Resource Library
Solution BriefsVisibilityRiskFebruary 14, 2024

Detect and Mitigate Ripple20 with ORDR

ORDR SECURITY BULLETIN · JUNE 2020

Ripple20 – How ORDR Can Help Detect and Mitigate These Vulnerabilities

Earlier this week, the cybersecurity firm JSOF published information on 19 vulnerabilities that affect many IoT devices. Specifically, JSOF discovered 19 vulnerabilities inside the Treck TCP/IP stack that is used by many device manufacturers and enables their devices to communicate over a network. The vendor list of vulnerable devices includes device manufacturers such as Baxter, Intel, Caterpillar, Cisco, Aruba, HP, and Xerox, that have all issued their own advisories and patches. However, the list of affected devices continues to grow as this vulnerability has been present inside the Treck stack for likely more than 20 years and implemented in thousands of devices since then. Organizations are now scrambling to assess their exposure by identifying any vulnerable assets in their inventory, and then respond by either patching or implementing compensating controls to protect at-risk devices.

ORDR Systems Control Engine (SCE) can:

  • Identify vulnerable assets impacted by Ripple20
  • Detect Ripple20 cyberattacks
  • Proactively protect devices from Ripple20 attacks
  • Take swift action when a Ripple20 attack is detected

Identifying Devices Vulnerable to Ripple20

ORDR exercises a combination of manufacturer advisories and proactive probing to track devices that are vulnerable to Ripple20. ORDR has curated a list of known vulnerable devices and will compare them to matching inventory in ORDR SCE customer environments automatically through our new Ripple20 feed service. This feed of vulnerable devices will be kept up to date and ensures organizations will be continually apprised for vulnerabilities as soon as the information is made available. Accompanying the Ripple20 feed service are links to the manufacturer's advisory as well as to any patches the vendors have made available to address the Ripple20 vulnerabilities. One major challenge is reliance on vendor identification and disclosure. Because the Ripple20 vulnerabilities have been present for 20 years, the affected device list is growing every day, and there are several major device manufacturers who are researching to see if any of their devices are vulnerable. Therefore, ORDR is also developing novel methods to proactively identify devices that are using the vulnerable Treck TCP/IP stack both passively and actively on the network.

In the ORDR SCE device dashboard, a device using the vulnerable Treck stack is automatically flagged, and the specific Ripple20 CVE (e.g., ICS4-20-168-03) is surfaced in that device's Known Vulnerabilities tab, together with a description of the flaw (Improper Handling of Length Parameter Inconsistency, Improper Input Validation, Double Free, Out-of-bounds Read, Integer Overflow, etc.) and a CVSS risk score of up to 10.0.

To help guarantee organizations can accurately identify any system vulnerable to Ripple20, whether it has been published or not, ORDR has built a Ripple20 active scanner incorporated into the ORDR SCE product. ORDR worked with the JSOF team to ensure our Ripple20 scans would accurately detect vulnerable versions of the Treck stack utilized by devices. ORDR's Ripple20 scanner dynamically identifies, or verifies, that a device is at risk. The Ripple20 scanner has minimal operational impact, and it can be tuned to only scan specific device types or areas of the network.

When devices are discovered that are vulnerable to Ripple20, either due to the feed service or the active scanner, they are listed inside the ORDR Security Dashboard, which surfaces incident totals across sessions exporting data, open external channels, external and internal communications, and infections/vulnerabilities, alongside a Device Risk Summary breaking devices out by Critical, High, Medium, Low, and Normal risk. A report can also be generated for auditing or reporting purposes from ORDR SCE.

Please note that ORDR SCE seamlessly integrates with external vulnerability assessment tools such as Tenable and Rapid7. Organizations using those tools to detect devices vulnerable to Ripple20 can integrate them into the ORDR SCE inventory and security dashboard. Additionally, ORDR can also transmit lists of vulnerable devices and device types back to external vulnerability assessment tools for a more aggressive scan, if wide scanning is not an option or if some devices will not react kindly to an aggressive scan.

Detect Active Exploitation of Ripple20

ORDR SCE has a built-in Network Intrusion Detection System (NIDS) engine which monitors traffic traveling throughout the network. Our NIDS rules have been updated to detect the Ripple20 vulnerability behavior. This is a distinct advantage over reliance on traditional firewalls that typically only monitor traffic coming through north-south, perimeter ingress/egress on the Internet edge. In order to exploit most of the Ripple20 vulnerabilities, attackers need to be on the same segment or in the same VLAN, rendering traditional perimeter-based firewall solutions ineffective. ORDR SCE monitors every device communication passively and checks against our NIDS rules. This generates instant alarms against devices that are being exploited, along with the attack vectors, such as devices that initiated attack, complete visibility of the attacking device, and retrospective record of communications during attack.

There are many NIDS CVEs that correspond to active Ripple20 attacks, as shown in the following table, and they are all included in the ORDR NIDS engine:

CVE

CVSSv3

Details

CVE-2020-11896

10

Remote Code Execution by sending multiple malformed IPv4 packets to a device supporting IPv4 tunneling.

CVE-2020-11897

10

Out-of-Bounds Write by sending multiple malformed IPv6 packets to a device.

