This post was updated on March 3, 2020.
A well-known RTOS (Real-Time Operating System), widely used in critical infrastructure sectors such as health care, transportation, aviation and other industrial operations, is affected by a series of 11 vulnerabilities dubbed URGENT/11.
First reported and analyzed by an IoT security vendor, Armis*, and further described by VxWorks incident response, the vulnerabilities are particularly notable because they allow attackers to take over devices without user interaction. Also, they can be exploited using worms that spread very quickly, and they expose critical sectors to attack.
While four publicly threat signatures for URGENT/11 were released quickly, these signatures can result in many false positives when used in industrial networks that contain legacy devices. To help our customers avoid this problem, Nozomi Networks Labs didn’t immediately incorporate the signatures into our Threat Intelligence. Instead, we conducted laboratory research on the vulnerable devices, and quickly developed our own signatures to identify exploits related to all 11 vulnerabilities that would work accurately in industrial environments as well as they do in more traditional IT settings.
Read on to learn about our URGENT/11 research and how Threat Intelligence helps ICS operators identify threats without investing unnecessary time and attention on false positives.
URGENT/11 Vulnerabilities – What Are They and Why Are They Important?
The VxWorks RTOS affected by URGENT/11 is used by more the 2 billion(!) devices in critical industrial, medical and enterprise devices. The vulnerabilities were reported to reside in VxWorks’ TCP/IP stack (IPnet), impacting all versions since version 6.5.
Note that some versions of VxWorks are NOT affected. These are:
- VxWorks, version 7 released on July 19, 2019, which contains fixes for the discovered vulnerabilities
- VxWorks 653 and VxWorks Cert Edition, versions of the products designed for safety certification and used by selected critical infrastructure industries such as transportation
For the VxWorks versions 6.5 and later that are affected:
- Six of the vulnerabilities are classified as critical and enable Remote Code Execution (RCE)
- Five of the vulnerabilities are classified as denial of service, information leaks or logical flaws
The vulnerabilities are extremely serious because:
- They allow attackers to take over devices without any user interaction, and also bypass perimeter security devices such as firewalls and NAT solutions
- The vulnerabilities are ‘wormable’, which means that they can be used to propagate malware into and within networks
- They impact devices such as SCADA, elevator and industrial controllers, patient monitors and MRI machines, as well as firewalls, routers, modems, VOIP phones and printers
- They could potentially have a wider impact, as IPnet (VxWorks’ TCP/IP stack) was used in other operating systems prior to VxWorks acquisition by Wind River in 2006
An attack based on an URGENT/11 exploit could have severe and widespread consequences, resembling that of the EternalBlue vulnerability, used to spread the WannaCry malware.
URGENT/11 – Why Are Publicly Available Threat Signatures Not Overly Helpful for ICS?
After the initial discovery of the URGENT/11 vulnerabilities, several weak and false positive-prone detection signatures were published online. Most were likely designed to detect pre-conditions of the exploitation phase, but the results are too generic for use in widely ranging, heterogeneous networks. In such an environment, they could raise too many false positives to be actionable.
Although the disclosure of the URGENT/11 vulnerabilities warns the ICS community to increase the security level of critical devices, they require an efficient and accurate method of detecting exploits to be useful. The challenge is that the issues related to the vulnerabilities rely on an unexpected mix of TCP/IP flags and options.
The only publicly available signatures are SNORT rules that include a set of four signatures aimed at detecting the potential malicious use of the URGENT/11 vulnerabilities.
alert ip any any -> any any (ipopts: ssrr; msg: "OS-VXWORKS Use of SSRR option, potential attempt to exploit an Urgent11 RCE vulnerability"; reference:cve,2019-12256; classtype:attempted-admin; reference:url,armis.com/urgent11; rev: 1; sid:1000004)
Example of URGENT/11 SNORT rule*.
URGENT/ 11 – How Can False Positives Be Reduced for ICS?
The Nozomi Networks Labs team is committed to creating highly effective rules for our Threat Intelligence. As such, we feel that it’s very important to conduct our own research into significant vulnerabilities, rather than ingest sometimes unproven rules from external sources.
(Note that the research describe below was done exclusively on VxWorks RTOS, we have no information of whether other RTOS’ are impacted.)
We specifically evaluated the published SNORT rules* and felt that while they are suitable for use by network defenders in their own IDS, there was room for improvement in their accuracy in heterogenous networks.
Let’s consider some examples of the signatures:
alert tcp any any -> any any (flags: U+; msg: "OS-VXWORKS - Use of Urgent Flag might indicate potential attempt to exploit an Urgent11 RCE vulnerability"; classtype:attempted-admin; reference:cve,2019-12255; reference:cve,2019-12260; reference:cve,2019-12261; reference:cve,2019-12263; reference:url,armis.com/urgent11; rev: 1; sid:1000002)
As described in the technical white paper*, a first common indicator for four of the most critical vulnerabilities is the abuse of the TCP’s Urgent Flag for triggering the Urgent Pointer mechanism.
- CVE-2019-12255
- CVE-2019-12260
- CVE-2019-12261
- CVE-2019-12263
Below is a quote from the RFC 6093:
TCP implements an “urgent mechanism” that allows:
- The sending user to incite the receiving user to accept some “urgent data”
- That permits the receiving TCP to indicate to the receiving user when all currently known “urgent data” has been read
We can assume from RFC 6093 that this approach is used when communicating with applications that need an immediate response (e.g. Telnet). Based on the evolution of modern networks, this mechanism is no longer recommended, even in RFC 6093 itself. But, we have to keep in mind that an OT infrastructure is likely to have lots of legacy devices and systems working together. Thus, it’s highly likely that in an industrial network, a lot of “urgent data” messages are being sent.
As Nozomi Networks focuses on industrial infrastructure, we decided not to implement a signature that could trigger many false positives. Note that the original research team calls out this problem themselves in their white paper:
The above rule can cause some false positives, in the rare case when a legitimate TCP connection uses the Urgent Pointer (such as RLOGIN connections, or certain TELNET clients).
Statement regarding false positives.
Then we examined the signature used for detecting a malicious use of the LSRR option in the TCP header:
alert ip any any -> any any (ipopts: lsrr; msg: "OS-VXWORKS Use of LSRR option, potential attempt to exploit an Urgent11 RCE vulnerability"; reference:cve,2019-12256; classtype:attempted-admin; reference:url,armis.com/urgent11; rev: 1; sid:1000003)
The Loose Source and Record Route (LSRR) option is rarely used. Its main function is to let the originating system specify a number of intermediate systems a packet must pass through to get to the destination host. In addition, the route followed by the packet is recorded in the option. The receiving host (end-system) must use the reverse of the path contained in the received LSRR option.
As we can understand from RFC 7126, this option has well-known security implications. It can be used to:
- Bypass firewall rules
- Reach otherwise inaccessible internet systems
- Establish TCP connections in a stealthy way
- Learn about the topology of a network
- Perform bandwidth-exhaustion attacks
However, at the same time there are some situations where the use of this option is required, for example, when conducting network troubleshooting.
Thus the detection of URGENT/11 without adequate sanity checks can lead to numerous false positives. We don’t want industrial operators to lose precious time and focus investigating unnecessary false positives, so we developed new signatures in Threat Intelligence that minimize false positives for industrial networks.
URGENT/11 – What Is a Good Way to Detect Exploits in ICS?
Nozomi Networks Labs is constantly working to effectively detect this type of attack scenario by adding new signatures to Threat Intelligence and improve its detection engine.
Our curated vulnerability database identifies vulnerable assets and supports patch management activities. We also provide accurate and high performing signatures for the precise detection of real-time exploitation attempts.
During our first analysis, we focused our attention on devices exposing VxWorks-related services. We discovered that many devices run this type of RTOS by searching on Shodan and similar search engines (i.e. FoFa pro and ZoomEye).
Given that type of operating system is widely used across different sectors (industrial, aviation, health care, etc.), Nmap is a well-known port scanning tool used for network mapping that gathers as much information as possible while conducting a network assessment. Its script engine allows us to extend its functionality to look for potentially vulnerable assets in a network. Then, based on the vulnerability detected, it identifies associated CVE(s).
Following is an example of the results:
However, even if the Nmap NSE script approach can identify potential vulnerable devices, we’re aware that it’s not easy to detect which version of VxWorks a device is running, and for some OT devices, the OS itself.
We are sharing our Nmap NSE script with the ICS and security research community on GitHub. While it can be used to detect URGENT/11 vulnerabilities, it is intended as a research tool and as a fast way to check systems. For comprehensive and regularly updated ICS threat intelligence that is correlated with other behaviors in an ICS, we recommend full featured security products such as our Guardian and Threat Intelligence solution.
For example, using our solution we’re able to detect some pre-conditions related to URGENT/11 vulnerabilities. And, thanks to Guardian’s Deep Packet Inspection analysis and real-time process analytics engine, we raise alerts only when illegal TCP/IP packets are detected.
URGENT/ 11 – New ICS Threat Signatures from Nozomi Networks Labs
Those involved in the safety, security and reliability of industrial operations should evaluate their network for exposure to risk from URGENT/11. An attack that exploits one of its vulnerabilities could allow threat actors to take over devices without user interaction. The attack could spread very quickly, and it could cause significant operational disruption.
Nozomi Networks customers using Guardian with Threat Intelligence automatically receive our threat signatures. They are also alerted if indicators of compromise are identified. An initial batch of threat signatures have been delivered, and more are under development for release this month
If you would like to learn more about how Threat Intelligence helps organization stay on top of the dynamic threat landscape, simply contact us.
