Ripple20 – New Zero-Day Vulnerabilities Send Shockwaves Across IoT

Ripple20 – New Zero-Day Vulnerabilities Send Shockwaves Across IoT

JSOF Research Lab has uncovered a series of 19 zero-day vulnerabilities that could impact hundreds of millions of IoT devices. Collectively named “Ripple20,” the vulnerabilities were found in a Treck TCP/IP stack that is widely embedded in enterprise and consumer-grade products including transportation systems, power grids, industrial equipment and others.

There are two aspects that make these vulnerabilities especially concerning to pharma, manufacturing, transportation and other critical infrastructure organizations:

  1. The impact that can be achieved through their exploitation. In fact, an attacker could gain unauthorized access to vulnerable devices executing arbitrary code remotely.
  2. The extreme difficulty in finding and patching all instances of the vulnerable library due to the large number of impacted products and a complex, untracked software supply chain. The vulnerable library could potentially be deployed across several products, and companies may not be aware they are using it.

I want to reassure Nozomi Networks customers that our solutions do not use the 3rd party products identified, and so are not at risk from the Ripple20 vulnerabilities. However, because these vulnerabilities are so important to the industries we serve, we are sharing our initial analysis of them.

Ripple20 Technical Analysis & Mitigation Tactics

While all 19 vulnerabilities should be addressed with appropriate patches or mitigations, there are four in particular that security teams should prioritize given their high rating on the U.S. Department of Homeland Security’s CVSSv3 vulnerability severity scale. Network administrators should also verify that the mitigations offered are suitable for each network configuration. The four vulnerabilities that should be addressed ASAP include:

CVE-2020-11896

  • Description: Remote code execution triggered by an attacker that can reach the vulnerable device through an open UDP port. The vulnerability details and its exploitation strategy has been detailed extensively in publicly-available paper.
  • Mitigation: Disable IP-in-IP tunneling (IP protocol number 4).
  • CVSSv3: 10

CVE-2020-11897

  • Description: Remote code execution triggered by an attacker that can send multiple malformed IPv6 packets to a vulnerable device.
  • Mitigation: Disable IP source routing, including IPv6 source routing – Routing Header Type 0, deprecated by RFC-5095.
  • CVSSv3: 10

CVE-2020-11898

  • Description: An attacker can get the vulnerable device to leak heap memory, and use it to bypass exploit mitigations, such as ALSR. The vulnerability details and its exploitation strategy has been detailed extensively in a publicly-available paper.
  • Mitigation: Disable IP-in-IP tunneling (IP protocol number 4).
  • CVSSv3: 9.1

CVE-2020-11901

  • Description: Remote code execution triggered by an attacker that can answer to a single DNS request initiated by a vulnerable device. A non-public proof of concept targeting Schneider Electric APC UPS was developed by JSOF researchers.
  • Mitigation: Normalize DNS responses through DNS deep packet inspection or with a secure DNS recursion server.
  • CVSSv3: 9

Ripple20 Vulnerabilities Impact & Mitigation Summary

The following table is a summary of all the vulnerabilities included in Ripple20. The technical details of some CVEs have not been documented extensively and thus are considered partial, although taking into account the associated CVSSv3 score, their security impact is likely limited. The Nozomi Networks Labs team will update this reference as more details become available.

The data presented below has been compiled from publicly-available material from JSOF and the CERT Coordination Center, with the goal of providing a cohesive overview of Ripple20. In looking at how the vulnerabilities affected different versions of the library, we can appreciate the significant efforts of all those involved in tracking and patching the discovered issues.

