Introduction
In 2019, Armis disclosed 11 vulnerabilities affecting several real-time operating systems (RTOS’s) collectively known as “Urgent 11.” The embedded systems world reacted with justifiable alarm as a result of the high publicity. These vulnerabilities posed critical threats to many RTOS’s considered to have strong cybersecurity credentials. What many cyber-savvy defense teams may have overlooked as they began patching these issues, however, is a less hyped and much older vulnerability that has existed in Wind River’s VxWorks RTOS for more than 10 years.
CVE-2010-2965 was discovered by HD Moore at Rapid 7 in 2010 who detailed his findings in an article titled “Shiny Old VxWorks Vulnerabilities.” While it may be older, companies using VxWorks in their industrial control systems need to be aware of this critical vulnerability and treat it with the seriousness that Urgent 11 is rightly receiving.
The Vulnerability
Back in 2010, Moore actually discovered 2 vulnerabilities. The first was a weak hashing algorithm that left passwords vulnerable. This vulnerability was eventually fixed by VxWorks in later versions, and should not be a problem on VxWorks 6.9 or later. The second, which is the topic of discussion for this paper, was a debug service open over UDP port 17185 that was enabled by default. The protocol is called Wind River Debug, and is built on top of RPC. For short, it is known as WDBRPC. Wind River declined to add any additional security to this service, since vendors should be disabling it in production anyway. As a result, 10 years later, unsuspecting vendors continue to leave this debug port open in their final products and unwitting consumers continue to have their systems exposed.
The service allows for typical debugging functions such as stepping through instructions and reading from and writing to memory and registers. There is no security built into the protocol. Anyone with knowledge of how the service works can gain access to the same abilities as the Wind River debugging software. In practice, this means that hackers can use this protocol to gain full control over any system running VxWorks with its debugging capability enabled and no firewall in place.
In the original disclosure, Moore specifically focused on combining both discovered vulnerabilities to read password hashes in memory, and crack them to gain full access to the system. However, even after fixing the hashing algorithm, system compromise is possible through the additional debugging functionality. Proprietary code detailing this functionality has been exposed on various search engine-indexed sites at several points in the past, so it is unsurprising that several public exploits (and undoubtedly private ones as well) exist.
Public Exploits
The most well-known exploit was written by Moore himself as a module for Rapid 7’s own Metasploit Framework. At the time, all that was necessary for complete system takeover was reading the memory location of the password hashes, cracking them, and then logging in over another service like Telnet. As a result, the only debugging functionality built into the module is memory dumping capability and a system restart command.
Another less well-known framework called ICSSPLOIT updated and expanded the original exploit. However, the primary functionality built into this framework is still the ability to read and write memory. One added benefit to this framework is that it defines the foundational pieces of the WDBRPC protocol in Scapy for anyone looking to build upon it.
Another tool called VxPwn uses the debugging capability to fuzz the system with Sulley and check for crashed processes.
While none of these public tools will give an immediate shell since the password hashing algorithm was fixed, it would be extremely unlikely that attackers have not extended these tools, or created their own, to gain full control over vulnerable systems.
Risk to Industrial Control Systems
Critically, unlike Urgent 11, CVE-2010-2965 can affect certified versions of VxWorks such as VxWorks 653 and VxWorks Cert Edition as well as the standard versions. Wind River claims that billions of devices run their VxWorks operating system, and some of those devices are sold by major industrial corporations like Siemens and Bosch. The impact to companies employing affected systems could easily be catastrophic to their operation especially if the debugging service is exposed beyond the internal network.
Perhaps the most haunting piece of information to come out of Moore’s research is that an unknown entity spent months scanning for open WDBRPC ports 4 years previous to his initial discovery.
The Solution
No company wants to be the one who this unknown entity ultimately decides to go after. Fortunately, the fix for the vulnerability is not complex. Two solutions exist depending on the role of the user.
If the user is involved in the creation of the VxWorks image, he or she should remove the INCLUDE_WDB and INCLUDE_DEBUG components before creating the production environment.
If the user is a consumer of a product from a vendor who neglected to remove these components, the solution is to implement firewall rules to block access to UDP port 17185, and petition the vendor to implement a patch.
Conclusion
New vulnerabilities like Urgent 11 and CVE-2010-2965 are discovered every day. Even more unnerving, many are not. Companies in the industrial sector must remain vigilant in light of this knowledge. Discovering system weaknesses before attackers do is critical to maintain the security of these crucial systems. Regular penetration tests by qualified security professionals is a key weapon in this battle. For more information on how Vigilant Cyber Systems can help you obtain this improved security, contact us at [email protected].
