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:
- The impact that can be achieved through their exploitation. In fact, an attacker could gain unauthorized access to vulnerable devices executing arbitrary code remotely.
- 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.
While all Ripple20 vulnerabilities should be addressed with appropriate patches or mitigations, four of the vulnerabilities should be prioritized due to their high severity score.
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:
- 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
- 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
- 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
- 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||188.8.131.52, 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||184.108.40.206, 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||220.127.116.11, 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||18.104.22.168, 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||22.214.171.124, released on 10/15/2014||Double free in IPv4 tunneling||Possible use after free||Disable or block IP in IP tunneling.|
|11901||9.0||126.96.36.199, 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||188.8.131.52, 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||184.108.40.206, 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||220.127.116.11, released on 03/03/2020||Integer overflow in memory allocator, when handling network packets||Possible out-of-bounds write|
|11905||5.3||18.104.22.168, 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||22.214.171.124, 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||126.96.36.199, 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||188.8.131.52, released on 11/08/07||Improper null termination in DHCP component||Possible exposure of sensitive information||Blocking rogue DHCP servers.|
|11909||3.7||184.108.40.206, released on 03/03/2020||Improper input validation in IPv4 component||Integer underflow||Block IPv4 source routing.|
|11910||3.7||220.127.116.11, 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||18.104.22.168, 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||22.214.171.124, 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||126.96.36.199, 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||188.8.131.52, 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:
- B. Braun – https://www.bbraunusa.com/en/products-and-therapies/customer-communications.html
- Caterpillar – https://www.cat.com/en_US/support/technology/connected-solutions-principles/security/caterpillar-cybersecurity-advisory.html
- HP – https://support.hp.com/us-en/document/c06640149
- Maxlinear (through HLFN)
- Rockwell –https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1126896/loc/en_US#__highlight
- Sandia National Labs
- Schneider Electric/APC – https://www.se.com/ww/en/download/document/SESB-2020-168-01/
- Digi – https://www.digi.com/support/knowledge-base/digi-international-security-notice-treck-tcp-ip-st
- HCL Tech – https://www.hcltech.com/software/psirt
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.
Related Content to Download
Read this document to learn about how Threat Intelligence:
- Makes it easy to detect threats identify vulnerabilities
- Notably reduces time to detection, minimizing impacts
- Speeds response with prioritized alerts and actionable insights
Supply Chain and Persistent Ransomware Attacks Reach New Heights
- 7 trends defining today’s threat landscape
- 18 specific threats you need to know about
- Recent vulnerability research and exploitation trends
- 7 types of vulnerabilities under active exploitation
- 10 recommendations for securing OT/IoT networks
- Blog: URGENT/11 Nmap NSE Script for Detecting Vulnerabilities
- Blog: Dark Nexus IoT Botnet: Analyzing and Detecting its Network Activity
- Blog: Covid-19 Chinoxy Backdoor: A Network Perspective
- Webpage: COVID-19 Malware: Community Support
- Webinar: The Emerging Threat Intel: How Hackers are Using COVID-19
- Podcast: Remote Access Monitoring: What to Watch Out for During the COVID-19 Pandemic
- GitHub: Snort Rule for Detecting Chinoxy Backdoor Malware Infections
- GitHub: COVID-19-Themed Network Indicators
- GitHub: Yara rules for detecting coronavirus ransomware
- GitHub: Yara rules for detecting COVID-19 Informer malware
- Webpage: Nozomi Networks Guardian
- Webpage: Nozomi Networks Threat Intelligence
Security Research Manager, Nozomi Networks
Alessandro Di Pinto is an Offensive Security Certified Professional (OSCP) with an extensive background in malware analysis, ICS/SCADA security, penetration testing and incident response. He holds GIAC Reverse Engineering Malware (GREM) and GIAC Cyber Threat Intelligence (GCTI) certifications. Alessandro co-authored the research paper “TRITON: The First ICS Cyber Attack on Safety Instrument Systems” and “Analyzing the GreyEnergy Malware: from Maldoc to Backdoor”.