Blog

Solving URGENT/11: Identifying VxWorks and Defending OT Devices

Elisa Costante | July 31, 2019

Executive Summary

  • Critical vulnerabilities have been disclosed exposing billions of embedded OT devices.
  • Use Forescout to discover and inventory VxWorks devices to prioritize critical patch updates.
  • Segment and control network access for vulnerable VxWorks versions using the Forescout platform.
  • Use SilentDefense to alert and block some of the attacks exploiting VxWorks.
  • Extend detection coverage using the scripting engine to address the remaining issues.
  • Configure Forescout to contribute up-to-date VxWorks asset inventory and ensure accurate CMDB and GRC controls.
  • To illustrate VxWorks device visibility and control in the RTOS landscape, Forescout Research examined over 32,000 devices from fifty vendors embedding VxWorks into their OT and IoT products.

Introduction

On July 29th 2019, 11 vulnerabilities affecting Wind River VxWorks, a popular Real Time Operating System (RTOS), were publicly disclosed by Armis (Seri, Vishnepolsky, & Zusman, 2019). These vulnerabilities are different from many others mainly because:

  • They affect an OS that is used in some 2 billion embedded systems, including mission-critical devices for Aerospace, Defense and Critical Infrastructure. Devices with embedded systems are notoriously difficult to manage because traditional endpoint agents cannot be installed and updates usually require a firmware reflash. As Bruce Schneier commented in 2014: “embedded computers are riddled with vulnerabilities and there’s no good way to patch them.” (Schneier, 2014)
  • Affected devices include internet-facing network hardware like firewalls (e.g. Sonicwall), routers, modems, VoIP phones and printers (e.g. Xerox, Canon), SCADA systems and more.
  • While Wind River isn’t explicitly acknowledging device types in its advisory, the vulnerabilities also likely exist in medical and patient diagnostic and monitoring equipment, satellite-based communications modems, and mission-critical ICS hardware including PLCs and DCSs.
  • Three of the issues have a Critical CVSSv3 rating and six can lead to Remote Code Execution – essentially, full control of the targeted device.
  • Most of the issues relate to the implementation of the TCP/IP stack (while the remaining relate to the DHCP client), which means they do not depend on a specific application and the adversary only needs network access to the targeted device to leverage the vulnerabilities and take device control.

Which Devices are Impacted?

VxWorks is a widely deployed Real Time Operating System leveraged by companies such as ABB, Airbus, Alcatel-Lucent, BD Biosciences, Boeing, Delphi, Eurocopter, Huawei, Mitsubishi, NASA, Northrop Grumman, Siemens, NEC and Varian to create products that go from healthcare to space exploration, from commercial aircraft to military operations (Wind River Systems, 2016). It is worth noting that both the Mars Rover (Brewster, 2015) and SpaceX Dragon (SPACEX, n.d.) use VxWorks. The OS is also widely used in embedded systems such as PLCs and DCS controllers from ABB (ABB, 2019), Siemens, Emerson, B&D, Schneider Electric, GE, Rockwell and others.

To further clarify and group the impacted devices, we analyzed the Forescout Device Cloud to see how many (and what kind) of devices run VxWorks. Forescout Device Cloud contains data from over more than 10 million devices across the Forescout customer base.1 Table 1 shows a breakdown of the number of devices running VxWorks divided per vertical. More than 32,000 devices were found running the VxWorks OS, with Healthcare and Government the most impacted.

For a more in-depth analysis, Figure 1 shows the Top 10 vendors using VxWorks, while Figure 2 shows what device types. VoIP Phone Systems are the most popular kind of devices, with NEC Platforms being the most common vendor in our sample. Attackers could use internet-facing VoIP Phones to get a foothold in a network and from there move laterally to more critical areas and devices.

Figure 1: Top 10 Vendors using VxWorks OS 2

Figure 2:Device Type using VxWorks OS 3

Deep Dive into the Vulnerabilities
VxWorks was first released in 1987 and its current iteration is thirteen years old. URGENT/11 includes the most severe vulnerability to affect the VxWorks RTOS to date, and mitigation actions are necessary. Of the 11 vulnerabilities, six are assessed as Critical by Armis because they enable remote code execution and wormable proliferation of dangerous payloads via TCP/IP traffic. The remaining five can lead to Denial of Service, logical errors or information leaks. Critical vulnerabilities include IPv4 Stack Overflow (CVE-2019-12256); 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); and the heap overflow in DHCP Offer/ACK parsing in ipdhcpc (CVE-2019-12257).

