An Unwanted (Wireless) Guest
Gaining a foothold onto the corporate LAN with the Crestron AM-100
As a consultant, one of the perks of traveling to clients is seeing how different companies adopt next-generation devices in their office spaces. While most people currently think of the Internet of Things as something for hobbyists and geeks to spruce up their homes with, I have noticed a definite trend towards the adoption of these devices in the corporate world as well. Most forward-thinking companies I have been to in the last 6 months have at least one piece of internet connected automation, whether it’s a smart lock, digital camera sentry, or a Raspberry Pi that keeps track of beers on tap. While it definitely increases the “hip” factor, when these devices get connected to the network it brings in a whole new element of security concern.
One relatively common device I have been seeing in networks is some type of wireless presentation box. Instead of having to grab a cable to plug in, guests can conveniently connect over the air and project their screens. In theory, I love the idea because there’s nothing more annoying than having to keep three different types of cables around just in case someone has a different output port. In practice, they are an attacker’s new best friend because they are often unprotected, unpatched, and offer a clear route to jump from guest access to the employee network.
On a recent internal penetration test, I wanted to test the segmentation between a client’s guest wireless network and their corporate LAN. Everything seemed to be configured according to best practices, and the only thing I was able to locate were three wireless presentation devices, the Crestron AM-100. Usually I will try to prioritize targets that have services that seem vulnerable first, such as Tomcat consoles, Wordpress blogs, or anonymous login FTP servers, but I figured it couldn’t hurt to poke around at these devices before I moved on.
As it turned out, these devices were completely full of holes. After a bit of Googling, three months ago the Cylance team publicly disclosed several critical vulnerabilities, including a path traversal, a command injection, and a hardcoded backdoor account. Thankfully, this was the perfect storm of issues that enabled us to get root on the device.
First, the /etc/shadow file was read:
However, even if we could crack it, there was no SSH or Telnet service on the device. Unless there’s a secret management console or something…
Using the username rdtool and the Google-able password mistral5885, I was able to turn on the Remote Debug service which caused a telnet server to open on port 5885!
Instead of waiting for the hash to actually crack out, I was able to read an awesome presentation of someone who had already done the hard work — the hardcoded root password was awind5885.
Now that I had root access on the device, it was possible to read the actual web console password in cleartext. Apparently the device stores valid session information in a file named session01.
The configuration files on the device also stored the connection details for the corporate wireless network, giving me a potential way to jump on with another device.
If that weren’t enough, the rdtool management page from before had the ability to upload files directly to the filesystem. If necessary, it would be trivial to create a malicious ELF binary with msfvenom and execute it from the terminal. Because the routing features of the ARM version of meterpreter (mettle) were acting spotty for me and the fact that netcat was already readily available, I was able to create a netcat relay and forward my traffic into the target network.
One of the big problems I have with the Internet of Things is that devices are no longer just “things” but are actually potential footholds to the network. Yes, a simple HDMI cable seems so passé in 2016, but at least you don’t have to add it to your patch management program. As part of a strong security program, all these devices need to be inventoried and properly segmented from the rest of the network. In this particular case, updating the latest version of the firmware fixed most of these issues, but these devices almost always fly under the radar of even the most astute companies. The danger is very real — don’t be tempted to let convenience trump strong security practice.
Original Vulnerability Research by:
Cylance — https://github.com/CylanceVulnResearch/disclosures/blob/master/CLVA-2016-05-001.md
SomethingBroken.com (Dave Aitel?) — http://somethingbroken.com/vuln/static/0003_b.pdf
