On July 29th, 2019, eleven vulnerabilities affecting the “VxWorks” Real Time Operating System (RTOS) were publicly disclosed. Since these vulnerabilities were all reported by the same source and all deal with VxWorks’ network stack (the software code implementing network communications), they were bundled together in the same advisory: ICSA-19-211-01. A reference to the number of vulnerabilities as well as the TCP feature that many of them exploit, the CVE bundle has been collectively dubbed “URGENT/11.”
Of those eleven vulnerabilities, five received CVSS scores of 8.8 or higher. Originally, these vulnerabilities were only believed to be present in VxWorks versions starting with 6.5 (released in 2006) and ending with 7.0 SR620 (released July 19, 2019). Further research revealed that these vulnerabilities actually have a wider reach and affect devices using six additional RTOSs, including OSE by ENEA, Integrity by Green Hills, ThreadX by Microsoft, Nucleus RTOS by Mentor, ITRON by TRON Forum, and ZebOS by IP Infusion.
This revelation, coming two months after the original disclosure, extended the vulnerabilities' footprint to millions more devices — with a disproportionate impact on hospitals.
The vulnerabilities comprising URGENT/11 all take advantage of legacy features found in the TCP/IP protocol and can be exploited with minimal requirements by sending a small number of packets to targeted machines. All that's needed is the ability to open a communication link between an attacker device and a target device over TCP.
At the same time, even though an URGENT/11 attack is not inherently difficult to pull off, a more sophisticated exploit could yield considerably more and better controlled damage. In the hands of an able hacker, these vulnerabilities can be made "wormable", allowing the attacker to plant an agent in the device that will work on spreading further.
Of the vulnerabilities contained in URGENT/11, each allows for different levels of network compromise, from remote code execution to information disclosure and possible denial of service. As a general rule, those vulnerabilities allowing for remote code execution should be attended to with greater alacrity.
Identifying Affected Devices
Because URGENT/11 exists in an embedded operating system that communicates with the network in a much more task-specific manner, the metadata disclosed over the network in the course of normal operations rarely includes more general information such as operating system signatures. This is in contrast to more all-purpose operating systems, such as Windows, that more frequently transmit information on their user agents, browser protocol, antivirus signatures, resource sharing, DNS queries etc.
As such, a complete indexing of URGENT/11-vulnerable devices can be difficult to achieve using standard security solutions alone.
Further complicating the matter is the fact that these embedded operation systems can run behind other operating systems on the same device. For example, a FUJIFILM SonoSite M-Turbo ultrasound machine may use VxWorks to run ultrasound operations and WinCE for its graphic user interface.
Security solutions that are less specialized and less context-aware may suffer from the technological equivalent of confirmation bias: they look for what they expect to see and classify the world around them accordingly. These solutions don't do very well with nuance and in a case like that described, they'll likely classify the device OS simply as WinCE. In so doing, they would also leave a blind spot in the network — with devices left exposed to URGENT/11 and entirely unknown to administrators.
Of course, it's not just a matter of knowing which devices run the IPnet TCP/IP stack supporting RTOSs, but knowing which devices run the specific RTOS versions that are vulnerable and whether or not they're networked in such a way that leaves them exposed.
For example, in a large and sprawling networked environment like a hospital, you may have hundreds of VxWorks devices stretched out across miles of your medical campus and belonging to different local or virtual networks. If you know that only ten of those devices run vulnerable versions of VxWorks and only three are accessible to the broader network, you can save significant time and avoid considerable disruption in your mitigation efforts. Unfortunately, this is not information that a standard security solution will be able to provide.
In these and other ways, URGENT/11 is a case in point for why HDOs need more specialized and context-aware cybersecurity solutions. A suitable solution will combine advanced network monitoring with machine learning, strategic active interrogation, and a supporting team of cyber analysts possessing expertise in medical devices and clinical workflows. Only through this sort of multi-lateral and healthcare-wise approach can administrators rest assured in the knowledge that their asset inventories will be comprehensively and accurately indexed, smartly classified, and efficiently patched/mitigated with respect to vulnerabilities like URGENT/11.
With a suitable solution in place, when vulnerable devices are identified, the relevant managers are sent in-system and email notifications informing them of the vulnerable devices and providing clear and actionable instructions for mitigation.
Vulnerable Products Found In Hospitals
The October 1 update to the original disclosure extended the vulnerabilities to, among other RTOSs, OSE by ENEA. For hospitals, that addition is hugely consequential. OSE is the RTOS used in BD's Alaris line of products; encompassing some of the most prevalent connected infusion pumps on the market.
This revelation exploded the hospital attack surface from less than 1% of medical devices to approximately 22%, per CyberMDX statistics. For context, only around 4% of a hospital's total connected device roster is vulnerable. That means that medical devices are more than 5X as exposed to these vulnerabilities than other devices.
In total, CyberMDX has identified over 300 different device models that may be found in connected medical environments and are exposed to URGENT/11. These include both medical devices as well as IoT devices.
Affected medical devices include (but are not limited to) certain models of Siemens MRI machines, some GE X-ray and UltraSound machines, certain Dräger ventilators, incubators, and anesthesia machine models, some Philips C-arms, and BD Alaris™ PC Unit.
Affected non-medical devices include (but are not limited to) certain Building Automation and Control system models, some firewalls, certain models of Xerox printers, certain models of Canon printers, some Hirschmann and 3Com switches, certain Cisco access points and IP phones.
If you're struggling to ascertain which devices from within your network fleet use vulnerable RTOSs, it may be helpful to cross-reference your asset list against a glossary of manufacturers known to design for VxWorks. You can find two such glossary examples by following the links below:
If you are fielding a device not implicated in the above or other glossaries and still suspect it to be vulnerable, please reach out to the vendor immediately. Depending on the circumstances, you may also want to reach out your cybersecurity service/solution providers.
While Wind River has released a version (7.0 SR620) that fixes the security flaws on which URGENT/11 is predicated, it's important to note that the company cannot directly patch your devices. Wind River supplies vendors a development kit for them to use when packaging VxWorks firmware for their products. The updated VxWorks version still needs to be baked into the vendors' firmware before it can be installed to your machines.
It's imperative therefore that you contact the vendors of your affected devices and arrange for firmware upgrades based on VxWorks version 7.0 SR620.
Listed below are some examples of advisories issued by vulnerable device vendors:
- Extreme Networks
- GE Healthcare
- Schneider Electric
- Sonicwall Firewalls
- Trend Micro
- Xerox Printers
As a general best practice, a policy should also be configured to accept DHCP offers and RARP replies ONLY from network entities responsible for IP assignment. All other DHCP offers and RARP replies should be automatically dropped.
Other firewall/IDS policies should be applied specifically for URGENT/11. Since these policies could rarely but possibly impact the normal functioning of certain network devices, it is best to apply them to the inbound communications of only VxWorks devices.
These policies should:
- Drop all packets flagged "Urgent". This flag is seldom used by today's systems, so its presence would not only be potentially dangerous but inherently suspicious.
- Drop IP packets containing LSRR or SSRR options (routing related features).
- Limit the size of DHCP options to 240 bytes.
For additional update and patching information, you may refer to the Wind River Security Alert posted on the company’s Security Center or contact CyberMDX.
Reports of vulnerabilities such as URGENT/11 send shock waves through the technology world. At the same time, they're becoming more and more common. As was the case with SACK Panic, URGENT/11 poses particular difficulties for traditional security solutions — with their identification and classification regimes lacking the necessary granularity, context-awareness, and device expertise to flag vulnerable machines in the wild.
Of course, in considering your response to URGENT/11, it's important that you think strategically as well as tactically. It's not enough to craft a plan of defense for known vulnerabilities. You must also plan to protect yourself against those zero-day vulnerabilities for which you don't yet know the details.
There is no debate around the fact that there are latent zero-day threats in every medical network. It is therefore essential that you implement controls and defenses capable of abating threats unknown. In practice, that means doing whatever you can to proactively reduce your attack surface and using some sort of advanced deviation from baseline analysis to lookout for non-specific suspicious activities.
If you need assistance, CyberMDX is here to help.
Update [10/02/2019]: Article updated to reflect the expanded content of the disclosure.