Get notifications!

Ripple20: Why this Latest Bundle of Related CVEs Is Making Waves

Yesterday CISA released an advisory for nineteen previously unknown vulnerabilities affecting Treck's embedded TCP/IP stack (also known as a network stack). This disclosure was the result of some very meticulous and dedicated research on the part of JSOF, beginning in September 2019.

After the initial discovery of these zero-days, JSOF contacted both Treck and the relevant authorities to report the vulnerabilities. They then began the process of validation and multilateral coordination that ultimately resulted in public disclosure.

In March 2020, Treck issued a confidential security advisory and patch to device and component manufacturers using its TCP/IP stack technology. When all the ts were crossed and is dotted, the vulnerabilities were bundled together in CISA advisory ICSA-20-168-01 and released to the wider public on June 16, 2020.

When referred to as a group, the 19 vulnerabilities reflected in the CISA advisory are called "Ripple20".

In the lead up to the CISA advisory, JSOF enlisted the assistance of select cybersecurity companies and device vendors. CyberMDX is proud to have played a role assisting with the validation of these vulnerabilities and in confirming specific devices affected.

Background

The Ripple20 vulnerabilities exist in the network stack created by a company named Treck and used by a large number of IoT devices and embedded components.  

Listed in the table below are the 19 vulnerabilities, enriched with basic risk and fix details:

CVE Num.

CVSS

Vuln. Component

Pot. Attack Outcome

Fixed Versions

Fix Date

CVE-2020-11896

10

IPv4/UDP

Remote Code Execution

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11897

10

IPv6

Out-of-Bounds Write

Version 5.0.1.35 and onward

04/06/09

CVE-2020-11898

9.1

IPv4/ICMPv4

Exposure of Sensitive Information

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11899

5.4

IPv6

Out-of-bounds Read and Denial of Service.

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11900

8.2

IPv4 tunneling

Use After Free

Version 6.0.1.41 and onward

10/15/14

CVE-2020-11901

9

DNS resolver

Remote Code Execution

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11902

7.3

IPv6OverIPv4

Out-of-bounds Read

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11903

5.3

DHCP

Exposure of Sensitive Information 

Version 6.0.1.28 and onward

10/10/12

CVE-2020-11904

5.6

Memory allocation

Out-of-Bounds Write

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11905

5.3

DHCPv6

Exposure of Sensitive Information

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11906

5

Ethernet Link Layer

Integer Underflow

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11907

5

TCP length handling

Integer Underflow

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11908

3.1

DHCP

Exposure of Sensitive Information

Version 4.7.1.28 and onward

11/08/07

CVE-2020-11909

3.7

IPv4

Integer Underflow

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11910

3.7

ICMPv4

Out-of-bounds Read

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11911

3.7

ICMPv4

Incorrect Permission Assignment for Critical Resource

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11912

3.7

TCP

Out-of-bounds Read

Version 6.0.1.67 and onward

03/30/20

CVE-2020-11913

3.7

IPv6

Out-of-bounds Read

Version 6.0.1.67 and onward

06/12/20

CVE-2020-11914

3.1

ARP

Out-of-bounds Read

Version 6.0.1.67 and onward

03/30/20

Across all 19 vulnerabilities contained in the Ripple20 bundle, the common thread uniting them — beyond their shared point of discovery and presence in Treck's TCP/IP stack — is the fact that they can all be exploited by a malicious actor with minimal requirements and skill.

To demonstrate the viability of Ripple20 as a means of attack, researchers from JSOF have developed a proof-of-concept for CVE-2020-11896 that not only performs the described overflow, but also uses it in order to remotely execute arbitrary code on a Digi Connect network device.

For more information on these vulnerabilities, including technical details, please see our vulnerability report here

Devices Affected By Ripple20

Because the Ripple20 vulnerabilities exist in a network stack implementation that many manufacturers build directly into their devices or integrate by way of embedded third-party components, the exposed attack surface is potentially enormous; possibly on par with the  URGENT/11 vulnerability. And since most manufacturer's don't maintain a granular accounting of the technological dependencies of their embedded components, it also represents a dimension of risk exposure that can be very difficult to accurately gauge.

Unfortunately, the picture isn't made a whole lot clearer on the user end. Since the network stack is implemented independent of the operating system (the stack can be used with or without a RTOS), it can be difficult to identify from the viewpoint of standard endpoint tracking tools or publicly broadcast device details. As such, assessing whether or not a given device is subject to these vulnerabilities will be a challenge. 