CVE-2020-XXXXX CVSS v3 First patched version Description Impact Mitigation
11896 10 6.0.1.66, released on 30/03/2020 Improper handling of length parameter inconsistency in IPv4/UDP  Remote code execution Disable or block IP fragmented packets or IP in IP tunneling.
11897 10 5.0.1.35, released on 04/06/2009 Improper handling of length parameter inconsistency in IPv6 Remote code execution Can be mitigated by blocking various IP source routing, including IPv6 source routing – Routing Header Type 0 that has been deprecated by RFC-5095, see also VU#267289.
11898 9.1 6.0.1.66, released on 03/03/2020 Improper handling of length parameter inconsistency in IPv4/ICMPv4 component Possible exposure of sensitive information Disable or block IP in IP tunneling.
11899 5.4 6.0.1.66, released on 03/03/20 Improper input validation in IPv6 component Out-of-bounds read / DoS  Drop IPv6 packets addressed to multicast destination ff00::/8.
11900 8.2 6.0.1.41, released on 10/15/2014 Double free in IPv4 tunneling  Possible use after free  Disable or block IP in IP tunneling.
11901  9.0 6.0.1.66, released on 03/03/2020 Improper input validation in DNS resolver component Remote code execution Normalize DNS responses through DNS deep packet inspection or with a secure DNS recursion server.
11902 7.3 6.0.1.66, released on 03/03/20 Improper input validation in IPv6 over IPv4 tunneling Possible exposure of sensitive information (Out-of-bounds read)  Disable IPv6 over IPv4 tunneling.
11903  5.3  6.0.1.28, released on 10/10/12 Out-of-bounds read in DHCP component Possible exposure of sensitive information (Out-of-bounds read)  Disable DHCP clients, ensuring the DHCP relay option (RFC3046) is not enabled, and the local area network switch has capabilities such as DHCP-snooping to reduce risk of DHCP abuse on the target device.
11904 5.6  6.0.1.66, released on 03/03/2020 Integer overflow in memory allocator, when handling network packets Possible out-of-bounds write
11905 5.3 6.0.1.66, released on 03/03/2020 Out-of-bounds read in DHCPv6 component  Possible exposure of sensitive information (out-of-bounds read)  Disable DHCPv6 clients, ensuring the DHCP relay option (RFC3046) is not enabled, and the local area network switch has capabilities such as DHCP-snooping to reduce risk of DHCP abuse on the target device.
11906 5.0 6.0.1.66, released on 03/03/2020 Improper input validation in ethernet link layer component Integer underflow Proper OSI layer 2 equipment should discard malformed frames.
11907 5.0 6.0.1.66, released on 03/03/2020 Improper handling of length parameter inconsistency in TCP component resulting in an integer underflow Integer underflow Disable or block IP fragmented packets.
11908 3.1 4.7.1.27, released on 11/08/07 Improper null termination in DHCP component Possible exposure of sensitive information Blocking rogue DHCP servers.
11909 3.7 6.0.1.66, released on 03/03/2020 Improper input validation in IPv4 component Integer underflow Block IPv4 source routing.
11910 3.7 6.0.1.66, released on 03/03/2020 Improper input validation in ICMPv4 component Out-of-bounds read Block ICMP messages with type 3, code 4.
11911 3.7 6.0.1.66, released on 03/03/2020 The affected product is vulnerable to improper access control, which may allow an attacker to change one specific configuration value Out of bounds read Block ICMP messages with type 18, code 0.
11912 3.7 6.0.1.66, released on 03/03/2020 Improper input validation in TCP component Out-of-bounds read Can be mitigated by a firewall device or NAT device that inspects TCP SACK (Select acknowledgement) and TCP timestamp options, rejecting any malformed packets.
11913 3.7 6.0.1.66, released on 03/03/2020 Improper input validation in IPv6 component Out-of-bounds read Reject runt or otherwise malformed ethernet frames.
11914 3.1 6.0.1.66, released on 03/03/2020 Improper input validation in ARP component Out-of-bounds read Reject runt or otherwise malformed ethernet frames.

Although the table above proposes specific mitigations for each vulnerability, more generic strategies will definitely help limit the risk. For instance, infrastructure operators should minimize the number of embedded devices accessible to the internet as this poses an intrinsic risk. OT networks should be properly segregated and not reachable from the outside. Firewalls should be used to block ICMP, TCP, DNS, DHCP and ARP traffic originating from any unauthorized sources.

Vendors Affected by Ripple20 Vulnerabilities

While a more complete list of affected vendors and products will likely be made available as new information arises, JSOF, with the help of several national computer emergency response teams (CERT), has already reached out to the companies believed to be embedding the vulnerable library in their products. Considering that many vendors are urgently working on the updates, we recommend that concerned organizations consult with the security advisories of the products they have deployed.

At the time of writing, the following vendors are confirmed to be affected:

How to Protect Your OT/IoT Networks

Nozomi Networks Labs is currently analyzing the technical data related to Ripple20 vulnerabilities, and as more information becomes available, will extend the detection coverage available in our Threat Intelligence service.

Network operators should determine whether the network under management contains vulnerable devices. Considering the unique requirements of each configuration, operators should also consider deploying the mitigations proposed for cases where a security update is not yet available.

References: