IT Freedom Blog

The Discovery and Disclosure of a Polycom Security Vulnerability

One night last June (2017), I was working from home, writing some software that would add Microsoft multi-factor-authentication to a VPN service that IT Freedom offers. The software itself was relatively simple, but the test environment I was using was unusually complex, with two servers and three client machines all dedicated to testing just the basic functionality. Since I was working from home, I needed to connect to those systems over the network, but there was a problem - I’d forgotten the IP addresses of two of them.

An Unexpected Discovery

I ran a port scan on the network to try and find the systems. I did indeed find them, but I also got an unexpected result:

Unexpected results have preceded the discovery of a lot of security vulnerabilities, and this result was especially weird. It appeared to show one of our office’s IP phones with open ports for SIP as well as SSH. SIP is a protocol used by most IP phones, so that was expected, but SSH is generally only used to log into the command line on servers and other network devices. I’d never seen it open on an IP phone before and I’d never seen anything about SSH in any of the many pages of Polycom reference documentation I’d read over the course of the past thirteen years of working with them at IT Freedom.

As it turned out, the phone in question belonged to Josh Caluette, one of our Systems Administrators. He had enabled a feature on the phone called “Desktop Connector” and that had in turn enabled SSH. Desktop Connector is sort of an odd ball feature on some models of Polycom phones that allows you to use your computer’s mouse as a mouse on the phone itself, so you can click on contacts on the display and perform other similar actions.

I tried to connect via ssh and got a password prompt. You aren't supposed to be able to get shell access on Polycom phones. This could be bad.

I guessed at a bunch of passwords, including all of the default web interface and provisioning ones I’d seen with Polycom, but those were a no go. I then started to wonder if the password might be hard-coded in the phone firmware itself and downloaded a copy from Polycom’s website, to try to peek inside of it.

Unpacking the firmware turned out to be arduous. The 50MB Polycom firmware image file seemed to be in a non-standard format that joined together and embedded multiple image types of various formats. There were filesystem/archive images in XZ, tar, CPIO, and Zlib mixed together, sometimes nested a few layers within each other. I did the extraction all by hand, but later found out that there is a utility called binwalk that I could have used to automate most of the process. Finally, I found the SSH server configuration file in one of the images and the passwd and files in one of the others.

The configurations looked pretty dangerous; hard-coded passwords for accounts with shell access and a configuration that allowed at least one of them to log in. If they worked, those passwords could be used to install backdoors on Polycom phones over the network to allow spying and all sorts of nasties. I decided to try and crack the passwords.

Cracking the Password

It had been a very long time since I had messed with any password cracking software, but I understood the basics. Password cracking software works by repeatedly making guesses at passwords until a match is found. That process is made faster by first only trying guesses to passwords that people are likely to have set. Passwords that contain words, passwords that end in numbers, that sort of thing.

The passwords I was cracking were both stored as md5crypt hashes. Md5crypt is a password hashing algorithm that is no longer thought of secure, even according to its author. Basically, due to advances in technology, what used to take many years and a substantial amount of hardware to try and crack could now take a few hours and some off-the-shelf components from Fry’s.

My first, and short lived, attempt was to try to crack the password was to use the quad-core CPU in a test machine I had at the office. That configuration chugged along at 84,000 guesses per second.

I’d heard before that GPU’s (graphics cards) were much better than CPUs for cracking passwords, but didn’t know much about it. I had a high end graphics card in a machine at home, a Nvidia 1080 Ti, so I decided to give it a shot.

That setup took a bit of work to get going and really was a lot of fun. I messed around with several options, including running the cracking software in AWS, but ended up settling on running Linux on the PC with the graphics card and cracking it there. At first that set-up produced 13 million password guesses per second. Quite an increase over the 84,000 that the CPU was getting. I didn’t let it sit at 13 million for long though. A few days later, I bought additional graphics card and also installed an older one I had on hand. That brought the number of guesses up to 33 million per second. I also brought the PC to the IT Freedom office and stuck it in our data center. While cracking, it was loud, consumed 500 watts of power, and generated just as much heat. Better in a datacenter than in my living room.

After a week, I succeeded in cracking the “Synergy” account’s password. It turned out that account could log in, but not execute any commands. I was confident from the firmware configuration though that the root account would allow a log in.

Reporting the Vulnerability

Shortly after, I contacted Polycom and let them know about that issue and several other more minor ones that I’d discovered along the way. I was pleasantly surprised with how quickly I was able to get in touch with their security team. Based on experiences I’ve had reporting vulnerabilities to other vendors, I fully expected to waste hours of my time just getting ahold of the right person. They quickly acknowledged the vulnerabilities and let me know when they planned to release patches for them.

The Fix

In June 2018, they released a new firmware update, Version 5.8.0, that included the patches for this vulnerability. As soon as we could, IT Freedom, and presumably other vendors, began to push this update to customer devices. Polycom also included in this update a security advisory, crediting me by name for disclosing the vulnerability. If you would like to see what Polycom has to say about this issue you can read their Security Advisory Relating to Vulnerabilities in VVX Phones and UC Software.

If you have any other questions about this vulnerability or how I discovered it, please reach out!