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.

If you recognize this, you should probably keep reading

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.