Below, we provide an analysis of the vulnerabilities and how a possible exploit can be detected by Forescout SilentDefense™ either out-of-the-box or with custom-made IDS scripts.

  • CVE-2019-12255 (CRITICAL) refers to the use of the field “Urgent Pointer” in the TCP header: if it is set to 0 it will lead to an integer underflow. To exploit this vulnerability, an attacker can send a TCP packet with “URG Flag” set to 1 and “URG Pointer” set to 0. This can be detected by a SilentDefense script that our team is currently developing and will be released soon.
  • CVE-2019-12256 (CRITICAL) is about a stack overflow in the parsing of IPv4 packets’ IP options. To exploit this vulnerability an attacker needs to send an IP packet with malformed LSRR (Loose Source and Record Route) or SSRR options (Strict Source and Record Route). The victim will generate an ICMP error message in response, and by doing that a stack buffer overflow happens. An exploitation of this vulnerability can be found by SilentDefense out of the box since the system will generate the following alerts: “Invalid Pointer Value in the SSRR”, “Invalid Pointer Value in the LSRR option”, “IP LSRR option appearing more than once” and “IP SSRR option appearing more than once.”
  • CVE-2019-12257 (CRITICAL) relates to a Heap overflow in DHCP Offer/ACK parsing inside ipdhcpc. DHCP Offer (and ACK) packets end with a variable “length options array”. To exploit the vulnerability, an attacker needs to send a DHCP offer packet with “total packet length” of 336 bytes, which is more than the 312 bytes available and causes a 24-byte heap overflow. This can be detected by a SilentDefense script that our team is currently developing and will be released soon.
  • CVE-2019-12258 is a DoS of TCP connection via malformed TCP options. If there is a legitimate TCP session established with a 4-tuple (SrcIP,SrcPort,DstIP,DstPort), an attacker can send a TCP packet with the same 4-tuple and any invalid TCP option set in the header without the need of knowing the sequence number, and the legitimate connection will be terminated. An exploitation of this vulnerability can be found by SilentDefense out of the box, as the system will detect “TCP invalid option” and “TCP Option Length Mismatch.”
  • CVE-2019-12259 refers to a DoS via NULL dereference in IGMP parsing. To exploit this vulnerability, an attacker needs to first exploit CVE-2019-12264, and then send a valid IGMPv3 membership query packet. Since the exploit of CVE-2019-12264 is a necessary condition for the exploit of CVE-2019-12259, we can detect attempts to exploit the latter by detecting exploits of the former.
  • CVE-2019-12260 (CRITICAL) refers to a TCP “Urgent Pointer” state confusion caused by malformed TCP AO option. To exploit this vulnerability, an attacker must send the following packets:
    • a SYN packet with TCP-AO and option length = 3
    • a SYN/URG/FIN packet with sequence number 0 and urgent pointer not zero
    • a valid SYN packet with a large sequence number

    In case of such an exploit, SilentDefense will generate an alert about the “TCP Invalid Flags Field Value.”

  • CVE-2019-12261 (CRITICAL) refers to TCP Urgent Pointer state confusion during connect() to a remote host. This vulnerability works the other way compared to the previous one, here the vulnerable system connects to the attacker (either legitimately or via a man-in-the-middle). To exploit this vulnerability, an attacker must perform the following actions upon receiving a TCP connection attempt from a vulnerable device:
    • attacker responds to normal SYN Packet with SYN/ACK/URG/FIN packet with crafted initial sequence number
    • attacker sends valid SYN/ACK packet with a different crafted sequence number

    In case of such an exploit, SilentDefense will generate an alert about a “TCP Invalid Flags Field Value.”

  • CVE-2019-12262 relates to the handling of unsolicited Reverse ARP replies (Logical Flaw). To exploit this vulnerability, an attacker needs to send a reversed ARP packet to the device. This can be detected by a SilentDefense script that our team is currently developing and will be released soon.
  • CVE-2019-12263 (CRITICAL) relates to TCP “Urgent Pointer” state confusion due to race condition. For this attack to be successful, there are many prerequisites to be matched, including the fact that different parts of the networking functionality need to run at different privilege levels. Unfortunately, this makes exploitation detection extremely hard to achieve. We are currently examining how it is possible to reliably detect the exploitation.
  • CVE-2019-12264 relates to a logical flaw in IPv4 assignment by the ipdhcpc DHCP client. To exploit it, it is necessary to send a DHCP offer in response to a DHCP request, or a DHCP renewal with IP address assigned as multicast, broadcast, or any other invalid IP address. This can be detected by a SilentDefense script that our team is currently developing and will be released soon.
  • CVE-2019-12265 is about IGMP Information leak via IGMPv3 specific membership report. An attacker can create specially crafted and fragmented IGMPv3 query report sent to a multicast address which is associated to the host. This can be detected by a SilentDefense script that our team is currently developing and will be released soon.

