VxWorks Vulnerability Tools Released

If you haven't started scanning your network for UDP port 17185, then you better start now. This past week at BSides Las Vegas and Defcon, HD Moore, CSO of Rapid7 and Metasploit chief architect for the Metasploit project, demonstrated an exploit against VxWorks that affects hundreds of products from many different manufacturers.VxWorks is an embedded operating system used in devices that range from consumer-based products like webcams to the Mars Rover and enterprise storage systems. HD gave Dark Reading a preview of his talk prior to Black Hat, BSides, and Defcon and can be found here, "Researcher Pinpoints Widespread Common Flaw Among VxWorks Devices."

Since then, HD has given his talk two times with even more information about the vulnerabilities, including some details and demonstrations that were intentionally kept from being recorded because they demonstrated actual exploitation. Today, advisories from his research will be published by CERT with tools for scanning, while exploitation tools will follow next month.

What makes these vulnerabilities particularly concerning is that they can be performed without knowing the password and they affect many devices including important enterprise hardware. Successful exploitation allows an attacker to dump memory and scan for passwords in the memory dump. Similarly, memory can be modified and reloaded without requiring credentials allowing an attacker to arbitrarily modify the firmware remotely.

HD published a blog a couple hours ago with more information that he covered in his talk and shows output from two of the four new modules he just added to the Metasploit Framework: wdbrpc_bootline, wdbrpc_version, wdbrpc_memory_dump, and wdbrpc_reboot. The four auxiliary modules are split into two categories where the first two are for scanning and device enumeration and the latter two actually exploit the VxWorks debugger service to dump memory and reboot the device.

I had originally started testing for these vulnerabilities by scanning a couple of devices I had in my lab using nmap looking for UDP port 17185 (only used by the VxWorks debugger). Since HD released the new Metasploit modules a few hours ago, I've rerun some of my scans and found it faster and more informative to use his modules instead of nmap because they can provide detailed version information about the hosts.

Of course, I'd be remiss if I didn't go beyond the enumeration phase and confirm that all of the found devices were indeed vulnerable. I put together a quick script to use the wdbrpc_memory_dump module to dump memory from a device I had laying around. And, just for the sake of confirming that wdbrcp_reboot worked, I rebooted the same device while pinging it to be sure it went offline and came back up--worked like a champ.

I'll ask again. Have you started scanning your network for UDP port 17185? I'm sure I already know the answer. Go, update your Metasploit Framework, and start scanning now. And, if you have any hosts on public IP addresses, then immediately go and block 17185 at your Internet boundary to prevent them from getting exploited. While the real "exploit" tools will not be released for another month, it won't take much to modify the wdbrcp_reboot module to do more than just reboot a device based on the information in HD's presentation, so please put in protections now.

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.