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.