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 |