Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


09:49 AM
John H. Sawyer
John H. Sawyer

Gaining A Foothold By Exploiting VxWorks Vulns

The VxWorks vulnerabilities recently announced in Las Vegas during the BSides and Defcon security conferences have opened a can of worms for hundreds of vendors, and even more consumers and companies using the vulnerable products -- the majority of whom have no idea they're vulnerable and potentially exposed to external attackers.

The VxWorks vulnerabilities recently announced in Las Vegas during the BSides and Defcon security conferences have opened a can of worms for hundreds of vendors, and even more consumers and companies using the vulnerable products -- the majority of whom have no idea they're vulnerable and potentially exposed to external attackers.I've spent several late nights exploring vulnerable VxWorks systems and digging through memory dumps from vulnerable systems. There are a couple of things that have become apparent. The first is these devices are everywhere. As I mentioned in my previous blog, VxWorks is found in webcams, enterprise SANs, and the Mars Rovers, which is impressive, but there's more.

You can find it running on printers, streaming multimedia devices, Fiber Channel and network switches, wireless access points and routers, VoIP phones, and videoconferencing products.

You get the point. VxWorks is everywhere. And best (or worst) of all, there's a treasure trove of information buried in their memory. Before we dig into what you can find in them, let's quickly cover finding them.

Identifying vulnerable VxWorks devices is extremely easy. The quickest, yet noisiest, method is scanning your target network with something like the Metasploit Framework's wdbrpc_bootline. You provide it with a single IP or subnet, and it probes UDP port 17185, then returns the VxWorks boot parameters if the device is vulnerable. It's super easy. Major vulnerability scanners should also have included detection capabilities by now -- I know Nessus and Rapid7 Nexpose do.

However, if you're looking to fly under the radar, then a scanner could cause some unwanted noise. SHODAN can help by providing a searchable index of service banners found by scanning Internet-accessible systems. Searching for "vxworks" returns nearly 18,000 publicly accessible devices that contained "vxworks" in their banners for HTTP, HTTPS, FTP, and Telnet.

That's a lot of devices, but let's say you're targeting a specific manufacturer or device. You can search for terms like "mcdata," which will return a handful of Fiber Channel switches. There are also numerous video-streaming devices that can be found by searching for "vbrick." What about scarier stuff like SCADA devices? It's all there, too, and disappointingly easy to find -- "SCHNEIDER TSX," for example.

Once you've found vulnerable VxWorks-based devices on your network (or your target's network), it's time to start dumping memory and digging for the good stuff. Be on the lookout for passwords, internal IPs, printed and scanned documents, e-mail addresses, and anything else that might help during a penetration test. Use the wdbrpc_memory_dump Metasploit module to dump memory from a device; if you have many and want to automate it, Dillon has written a blog titled "Metasploit VxWorks WDB Agent Attack Automation" on how to do it with Ruby.

Of course, if you're lazy like me, then you automated the dumping in one line of bash: for i in `cat hosts`; do ./msfcli auxiliary/admin/vxworks/wdbrpc_memory_dump RHOST=$i LPATH=/tmp/vxworks/$i E ; done

While you can find password hashes associated with the weak password hashing algorithm in memory, the tools to exploit the vulnerability will not be released until September. You could spend time generating your own table like a friend did, but there's other juicy tidbits to be found without much effort.

Two different devices I looked at had their management interfaces' user name and password in the memory dumps within a HTTP Basic Authentication header that can be easily decoded. I was scrolling through a dump with a hex editor when I found a full header with something like "Authorization: Basic YWRtaW46c3cxdGNocHcK." From there, I started searching dumps (grep -ai "Authorization: Basic" dump_file) and found several more. Unfortunately, finding these credentials was not consistent across all the devices I looked at.

There's also the potential for exposure of passwords to other systems. For example, multifunction copier devices can often send scanned documents via e-mail, upload them using WebDAV, or save them to a shared folder on a Windows system. On one device I found the WebDAV user name and password that was base64 encoded similar to the HTTP Basic Authentication headers above. On another device, there was what appeared to be an Active Directory service account with password.

Like I said, these vulnerabilities have opened a can of worms, and there's still so much left to explore. I'm sure there's more interesting information that can be gleaned from these systems' memory, so if you're bored this weekend, you know what you can do. You never know, it could lead to the foothold you need in your next penetration test.

Happy hacking!

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.