Advanced-threat-detection-and-related-cvesIn facing this challenge, best-in-class organizations will call on advanced vulnerability and threat detection tools such as the CyberMDX solution to profile devices and identify exposure on the basis network communication behavior patterns. With sufficiently granular and panoramic visibility, an appropriately context-aware interpretation model and robust supporting dataset, a behavior-based monitoring is uniquely qualified to identify endpoints using the Treck network stack.

In the shared effort to prepare and protect the technology world for the disclosure of Ripple20, CyberMDX contributed its advanced endpoint visibility capabilities, medical network expertise, and dataset to help identify affected devices commonly found in hospitals.

Among the range of devices already confirmed vulnerable are the following popular products:

Indeed, the healthcare industry appears to be particularly vulnerable to Ripple20, with estimated exposure more than 7X the size of the manufacturing industry.

You can find a more extensive list of affected healthcare products here. At the same time though, it should be noted that for every vendor confirmed affected, there are three more currently under investigation. As such, if you suspect the vulnerability of a given product or are otherwise seeking further information, you are advised to contact your device vendors or reach out to CyberMDX

Patching

Though Treck released a new version of its software (6.0.1.67) that fixes the security flaws on which Ripple20 is predicated, it must be noted that Treck cannot directly update devices. Treck supplies vendors a development kit for them to use when they package network stacks for their products. Until vendors use that kit to develop product firmware updates, devices cannot be “patched”. 

In some cases, vendors will design their products to automatically and remotely receive these patches. In other cases, user interaction will be required to trigger an update. In other cases, the vendor will need to dispatch a technician to physically arrive on premise and install the patch. 

In all instances, user follow up is imperative. First to understand what is required, then to coordinate as needed with the vendor, and finally to see the process through to completion.

Mitigation

In the event that the vulnerability of a given device or product line is suspected but hasn't been confirmed, or the vendor hasn't incorporated the updates provided by Treck into their products, mitigation will be required.

This may be complicated by the fact that the vulnerabilities relate specifically to embedded devices. These devices lack traditional operating systems and are generally designed in a leaner manner to serve more task-specific purposes. As such, they are mostly unmanaged, which is to say that they cannot support traditional endpoint agents.

In any event, the first step should always be to contact the vendors of affected devices to arrange for firmware upgrades based on version 6.0.1.67 and up of Treck's network stack.

call-your-device-vendors-manufacturers-for-ripple20-patch-1

While you wait for something to materialize from your vendor-facing conversations, there are a number of immediate actions that can and should be taken. These include:

  • Asking the following questions and, according to the relevant answers, applying the prescribed policies to your network firewalls / IDSs –
    • Do your affected devices need IP tunneling?
      • If not, drop all incoming tunneled packets.
      • If yes, perhaps you can drop specific unnecessary tunneling methods such as IP-in-IP ? PIV6-in-IPV4?
    • Do your affected devices make use of IPV6?
      • If not - drop all incoming IPV6 packets.
      • If yes - can you drop specific packets like IPv6 multicast? IPv6 routing headers?
  • Dropping unused ICMP control messages such MTU Update and Address Mask updates
  • Normalizing DNS through a secure recursive server or DNS inspection firewall
  • Referring to the Suricata IDS detection signatures published here and cross referencing against the traffic in your network environment – making sure to immediately upon detection terminate any associated workloads and initiate quarantine procedures for affected endpoints.

Since these policies could rarely but possibly impact the normal functioning of certain network devices, it is best to apply them only to the inbound communications of Treck-based devices and start from a permissive mode (logging violations instead of blocking them) before moving on to an enforcement capacity.

Vulnerabilities Are Bad, But These May Augur Something Good 

When JSOF discovered these vulnerabilities, they did something truly remarkable: they proactively brought other cybersecurity and research companies into the fold. They refused to let their thinking be dominated by ego or business interests and resolved to manage the investigation and disclosure process in whatever way was best for the public good.

Among other parties, this collaboration brought would-be competitors CyberMDX and Forescout together, working in common purpose to accelerate and ease the identification of affected devices, as well as to manage and mitigate associated risk. This type of collaboration is highly unusual and tremendously positive.

It is our sincere hope that these bold steps serve as inspiration for a larger trend to come; one in which all cybersecurity stakeholders think big, think responsibly, and think collectively in pursuit of the greater good.

Further Risk Assessment & Mitigation Assistance

CyberMDX works closely with medical device manufacturers and the healthcare community to investigate and ameliorate cyber vulnerabilities. We also work to harden hospital security through cyber intelligence that automates context-aware device profiling and combines it with tailored risk assessment and remediation.

We want to learn about the unique cyber risk management challenges facing your healthcare organization and are eager to help in any way we can — including a no strings attached free consultation.

For further risk assessment and mitigation assistance pursuant to Ripple20 or any other concern, please contact us today.

Comments