Thanks to video conferencing, we don’t always need to travel in order to conduct important business. But the reality of the situation is that an attacker can secretly conduct surveillance by taking control of the video conferencing camera and microphone. At Black Hat Europe, Moritz Jodeit presented “Hacking Video Conferencing Systems” [PDF] and demonstrated how to remotely compromise all variants of the popular Polycom HDX systems.
You might recall when Rapid7’s HD Moore alerted the public to the dangers of poorly configured video conferencing equipment being connected to the Internet. Moore highlighted the need to secure the configuration after showing that “thousands of videoconferencing systems were publicly accessible over the Internet and had the call auto-answer feature turned on." But Jodeit took it to an entirely new level and demonstrated how to remotely own the device.
Jodeit’s Black Hat presentation research [PDF] [slides] is divided into two main sections. First, he shows how to get root access to the Polycom HDX devices in order to find vulnerabilities and to develop exploits. He found vulnerabilities a malicious user might exploit such as by escalating privileges, a command injection when using the firmware update, a format string vulnerability, SQL injection, and a PUP file header MAC signature bypass. Then he explains how to remotely compromise the Polycom video conferencing system in its most secure configuration.
You developed a proof of concept exploit, but can you highlight for me what you discovered that was new from what Moore discovered please?
Jodeit: His research was all about missing awareness which resulted in poorly configured video conferencing equipment being connected to the internet. While he nicely showed that it's really important to harden the configuration of those devices and raise awareness, my research focuses on how to break these devices in their most secure configuration. So my research doesn't cover the configuration but the software implementation of those devices.
The first part of the research focused on how to get root access to the devices. This included attacks which already require administrative access to the device. These are not attacks which are meant to be used by an attacker to compromise those devices remotely, but just to get root access (which you are not supposed to have) in order to analyze the device and be able to more easily find vulnerabilities and develop exploits. So the described ways to get system level access are more meant for security researchers to conduct their own research on these devices.
The second part of the research then focused on how to remotely compromise these devices in their most secure configuration (and of course without having prior administrative access to the device). The attack I described in the H.323 stack which exploited the format string bug is one of these attacks. By just sending a lot of H.323 SETUP packets to the device I'm able to get root access to the device remotely.
You mentioned, "After compromising an HDX system you typically want to control the device's peripherals like moving the camera, recording voice using the microphone, playing sounds or displaying childish messages on the screen." But if an attacker were to overcome the urge to play sounds or display messages, exploiting payloads in order to control the video camera and microphones, then an attacker could use the system for surveillance and potential espionage without being detected?
Jodeit: Exactly, that's the whole point in compromising those devices. To take control over the camera and the microphone in order to do surveillance. The part where I show how to play sounds or display things on the screen was basically only used to demonstrate that I have full control over the device.
There has been considerable research in video-conferencing security risks over the years, yet systems are still exploitable. Do you believe that attackers, be it nation states or business rivals, are secretly exploiting these systems?
Jodeit: That's really hard to say. But that was one of the reasons I started this research, to see how easy it would be to compromise those systems and use them for surveillance purposes.
Polycom has a long list of customer success stories, from the healthcare industry, to the Colorado Department of Transportation, universities and other educational services, and even banks and the entertainment industry. In some cases, it is used by the courts or for arbitration. You referenced a White House videoconference meeting when President Obama spoke with the German Chancellor, French President and Italian Prime Minister. By having full control to send messages, is there some potential scenario you could give me that an attacker could maliciously intervene or interject into the system when used by an arbitration court?
Jodeit: In order to compromise these systems you must have the ability and network connection to "call" them (even though the call auto-accept feature doesn't need to be turned on). Once compromised, then you can basically do anything on the device. This of course includes recording or modifying the data of ongoing video conferences taking place over the compromised device.
Rapid7 was 'attacked' after highlighting the security risks of poorly configured video conferencing systems. Have you been harassed? If so, is there anything that you might want to say in return?
Jodeit: No, I have not been harassed. I only received positive feedback so far. ;)
Did anyone from Polycom HDX systems contact you, or say anything about your presentation that you know of?
Jodeit: We responsibly disclosed all the published vulnerabilities to Polycom before the Black Hat talk. Polycom was pretty responsive and really transparent during whole process. They even offered me a test build before the official publication of the new release 3.1.1.2 which fixed all the issues. This release was published just in time, one day before the talk. One guy from Polycom also attended the talk and I received positive feedback from him as well.
The advisories published by Polycom can be found here:
Security Bulletin 107522: Security Advisory Relating to the Firmware Update Command Injection Vulnerability on Polycom HDX Video Endpoints. “The Polycom HDX is susceptible a command injection vulnerability which allows an authenticated malicious user to execute arbitrary commands on the system when using the firmware update functionality.”
Security Bulletin 107523: Security Advisory Relating to the Command Shell Vulnerability on Polycom HDX Video Endpoints. “The Polycom HDX Command Shell is susceptible to and escalation of privileges vulnerability that could lead to unauthorized system access and information disclosure.”
Security Bulletin 107524: Security Advisory Relating to the H.323 Format String Vulnerability on Polycom HDX Video Endpoints. “The Polycom HDX is susceptible to a format string vulnerability via a maliciously crafted call setup message that could lead to systems instability or remote code execution.”
Security Bulletin 107525: Security Advisory Relating to the H.323 CDR Database SQL Injection on Polycom HDX Video Endpoints. “The Polycom HDX is susceptible to a SQL injection vulnerability via a maliciously crafted call setup message that could lead to remote code execution.”
Security Bulletin 107526: Security Advisory Relating to the PUP File Header MAC Signature Bypass on Polycom HDX Video Endpoints. “The Polycom HDX uses a software update process that reads in a PUP file containing all of the information and tools needed to properly update the system. A vulnerability has been discovered in the PUP file header MAC signature verification process allowing a malicious user to extract the components of the PUP file.”
I have great respect for HD Moore, Chief Security Officer at Rapid7 and Chief Architect of Metasploit, so I also reached out to Moore to see what he thought of Jodeit’s research into hacking video conferencing systems.
HD Moore: Mr. Jodeit’s research is a great example of the type of vulnerabilities widely present in embedded network devices. These devices have been mostly ignored in the past by both researchers and security-conscious users. The reason for this is two-fold. First, the minimum amount of work to get a viable debugging environment is not trivial; this requires a combination of reverse engineering, knowledge of embedded systems, and familiarity with non-x86 processors. Second, the risk of an embedded device is often considered low to none. This situation will only improve as real-world risks are identified and the manufacturers of these systems start to feel pressure from their customers.