Digital Forensics & Incident Response Strategic Services Advanced Testing Services Managed Security Services
June 19, 2020
CBI Security Alert: Ripple20

By Aaron Pohl, Senior Penetration Tester, CBI ATS Team

What is Ripple 20?

Ripple20 is a collection of nineteen software vulnerabilities in a proprietary TCP/IP stack library developed by Cincinnati, Ohio-based Treck, Inc. This library has been in use in embedded and industrial hardware dating back to 1995, and may affect hundreds of millions of devices according to Jerusalem, Israel-based JSOF, the security firm that discovered these vulnerabilities.

Three of these vulnerabilities are noted as potentially leading to remote code execution. There is also mention that this library was included in other development suites without appropriate attribution, leading to situations where there may be devices in the field where the original developers have no idea that they used this vulnerable code. The collection has been named “Ripple 20” because of the ripple effect that the discoverers of the vulnerability predict will be seen from them in the years to come. A US Department of Homeland Security advisory which is to be sent out about this collection of vulnerabilities listed the following highlights:

CVE-2020-11896 – CVSSv3 score: 10 – Improper handling of length parameter inconsistency in IPv4/UDP component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in remote code execution.

CVE-2020-11897 – CVSSv3 score: 10 – Improper handling of length parameter inconsistency in IPv6 component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in possible out-of-bounds write.

CVE-2020-11898 – CVSSv3 score: 9.8 – Improper handling of length parameter inconsistency in IPv4/ICMPv4 component when handling a packet sent by an unauthorized network attacker. This vulnerability may result in exposure of sensitive information.

CVE-2020-11899 – CVSSv3 score: 9.8 – Improper input validation in IPv6 component when handling a packet sent by an unauthorized network attacker. This vulnerability may allow exposure of sensitive information.

As a Red Team member here at CBI, when I read headlines telling me that there is a new collection of remote code execution vulnerabilities out, and that the number of vulnerable devices potentially number into the hundreds of millions, the writer immediately has my attention. I am also a very busy person, so when it came to a question of reading their whitepaper which only covers some of the vulnerabilities or just skimming the available materials, I quickly found myself watching JSOF’s YouTube video demonstrating a potential attack-vector for this vulnerability.

Thankfully, they left some really solid notes in their exploit script that give me a pretty good idea of one of their potential exploitation vectors:

\Users\User\Desktop\ups>python -1 10 -t MX
DNS Responder started (respond to queries of type: MX) =
[SHAPING] Forming big hole…
[+] Reply to type MX(0xf) query for domain: [reply length: 0x598]
[SHAPING] Forming little hole…
[+] Reply to type MX(0xf) query for domain: [reply length: 0x598]
Begin emission:
Finished sending 1 packets.
Received 2 packets, got 1 answers, remaining 0 packets
[OVERFLOW] Redirecting assert handler to payload…
[+] Reply to type MX(0xf) query for domain: {reply length: 0x598]
Behind NAT, wait for event to trigger payload.
Press <enter> to trigger event:
[HTTP] Sending bad credentials…
[HTTP} Done.

So what can we glean from this?

First-off, it states “DNS Responder started”. This immediately implies that they’re responding to DNS queries, potentially even spoofing responses to local network requests. The script is using a type flag of “MX”, indicating that this is going to be sending responses to DNS requests for mail servers, and indeed it goes on to “Reply to type MX(0xf) query for domain: [reply length: 0x598]”.

The next big hint here is that reply length of 0x598. As soon as I saw this, it tripped my memory, and a quick search told me that I was correct in my recollection that the maximum size of a DNS response is 512 bytes. With three of the most critical vulnerabilities being noted as “Improper handling of length parameter”, this seems like a slam-dunk as pointing at the demonstrated exploit vector.

From there, there is mention of the device being behind NAT, which implies that they’ve set this scenario up in a way that it replicates an attacker on the external network in control of a domain that the vulnerable device is looking up, but then at the end, there is mention of “wait for event to trigger payload” a cut-off “[HTTP] Sending bad credentials…” – This raises some questions again – if the requesting device were behind NAT from the perspective of the DNS server, it shouldn’t be able to immediately communicate with the webserver on the vulnerable UPS unless if this happened to be an internet-facing UPS. What I assume is going on here is that their oversized DNS response placed the vulnerable code in memory, but they still needed to actually get that shellcode to execute in another fashion, and failing authentication against the httpd just happened to be the way to do so.

Taking a quick skim over their whitepaper to see if I’m right found the following note, “A second white-paper, 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” indicates that the YouTube video is likely a preview of JSOF’s BlackHat presentation.

What does CBI recommend?

All speculation aside, what do you need to do to protect yourself against this threat?

First-off, you’re going to want to scan for vulnerable devices in your network and start patching immediately, but as this collection of vulnerabilities is very new, there may not be comprehensive scanners to detect all 19 vulnerabilities, or even the four most critical ones. As far as patching goes, while an update is available from Treck, you may or may not need to wait for the developer of the vulnerable hardware to release such a patch.

Next, the most pragmatic thing to do is to follow the advice of the vulnerability authors and start tightening down the network. Most of JSOF’s suggestions have to do with proper segmentation, isolation of vulnerable devices, the enabling of IDS/IPS and anomaly detection features, and blocking some specific types of network requests if they’re not in use on your network. They even go as far as stating that people may want to move off of DHCP to static IP addresses, likely giving us another solid hint at where another one of the vulnerabilities is.

From there, we’re likely looking at a very long-tail of slow vendor patching and notification as embedded hardware developers start reading these headlines and checking their code and their product support teams start receiving queries from customers about whether or not their devices are vulnerable leading to searches for whether or not this code was used at any point in the last 25 years.

About the Author
Aaron Pohl
Aaron Pohl
Senior Penetration Tester
Aaron Pohl is a Senior Penetration Tester at CBI. Aaron’s expertise includes ethical hacking, red teaming, internal and external network penetration testing, physical security assessments, wireless testing, social engineering, and web application testing. He also enjoys researching software-defined radios, physical network implants, and cellular technologies.
I Need To...