These vulnerabilities will impact the IoT landscape for years to come
The JSOF research lab has discovered a series of zero-day vulnerabilities in a widely used low-level TCP/IP software library developed by Treck, Inc. The 19 vulnerabilities, given the name Ripple20, affect hundreds of millions of devices (or more) and include multiple remote code execution vulnerabilities. The risks inherent in this situation are high. Just a few examples: data could be stolen off of a printer, an infusion pump behavior changed, or industrial control devices could be made to malfunction. An attacker could hide malicious code within embedded devices for years. One of the vulnerabilities could enable entry from outside into the network boundaries; and this is only a small taste of the potential risks.
The interesting thing about Ripple20 is the incredible extent of its impact, magnified by the supply chain factor. The wide-spread dissemination of the software library (and its internal vulnerabilities) was a natural consequence of the supply chain “ripple-effect”. A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies, and people.
Ripple20 reached critical IoT devices from a wide range of fields, involving a diverse group of vendors. Affected vendors range from one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors suspected of being of vulnerable in medical, transportation, industrial control, enterprise, energy (oil/gas), telecom, retail and commerce, and other industries.
A detailed technical report of two of the vulnerabilities and their exploitation can be found in the CVE-2020-11896/CVE-2020-11898 whitepaper.
Risk Evaluation and Mitigations
Ripple20 poses a significant risk from the devices still in use. Potential risk scenarios include:
- An attacker from outside the network taking control over a device within the network, if internet facing.
- An attacker who has already managed to infiltrate a network can use the library vulnerabilities to target specific devices within it.
- An attacker could broadcast an attack capable of taking over all impacted devices in the network simultaneously.
- An attacker may utilize affected device as a way to remain hidden within the network for years
- A sophisticated attacker can potentially perform an attack on a device within the network, from outside the network boundaries, thus bypassing NAT configurations. This can be done by performing a MITM attack or a dns cache poisoning.
- In some scenarios, an attacker may be able to perform attacks from outside the network by replying to packets that leave network boundaries, bypassing NAT
In all scenarios, an attacker can gain complete control over the targeted device remotely, with no user interaction required.
JSOF recommends taking measures to minimize or mitigate the risk of device exploitation. Mitigation options depend on the context. Device vendors would have different approaches from network operators. In general, we recommend the following steps:
- All organizations must perform a comprehensive risk assessment before deploying defensive measures.
- First deploy defensive measures in a passive “alert” mode.
- Mitigation for device vendors:
- Determine if you use a vulnerable Treck stack
- Contact Treck to understand risks
- Update to latest Treck stack version (22.214.171.124 or higher)
- If updates are not possible, consider disabling vulnerable features, if possible
- Mitigation for operators and networks:
(based on CERT/CC and CISA ICS-CERT advisories)
- The first and best mitigation is updating to patched versions of all devices.
- If devices cannot be updated, the following steps are recommended:
- Minimize network exposure for embedded and critical devices, keeping exposure to the minimum necessary, and ensuring that devices are not accessible from the Internet unless absolutely essential.
- Segregate OT networks and devices behind firewalls and isolate them from the business network.
- Enable only secure remote access methods.
- Block anomalous IP traffic.
- Block network attacks via deep packet inspection, to reduce risk to your Treck embedded TCP/IP-enabled devices.
Pre-emptive traffic filtering is an effective technique that can be applied as appropriate to your network environment. Filtering options include:
- Normalize or block IP fragments, if not supported in your environment.
- Disable or block IP tunneling (IPv6-in-IPv4 or IP-in-IP tunneling), if not required.
- Block IP source routing, and any IPv6 deprecated features, like routing headers VU#267289
- Enforced TCP inspection, rejecting malformed TCP packets.
- Block unused ICMP control messages, such as MTU update and Address Mask updates.
- Normalize DNS through a secure recursive server or DNS inspection firewall. (Verify that your recursive DNS server normalizes requests.)
- Provide DHCP/DHCPv6 security, with features such as DHCP snooping.
- Disable/Block IPv6 multicast capabilities if not used in the switching infrastructure.
- Disable DHCP where static IPs can be used.
- Employ network IDS and IPS signatures.
- Employ network segmentation, if available.
Ripple20 is a set of 19 vulnerabilities found on the Treck TCP/IP stack . Four of the Ripple20 vulnerabilities are rated critical, with CVSS scores over 9 and enable Remote Code Execution. One of the critical vulnerabilities is in the DNS protocol and may potentially be exploitable by a sophisticated attacker over the internet, from outside the network boundaries, even on devices that are not connected to the internet.
A second Whitepaper, to be released following BlackHat USA 2020 will be detailing the exploitation of CVE-2020-11901, a DNS vulnerability, on a Schneider Electric APC UPS device. The other 15 vulnerabilities are in ranging degrees of severity with CVSS score ranging from 3.1 to 8.2, and effects ranging from Denial of Service to potential Remote Code Execution.
Most of the vulnerabilities are true Zero-days, with 4 of them having been closed over the years as part of routine code changes, but remained open in some of the affected devices (3 lower severity, 1 higher). Many of the vulnerabilities have several variants due to the Stack configurability and code changes over the years.
Ripple20 are the only vulnerabilities reported in Treck to date as far as we know, except for some general logical vulnerabilities referenced in the past which pertained to many stack implementations and usually had to do with RFC misinterpretations or deprecated RFCs.
Ripple20 vulnerabilities are unique both in their widespread effect and impact due to supply chain effect and being vulnerabilities allowing attackers to bypass NAT and firewalls and take control of devices undetected, with no user interaction required. This is due to the vulnerabilities being in a low level TCP/IP stack, and the fact that for many of the vulnerabilities, the packets sent are very similar to valid packets, or, in some cases are completely valid packets. This enables the attack to pass as legitimate traffic.
A white paper describing a third vulnerability and exploitation on the UPS will be released following Black Hat USA 2020.
More information and details about the vulnerabilities and affected vendors you find here.