CVE-2020-11901

9

Remote Code Execution by answering a single DNS request made from the device. This affects any device running the Treck TCP/IP stack with DNS support.

CVE-2020-11898

9.1

Improper handling of the Length Parameter Inconsistency in IPv4/ICMPv4 component.

CVE-2020-11900

8.2

Possible Double Free in IPv4 tunneling component

CVE-2020-11902

7.3

Improper Input Validation in IPV6OverIPv4 tunneling component

CVE-2020-11904

5.6

Possible Integer Overflow or Wraparound in Memory Allocation component

CVE-2020-11899

5.4

Improper Input Validation in IPv6 component

CVE-2020-11903

5.3

Possible Out-of-Bounds Read in DHCP component

CVE-2020-11905

5.3

Possible Out-of-Bounds Read in DHCPv6 component

CVE-2020-11906

5

Improper Input Validation in Ethernet link layer component

CVE-2020-11907

5

Improper Handling of Length Parameter Inconsistency in TCP component

CVE-2020-11909

3.7

Improper Input Validation in IPv4 component

CVE-2020-11910

3.7

Improper Input Validation in ICMPv4 component

CVE-2020-11911

3.7

Improper Access Control in ICMPv4 component

CVE-2020-11912

3.7

Improper Input Validation in TCP component

CVE-2020-11913

3.7

Improper Input Validation in IPv6 component

CVE-2020-11914

3.1

Improper Null Termination in DHCP component

CVE-2020-11908

3.1

Improper Null Termination in DHCP component

When an exploit attempt is detected, the security dashboard updates in real time and calls out the details of the issue, including the aggressor and target of the attack. Optionally, security incidents can be shared with Security Information and Event Management (SIEM) tools like Splunk, and workflow orchestration tools like ServiceNow and Nuvolo so they can tie into existing response and remediation processes.

Protect Vulnerable Devices

Organizations should contact their device manufacturer to obtain patches for Ripple20. If you have devices that cannot be patched in a timely fashion, ORDR SCE can implement microsegmentation as a compensating control to limit the surface area of attack while ensuring the device's continued operation.

Safeguards against compromise can be achieved by provisioning security policies with Access Control Lists (ACLs) based on device behaviors observed by ORDR SCE. The policy enforcement can be enabled directly from ORDR SCE and enforced through our integrations with network switches, wireless controllers, and sent to NAC solutions such as Cisco Identity Services Engine (ISE) or HPE Aruba ClearPass, or protected with zone-based security on next-generation firewalls including Palo Alto Networks, Check Point, Fortinet, and Cisco. In the case of Ripple20, ORDR SCE can automatically generate appropriate ACLs allowing the required communications and denying unnecessary access to devices that are vulnerable to Ripple20. This process is typically the most time-consuming part of an organization's security as it takes multiple efforts to combine device visibility and device behavior to build right security policies. ORDR automates this.

Take Swift Action

In cases where ORDR SCE sees suspicious activities from potentially compromised endpoints, the ORDR SCE operator can immediately initiate the remediation process by sending appropriate policy change to the network switches, connection infrastructure, or firewalls to isolate and quarantine offending devices. Sample remediations may include the use of enforcing quarantine Virtual LANs (VLANs) or denying network access to the compromised endpoint completely through blacklisting and/or shutting down the compromised endpoint's network port. This can be performed directly from ORDR SCE through our integrations or automated through NAC tools like Cisco ISE and HPE Aruba ClearPass.

Conclusion

Ripple20 vulnerabilities reinforce the challenges organizations face with connected IoT and OT devices. These threats also validate the need for proactive protection based on rich visibility of connected devices and their behavior to combat vulnerabilities like Ripple20 and for other vulnerabilities that are right around the corner.

Please contact the ORDR team for a demo and discussion on how to protect your assets from the never-ending vulnerability advisories.

ORDR — Take Control.

Contact: info@ordr.net  ·  www.ordr.net  ·  2445 Augustine Drive, Suite 601, Santa Clara, CA 95054

Frequently asked questions
How can I identify Ripple20-vulnerable devices in my network?
ORDR's Systems Control Engine uses passive discovery to automatically detect all Ripple20-vulnerable devices across your IoT infrastructure without active scanning. This real-time visibility enables you to immediately prioritize remediation efforts on affected assets.
Why is Ripple20 particularly critical for healthcare environments?
Ripple20 affects TCP/IP stacks in medical devices and IoT equipment, creating direct pathways to patient safety systems and sensitive data. In healthcare, these vulnerabilities can enable lateral movement across connected medical infrastructure, making early detection and containment essential.
What controls stop Ripple20 exploitation and lateral movement?
ORDR enforces micro-segmentation controls that isolate vulnerable devices and restrict unauthorized communication paths. Combined with continuous monitoring for active exploitation attempts, these controls prevent attackers from moving laterally even if a device is compromised.

This resource is published by ORDR, the connected asset security company. ORDR delivers AI-powered visibility, risk assessment, and automated protection for IoT, OT, and IoMT devices across healthcare, manufacturing, government, and financial environments. Browse all resources →

Ripple20 Detection & Mitigation for IoT Devices | ORDR | ORDR