97% of URGENT/11 and 80% of CDPwn Vulnerable Devices Remain Unpatched Putting Thousands of Organizations at Risk of Attack
Armis has continued to track the exposures from the URGENT/11 and CDPwn exploits discoveries over the past 18 months. Based on that research, we have identified that 97% of the OT devices impacted by URGENT/11 have not been patched; and 80% of those affected by CDPwn remain unpatched. As startling as those figures are, it is even more concerning when you break the data down by industry and understand what is at risk.
URGENT/11 affects additional RTOSs – Highlights Risks on Medical Devices
Armis has discovered that URGENT/11 impacts devices using six additional Real-Time Operating Systems (RTOS) that supported IPnet TCP/IP stack, 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 new discovery expands the reach of URGENT/11 to potentially millions of additional medical, industrial, and enterprise devices.
The Armis research team, Armis Labs, has discovered 11 zero-day vulnerabilities in VxWorks®, the most widely used operating system you may have never heard about. VxWorks is used by over 2 billion devices including critical industrial, medical and enterprise devices. Dubbed “URGENT/11,” the vulnerabilities reside in VxWorks’ TCP/IP stack (IPnet), impacting all versions since version 6.5, and are a rare example of vulnerabilities found to affect the operating system over the last 13 years. Armis has worked closely with Wind River®, the maintainer of VxWorks, and the latest VxWorks 7 released on July 19 contains fixes for all the discovered vulnerabilities.
Six of the vulnerabilities are classified as critical and enable Remote Code Execution (RCE). The remaining vulnerabilities are classified as denial of service, information leaks or logical flaws. URGENT/11 is serious as it enables attackers to take over devices with no user interaction required, and even bypass perimeter security devices such as firewalls and NAT solutions. These devastating traits make these vulnerabilities ‘wormable,’ meaning they can be used to propagate malware into and within networks. Such an attack has a severe potential, resembling that of the EternalBlue vulnerability, used to spread the WannaCry malware.
Armis disclosed the vulnerabilities to Wind River, the company that built and maintains VxWorks, and has worked with them to develop mitigations and patches, as well as notify manufacturers of affected devices. The URGENT/11 vulnerabilities affect the notedVxWorks versions since version 6.5, but not the versions of the product designed for safety certification – VxWorks 653 and VxWorks Cert Edition, which are used by selected critical infrastructure industries such as transportation.
URGENT/11 might have an even wider reach as IPnet was used in other operating systems prior to its acquisition by VxWorks in 2006; however, our research was exclusively on VxWorks, so we have no information on whether other RTOSs are impacted. The URGENT/11 vulnerabilities are estimated to impact devices such as SCADA, elevator and industrial controllers, patient monitors and MRI machines, as well as firewalls, routers, modems, VOIP phones and printers.
Manufacturers of devices running VxWorks are advised to check for the latest updates in the Wind River Security Alert posted on the company’s Security Center, and patch them immediately. The full technical details regarding URGENT/11 vulnerabilities can be found in the URGENT/11 technical white paper.
Armis researchers Ben Seri and Dor Zusman will present URGENT/11 at Black Hat 2019 and demonstrate real-world end-to-end attacks on three VxWorks-based devices: a SonicWall firewall, a Xerox printer and a patient monitor. Armis will be at Booth #166 at Black Hat.
VxWorks is the most widely used real-time operating system (RTOS) in the world. RTOSs are used by devices which require high accuracy and reliability, such as critical infrastructure, networking equipment, medical devices, industrial systems, and even spacecrafts. As such, VxWorks is used for an exceedingly wide range of purposes, from PLCs to MRI machines, to firewalls and printers, to airplanes, trains, and many more. The actual extent of VxWorks devices is astonishing, including Siemens, ABB, Emerson Electric, Rockwell Automation, Mitsubishi Electronic, Samsung, Ricoh, Xerox, NEC, and Arris, among others.
First released in 1987, VxWorks is one of the most mature operating systems still widely in use, and maintains a large number of its versions, due to the nature of the devices it operates and the difficulties in upgrading them. Despite being a legacy RTOS, only few vulnerabilities affecting it were ever publicly identified, none as severe as URGENT/11. VxWorks’ uncharted nature stems from the fact that it is closed sourced, making it more difficult to inspect, and the fact that it is an RTOS, which has received less attention from the research community as it does not operate strictly consumer devices.
Our research demonstrates why RTOS’ should receive the same scrutiny as others have, for two major reasons. First, any software which isn’t researched maintains flaws that might have a devastating impact once discovered. The inner workings of VxWorks have remained relatively in the dark, so did its flaws, resulting in the unusual low-level and severe URGENT/11 vulnerabilities. Second, RTOSs are used by critical devices, due to the high level of reliability they provide. This makes the effect of any vulnerability found within them much harsher. It is inconvenient to have your phone put out of use, but it’s an entirely different story to have your manufacturing plant shut down.
Furthermore, VxWorks devices lack the ability to install a security agent, and rely solely on the overall integrity of the operating system. VxWorks includes some optional mitigations that could make some of the URGENT/11 vulnerabilities harder to exploit, but we have not seen these mitigations used by device manufacturers at this time. In the devices we’ve examined (and exploited), almost no mitigations were used: no ASLR, no stack canaries and no DEP. The lack of a security agent combined with the absence of mitigations make URGENT/11 vulnerabilities even more dangerous.
URGENT/11 poses a significant risk to all of the impacted VxWorks connected devices currently in use. There are three attack scenarios, depending on the location of the device on the network and the attacker’s position. URGENT/11 can be used by an attacker to take control over a device situated either on the perimeter of the network or within it. Even a device that is reaching outbound to the internet could be attacked and taken over. Alternately, an attacker who has already managed to infiltrate a network can use URGENT/11 to target specific devices within it, or even broadcast an attack capable of taking over all impacted VxWorks devices in the network simultaneously. It is important to note that in all scenarios, an attacker can gain complete control over the targeted device remotely with no user interaction required, and the difference is only in how the attacker reaches it.
The first attack scenario affects VxWorks devices stationed at the perimeter of the network, such as firewalls. These devices are exposed to attacks coming from the Internet directly and are designed to be extremely secure, as the integrity of the internal network they protect relies on them. Using the URGENT/11 vulnerabilities, an attacker can launch a direct attack against such devices, taking complete control over them, and subsequently, over the networks they guard.
As an example of this scenario, consider how such an attack can take over the SonicWall firewall, which runs on the impacted VxWorks OS. According to Shodan, there are over 808K SonicWall firewalls connected to the Internet, representing a similar number of networks that these devices defend. Using URGENT/11 and an Internet connection, an attacker can launch a direct attack with a specially crafted TCP packet and take control over all firewalls at once, amassing a botnet nearly unparalleled in size and compromising all of the networks behind them.
The second attack scenario affects any impacted VxWorks device which has an external network connection. The URGENT/11 vulnerabilities enable attackers to take over such devices, regardless of any firewall or NAT solutions implemented on the perimeter of the network to fend off attacks. The low-level nature of the vulnerabilities allows the attack to remain invisible to security measures, as they would be viewed as benign network communications.
As an example of this scenario, consider an attack on an IoT device connected to the cloud from within a secure network — such as a Xerox printer. The printer is not directly exposed to the Internet, as it is protected by both a firewall and NAT solutions, through which it connects to a cloud application (such as Google Cloud Printing in this instance). An attacker can intercept the printer’s TCP connection to the cloud (regardless of TLS) and trigger one of the URGENT/11 RCE vulnerabilities on the printer, taking complete control over it. To intercept the TCP connection, an attacker can use techniques such as the one used by the DNSpionage malware, targeting DNS servers and becoming a Man-in-The-Middle on an organization’s Internet traffic. Once the attacker took over a device within the network, he can spread laterally taking control over other VxWorks devices in it, as described in the next attack scenario.
In this scenario, an attacker already positioned within the network as a result of a prior attack, such as the scenarios described above, can send the targeted VxWorks device packets capable of taking full control over the device, with no user interaction required. Furthermore, the attacker doesn’t need any prior information regarding the targeted devices, as URGENT/11 allows him to breach all vulnerable devices at once by broadcasting his malicious packets throughout the network.
As an example of such an attack, consider a critical device that has only internal network connections: the patient monitor in a hospital. Even though it has no connection to the Internet, by infiltrating the network an attacker can nevertheless take it over. While one might think hiding a device inside a secure network might suffice, there is always a way for attackers to get in, as demonstrated by the attack scenarios above, which detail how an attacker can infiltrate a network using URGENT/11 .
Another example can be found in Programmable Logic Controllers (PLCs), which are spread out in factories. Since they run on the impacted VxWorks, an attacker using URGENT/11 can broadcast an attack once in the network and effectively take control over the entire factory without any reconnaissance efforts, taking it down for ransom or any other malicious purpose.
As mentioned above, The URGENT/11 vulnerabilities affect all VxWorks versions since version 6.5, excluding versions of the product designed for certification, such as VxWorks 653 and VxWorks Cert Edition. New updates have been provided and more information can be found in the Wind River Security Alert posted on the company’s Security Center.
A partial list of devices impacted include:
Partial list of companies or devices using VxWorks versions impacted by URGENT/11:
In addition to the above devices, there are extensive lists publicly available that identify which manufacturers use VxWorks:
Since VxWorks is ordinarily used by the industrial and healthcare sectors, they are both put at an exceptionally severe risk by the URGENT/11 vulnerabilities. This risk only intensifies considering the critical nature of VxWorks devices in such environments. A compromised industrial controller could shut down a factory, and a pwned patient monitor could have a life threatening effect.
As a part of our research, the Armis Labs team successfully exploited three devices using the URGENT/11 vulnerabilities in accordance with the attack scenarios identified above.
A detailed technical report regarding all vulnerabilities can be found in the technical white paper (click here).
URGENT/11 is a set of 11 vulnerabilities found to affect VxWorks’ TCP/IP stack (IPnet), used by the versions of VxWorks as described above. Six of the vulnerabilities are classified as critical and enable Remote Code Execution (RCE). The remaining vulnerabilities are classified as denial of service, information leaks or logical flaws. As each vulnerability affects a different part of the network stack, it impacts a different set of VxWorks versions. As a group, URGENT/11 affects the VxWorks’ versions described above with at least one RCE vulnerability affecting each version. The wide range of affected versions spanning over the last 13 years is a rare occurrence in the cyber arena and is the result of VxWorks’ relative obscurity in the research community. This timespan might be even longer, as according to Wind River, three of the vulnerabilities were already existent in IPnet when it acquired the stack from Interpeak in 2006.
URGENT/11 are the most severe vulnerabilities found in VxWorks to date, which has suffered from only 13 public CVEs in its 32-year history. URGENT/11 is a unique group of vulnerabilities that allow attackers to circumvent NAT and firewalls and take control over devices remotely via the TCP/IP stack undetected, with no user interaction required. This is due to the vulnerabilities’ low level position inside the TCP/IP stack, which enables attacks to be viewed as legitimate network activity. Such vulnerabilities do not require any adaptations for the various devices using the network stack, making them exceptionally easy to spread. In most operating systems, such fundamental vulnerabilities in the crucial networking stacks have become extinct, after years of scrutiny unravelled and mitigated such flaws.
As mentioned earlier, URGENT/11 is comprised of 11 vulnerabilities, separated to two classes of severity:
Stack overflow in the parsing of IPv4 options (CVE-2019-12256)
This vulnerability can be triggered by a specially crafted IP packet sent to the target device, even as a broadcast or multicast packet. It does not require any specific application or configuration to be running on the device, and it affects any device running VxWorks v6.9.4 or above with a network connection. The vulnerability causes a stack overflow in the handling of IP options in the IPv4 header, making it easy to reach RCE by it.
Four memory corruption vulnerabilities stemming from erroneous handling of TCP’s Urgent Pointer field (CVE-2019-12255, CVE-2019-12260, CVE-2019-12261, CVE-2019-12263)
The following vulnerabilities all stem from erroneous handling of TCP’s Urgent Pointer field. This is an esoteric TCP field that is rarely used in modern applications. An attacker can trigger the erroneous handling of this field by either directly connecting to an open TCP port on the target device, or by hijacking an outbound TCP connection originating from the target device. Once triggered, these vulnerabilities will cause the application on the target device to receive more bytes than expected from the system’s recv() function, leading to a memory corruption of either the stack, the heap, or of global data section variables — depending on which buffer was passed to the recv() function. This means an attacker can probe the various TCP connections of the target device (either inbound or outbound) and attack the application that is the easiest to exploit.
Since the Urgent Pointer field is a built-in feature of TCP, routers, NATs and even firewalls that stand between the target device and the attacker are likely to transfer it intact. This means that even a TCP connection that travels from a vulnerable device to the Internet through multiple routers, NAT and firewall devices can still be hijacked by an attacker on the Internet and used to trigger the vulnerability. This can enable an attacker to not only take over vulnerable devices that are otherwise secured within internal networks, but also penetrate these networks via this path.
The four variants of this type of attack affecting different VxWorks versions:
Heap overflow in DHCP Offer/ACK parsing in ipdhcpc (CVE-2019-12257)
This vulnerability is a heap overflow vulnerability triggered when a vulnerable device parses a specially crafted DHCP response packets. These packets are parsed by ipdhcpc, VxWorks’ built-in DHCP client, when it attempts to acquire an IP address from a DHCP server. An attacker located in the same subnet as the target device can wait for it to send a DHCP request, and reply quickly with the specially crafted DHCP response. In this scenario the target device waiting for a response from the original DHCP server of the network will be easily fooled by the attacker, and parse the crafted DHCP response message. This would lead to a heap overflow with attacker controlled data that can result in remote-code-execution. This vulnerability affects VxWorks versions from 6.5 to 6.9.3.
TCP connection DoS via malformed TCP options (CVE-2019-12258)
This vulnerability affects VxWorks versions 6.5 and above, and allows denial-of-service attacks on any TCP connection to or from affected VxWorks devices. The vulnerability can be triggered by sending a specially crafted TCP packet containing certain TCP options with the 4-tuple of an existing connection, but without knowing the sequence numbers of that connection, causing the TCP connection to drop.
Handling of unsolicited Reverse ARP replies (Logical Flaw) (CVE-2019-12262)
This vulnerability is a logical error that affects VxWorks versions 6.5 and above, and can allow an attacker on the same subnet to add multiple IPv4 addresses to a target device via unsolicited RARP reply packets. This will disrupt the routing tables of the targeted device and can lead to DoS of any TCP/IP application used by it. Triggering this vulnerability multiple times can also cause memory exhaustion, leading to additional execution failures on the target device.
Logical flaw in IPv4 assignment by the ipdhcpc DHCP client (CVE-2019-12264)
This vulnerability is a logical error in VxWorks’ builtin DHCP client, if included, (ipdhcpc) that affects VxWorks versions 6.5 and above. A vulnerable device will accept any IPv4 address assigned to it by a DHCP server, even if this address is a non-valid unicast address (multicast, broadcast, or other illegal addresses). Similar to the RARP vulnerability mentioned above, an attacker in the same subnet can force the assignment of non-valid IP addresses to target device, which will lead to erroneous routing tables and will disrupt the network connectivity of the target device. In addition, assigning a multicast IP address to target device will also open up the device to the IGMP-related vulnerabilities described below.
DoS via NULL dereference in IGMP parsing (CVE-2019-12259)
This vulnerability is a denial-of-service vulnerability that affects VxWorks versions 6.5 and above, and can lead to a crash of a target device via an unauthenticated packet sent from an attacker within the local subnet. To trigger this vulnerability an attacker will first force an assignment of a multicast address on a target device via a specially crafted DHCP response packet. Then, he can send an IGMPv3 membership query packet to the target device, leading to a NULL dereference in the network stack and crashing the target device.
IGMP Information leak via IGMPv3 specific membership report (CVE-2019-12265)
This vulnerability is an information leak that affects VxWorks versions 6.9.3 and above. A device will be affected by this vulnerability if it has a multicast address assigned to its network interface, which can be achieved through DHCP client vulnerability described above (CVE-2019-12264). To trigger this vulnerability an attacker can send an IGMPv3 membership query report that is fragmented over multiple IP fragments to the target device. This would lead to an information leak of the target’s packet heap via an IGMPv3 membership report that will be sent back to the attacker.
Organizations and device manufacturers deploying devices with VxWorks should patch impacted devices immediately. Update and patch information can be found in the Wind River Security Alert posted on the company’s Security Center.
The most severe URGENT/11 vulnerabilities abuse esoteric parts of the TCP/IP stack that are almost never used by legitimate applications. Armis has developed the following Snort rules to be freely used by Firewall and IDS solutions to detect and prevent any attempt to exploit these vulnerabilities:
Update for Rockwell Automation products: VxWorks Vulnerabilities aect Programmable Automation Controllers, EtherNet/IP Communication Modules, I/O Modules, Kinetix Servo Drive, High-Frequency RFID Interface Block
Updates for SonicWall Firewalls are available on their support site. Specific updates to address URGENT11 can be found here.
Updates to SonicWall Firewalls can be a part of mitigation of VxWorks devices exposure to URGENT11, identifying and stopping suspected TCP traffic, thereby protecting those devices from future exposure.
Spacelabs has determined that some of its medical devices are running vulnerable versions of the operating system. Spacelabs will provide its evaluation of these vulnerabilities at the ICS-CERT website (www.us-cert.gov/ics) and on the cybersecurity area of our website (www.spacelabshealthcare.com/products/security/). Please refer to the sites for the latest information on identified threats and Spacelabs’ product mitigations.
Update for Xerox printers can be found here.
The Cybersecurity and Infrastructure Security Agency (CISA) has issued the following Advisory on URGENT/11.
The Canadian Centre for Cyber Security has made information available regarding updates and mitigations for URGENT/11. As mentioned, since VxWorks runs in embedded devices, it doesn’t offer the ability to install any kind of security agent. So the main options that an end-user organization (as opposed to a device manufacturer) could take to defend against attacks against URGENT/11 vulnerabilities are:
The Armis agentless device security platform is able to discover all devices in an enterprise environment that are vulnerable to any of the URGENT/11 vulnerabilities. In addition, Armis tracks device behavior and their connections to your network and within it, and detects anomalies in TCP/IP that indicate attacks URGENT/11 vulnerabilities. For additional information, please click here.
In response to an influx of inquiries, Armis will offer a Risk Assessment to help enterprises determine their exposure in the wake of the URGENT/11 vulnerabilities. The Risk Assessment is focused on identifying impacted devices so organizations can develop appropriate patching or mitigation programs. Organizations interested in learning more about the URGENT/11 Risk Assessment should email [email protected] or complete a Request for Risk Assessment.
Armis has released an URGENT/11 Detector, a free, downloadable tool, designed to detect devices vulnerable to URGENT/11 regardless of the RTOS the device uses. We strongly encourage organizations to use the open sourced tool to detect vulnerable devices in their networks and update them promptly.
The URGENT/11 Detector is an active tool that will use various non-invasive fingerprint techniques to determine if a device is using the IPnet TCP/IP stack, and whether it is vulnerable to URGENT/11 or not. This tool implements 4 unique methods of detection in the form of a TCP/IP stack fingerprints to a target host. It calculates the combined score of all the methods and determines whether the target host runs an OS that relies on the IPnet TCP/IP stack and whether the OS is VxWorks or not.
It will also test the host for one of the URGENT/11 vulnerabilities (CVE-2019-12258), which affects all versions of VxWorks that implement IPnet, and so it can determine whether a VxWorks-based device that uses IPnet has been patched against URGENT/11 or not.