Ripple20 - Dangerous vulnerability discovered in countless devices
Nozomi
Researchers from the Israeli security company JSOF have discovered 19 security holes in the low-level TCP/IP software library of the company Treck, which can be exploited to either steal or manipulate data with little effort. Complete control over a device is also possible. The vulnerabilities have a CVSSv3 score of up to 10, which corresponds to a remote code execution vulnerability. This means that arbitrary code can be executed on a device remotely, i.e. via the internet, without any activity on the part of the user/operator being required.
Corresponding CVEs are:
| CVE ID | CSSv3 Value | Description |
| CVE-2020-11896 | 10 | This vulnerability can be exploited by sending multiple malformed IPv4 packets to a device that supports IPv4 tunneling. It affects any device running Trek with a specific configuration. It can allow stable remote code execution and has been demonstrated on a Digi International device. Variants of this vulnerability can be exploited to cause a persistent denial of service requiring a hard reset of the device. |
| CVE-2020-11897 | 10 | This vulnerability can be exploited by sending multiple malformed IPv6 packets to a device. It affects any device running an older version of Treck with IPv6 support. It can potentially allow remote code execution. |
| CVE-2020-11901 | 9 | This vulnerability can be exploited by responding to a single DNS request from the device. It affects any device running Treck with DNS support and has been demonstrated to be able to be used for remote code execution on a Schneider Electric APC UPS. Despite a CVSS score of 9.0, this is one of the most serious vulnerabilities because DNS requests can leave the network where the device resides and a sophisticated attacker can use this vulnerability to take over a device from outside the network through DNS cache poisoning or other methods. This allows an attacker to infiltrate the network and take over the device bypassing all security measures. |
| CVE-2020-11898 | 9,1 | The malformed package is almost fully RFC compliant, so it will likely be difficult for security products such as firewalls to detect this vulnerability. On very old versions of the trek stack still running on some devices, the transaction ID is not randomised, making the attack easier. |
| CVE-2020-11900 | 8,2 | Improper handling of length parameter inconsistency (CWE-130) in the IPv4/ICMPv4 component when handling a sent packet from an unauthorised network attacker. Possible disclosure of sensitive information (CWE-200). |
| CVE-2020-11902 | 7,3 | Possible Double Free (CWE-415) in the IPv4 tunnel component when handling a sent packet from a network attacker. Use after Release (CWE-416) |
| CVE-2020-11904 | 5,6 | Incorrect input validation (CWE-20) in IPv6OverIPv4 tunneling component when handling a sent packet from an unauthorized network attacker. Possible out-of-bounds reading (CWE-125). |
| CVE-2020-11899 | 5,4 | Possible integer overflow or wraparound (CWE-190) in the memory allocation component when handling a packet sent by an unauthorised network attacker Possible out-of-bounds write (CWE-787) |
| CVE-2020-11903 | 5,3 | Incorrect input validation (CWE-20) in IPv6 component when handling a sent packet from an unauthorised network attacker . Possible out-of-bounds read (CWE-125) and possible denial of service. |
| CVE-2020-11905 | 5,3 | Possible out-of-bounds read (CWE-125) in the DHCP component when handling a packet sent by an unauthorised network attacker. Possible disclosure of sensitive information (CWE-200). |
| CVE-2020-11906 | 5 | Improper input validation (CWE-20) in the Ethernet link layer component from a packet sent by an unauthorised user. Integer underflow (CWE-191) |
| CVE-2020-11907 | 5 | Improper handling of length parameter inconsistency (CWE-130) in the TCP component from a packet sent by an unauthorised network attacker. Integer Underflow (CWE-191) |
| CVE-2020-11909 | 3,7 | Incorrect input validation (CWE-20) in IPv4 component when handling a sent packet from an unauthorised network attacker. Integer Underflow (CWE-191) |
| CVE-2020-11910 | 3,7 | Incorrect input validation (CWE-20) in the ICMPv4 component when handling a sent packet from an unauthorised network attacker. Possible out-of-bounds read (CWE-125). |
| CVE-2020-11911 | 3,7 | Illegal access control (CWE-284) in the ICMPv4 component when handling a sent packet from an unauthorised network attacker. Incorrect permission assignment for critical resource (CWE-732). |
| CVE-2020-11912 | 3,7 | Incorrect input validation (CWE-20) in the TCP component when handling a sent packet from an unauthorised network attacker. Possible out-of-bounds read (CWE-125). |
| CVE-2020-11913 | 3,7 | Incorrect input validation (CWE-20) in IPv6 component when handling a sent packet from an unauthorised network attacker. Possible Out-of-Bounds Reading (CWE-125) |
| CVE-2020-11914 | 3,1 |
Improper input validation (CWE-20) in the ARP component when handling a sent packet from an unauthorised network attacker. |
| CVE-2020-11908 | 3,1 |
Illegal null termination (CWE-170) in the DHCP component when handling a sent packet from an unauthorised network attacker. |
The vulnerabilities were fixed in version 6.0.1.67 of the software library, which was released on 3 March 2020. Unfortunately, it is usually not possible for end users to update this software library themselves. A manual update on the part of the manufacturer is required here.
Which devices are affected by Ripple20?
This is a good question, to which there is unfortunately not yet a sufficient answer. Basically, every product with this software library is affected. It can be a simple printer, a smart home component such as a remote-controlled socket or even certain industrial machines. In addition, some aircraft and satellites are also affected. The question should rather be, which devices are not affected by Ripple20?
Since the manufacturer Treck has signed a non-disclosure agreement (NDA) with its customers, it is not in a position to publish a list of customers. However, Treck has contacted all customers, informed them about the vulnerabilities and provided the updated version of the software library.
The researchers at JSOF have themselves tried to find out which manufacturers are affected and which of them have already taken countermeasures. The following list is as of 18 June 2020 and does not claim to be complete or correct. Please contact the manufacturer of your IP-enabled devices if you suspect that they may be affected by the vulnerabilities.
Status: Confirmed |
Status: Not affected according to manufacturer |
| B.Braun | Abbott |
| Baxter | AMD |
| Caterpillar | GE Healthcare |
| Cisco (via Starent) | Laird |
| Green Hills | Philips |
| HP | Texas Instruments |
| HPE | Zebra Technologies |
|
Maxlinear (via HLFN) |
|
| Rockwell | |
| Scandia National Labs | |
| Schneider Electric/ APC | |
| Digi | |
| HCL Tech | |
Status: Possibly affected |
||
| EMC (now Dell) | Guidant medical | SAIC |
| GE general electric (via Quadros) | Hitache europe | ScriptPro |
| NASA | HLFN | Semtech |
| Verifone | Honeywell | Sigma Designs |
| Agilent | Itron | SimCom Wireless |
| Airlinq (via Netsnapper Technologies SARL) | Kadak | Starent Networks |
| Arburg | L-3 Chesapeake Sciences Corporation | Synamedia (via Cisco)/NDSUK |
| Audiocodes | Lockheed Martin | Syncroness |
| BAE systems | Marvell | Technicolor (via Cisco) |
| BD | Maxim Integrated Products | Thinkcom/ThinKom |
| BECK | Memjet | Tollgrade communications |
| Broadcom | MTS Technologies | Ultra Electronics Flightline Systems |
| Capsule (via Digi) | Netafim | Vicom |
| DASAN Zhone (via vpacket) | Netsnapper Technologies SARL | Videotek |
| Datamax Corporation | nVidia (via Portalplayer) | Vocera |
| Enghouse (via tollgrade communications) | Portalplayer | vpacket (now DHASAN Zhone) |
| Extreme Networks | Qualstar.com | Weibel weibel.dk |
| Foundry | Quadros | Western geco |
| Fraunhofer IZFP | Red lion controls | Xilionx |
| Gainspan (telit) | Redcom | Zodiac Aerospace |
How can the risk of being attacked by Ripple20 be minimised?
As a first step, one should get a complete overview of one's network and all connected devices. With a complete inventory, it can then be determined whether there are any affected devices in the network. Then it should be checked whether updates are available for the devices.
The general best-practice approaches naturally also include the standard procedure:
- Allow devices access to the internet only when absolutely necessary.
- Segment networks and use firewalls between networks.
- If possible, only allow remote maintenance access to the devices via secured and encrypted VPN connections.
For the inventory and analysis of your network and the devices in it, there is a solution from the company Greenbone, which actively or passively searches for security vulnerabilities and summarises results in easy-to-understand reports. In addition, the solution can automatically search for devices in the network and generate an ISO27001-compliant inventory list.
For monitoring, we offer solutions from Nozomi Networks, which uses AI-based systems to learn how devices within a network speak to each other, so that after the learning phase, anomalies can be specifically detected and reported.
If you are interested in a consultation or a test of the presented solutions, please feel free to contact us via phone, email or our contact form.