Table 2 provides a summary of how exploits of URGENT/11 vulnerabilities can be detected by SilentDefense.

Impact and Exposure

To exploit URGENT/11 vulnerabilities, an attacker needs direct connection to an affected device or a routed path to internal networks. This means devices directly connected to the internet are those most at risk. An attacker could target these devices first, compromise them and move further into the network to access or infect other devices.

As an example of the impact of these vulnerabilities, a Shodan search reveals there are more than 900 thousand internet-connected instances of Sonicwall firewalls (known to be vulnerable to URGENT/11) (Gmuender, 2019) that could be directly compromised by anybody on the internet. This means corrective actions like identifying the vulnerable system versions to prioritize patch updates and further isolating them with segmentation techniques needs to be taken as soon as possible.

Figure 3: Instances of SonicWall firewall on Shodan (search made on July 31st, 2019)

Recommended Mitigations

For a complete protection from URGENT/11, patching the devices running the vulnerable version of the OS is the only long-term protection. However, many of the affected devices are part of critical systems and infrastructure that make patching a complicated affair. In addition, certain systems patches might not be available yet (see advisory from ABB (ABB, 2019)).

Luckily, for most of the vulnerabilities, SilentDefense offers detection of exploit attempts (see Table 2). We suggest the following mitigation strategy:

  • Discover and inventory devices running VxWorks OS with eyeSight to prioritize patch updates and segment vulnerable versions
  • Establish immediate out-of-the box protection by making sure the SilentDefense Malformed Packet Detection engine is enabled
  • Install the URGENT/11 SilentDefense script as soon as it is made available
  • Check network hygiene and segregation from external connections with SilentDefense LAN CP
  • Monitor changes to the asset inventory with progressive patches released by affected device vendors
  • Establish a remediation plan with SilentDefense Asset Inventory and Reporting
  • Use SilentDefense alerts to initialize remediation actions like moving a vulnerable device out of the network or apply updates/patches via Forescout eyeControl

References

ABB. (2019). Cyber Security Notification – WindRiver VxWorks IPNet Vulnerabilities, impact on ABB Industrial Automation products.ABB. Retrieved from https://search-ext.abb.com/library/Download.aspx?DocumentID=8VZZ001892T0001&LanguageCode=en&DocumentPartId=&Action=Launch

Brewster, T. (2015, September 10). Forbes.Retrieved July 31, 2019, from https://www.forbes.com/sites/thomasbrewster/2015/09/10/vxworks-remote-code-vulnerability/

Gmuender, J. (2019, July 29). Wind River VxWorks and URGENT/11: Patch Now . (SONICWALL) Retrieved from https://blog.sonicwall.com/en-us/2019/07/wind-river-vxworks-and-urgent-11-patch-now/

Schneier, B. (2014, January 6). The Internet of Things is Wildly Insecure – and Often Unpatchable.Retrieved from WIRED: https://www.wired.com/2014/01/theres-no-good-way-to-patch-the-internet-of-things-and-thats-a-huge-problem/

Seri, B., Vishnepolsky, G., & Zusman, D. (2019). Critical vulnerabilities to remotely compromise VxWorks, the most popular RTOS. Armis, Inc.

SPACEX. (n.d.). Dragon Lab Fact Sheet. (SPACEX) Retrieved from https://www.spacex.com/sites/spacex/files/pdf/DragonLabFactSheet.pdf

Wind River Systems. (2016). VxWORKS – The Safe and Secure RTOS for the Internet of Things.Retrieved from https://www.windriver.com/products/product-overviews/2691-VxWorks-Product-Overview.pdf

1 As of June 30, 2019

2 From Forescout Research Labs

3 From Forescout Research Labs