Ripple20: A Reflection

Since releasing our Ripple20 whitepaper and follow up article, we have received great feedback from our customers and the community at large about our Ripple20 research and findings. We have also received some pointed remarks from the security research firm that originally disclosed the Ripple20 vulnerabilities. In this article, we would like to set the record straight about our position on Ripple20, what we are focused on now, and what we are committed to doing moving forward to best serve our customers and the community.

Our Ripple20 Research

The Ripple20 disclosure by JSOF shook the community to its core, claiming on their website that its vulnerabilities “affect hundreds of millions of devices (or more) and include multiple remote code execution vulnerabilities.” Furthermore, they claimed, “in all scenarios, an attacker can gain complete control over the targeted device remotely, with no user interaction required.” Many vendors were uncertain about whether or not their products were vulnerable, especially since there was limited information and tooling available to reproduce and verify JSOF’s research. Given the discrepancies that we saw in the reporting around Ripple20 and our customers inquiring about these vulnerabilities, we investigated the claims made by JSOF to better understand the true impact of Ripple20. To summarize our analysis so far, we are mapping our results to the claims that are detailed in the Risk Evaluation and Mitigations section of JSOF’s Ripple20 website.

Claim #1: “An attacker from outside the network taking control over a device within the network, if internet facing.”

CVE: CVE-2020-11896
Reality: The reported remote code execution (RCE) vulnerability that can affect “internet facing” devices is CVE-2020-11896. This vulnerability is only applicable if certain macros are intentionally disabled during build time. This includes the error checking macro TM_ERROR_CHECKING or the configuration macro TM_USE_DRV_SCAT_RECV which supports scattered data from the device driver. Our research found only 1 of our 20 devices made such a decision: the Digi Connect Me 9210, which has since been patched. The other potential remote takeover scenario is related to a DNS cache poisoning attack targeting CVE-2020-11901, which is addressed later in this article.

Claim #2: “An attacker who has already managed to infiltrate a network can use the library vulnerabilities to target specific devices within it.”

CVE: CVE-2020-11896, CVE-2020-11897, CVE-2020-11901
Reality: This general claim is true for devices that can be remotely exploited; however, as our research has demonstrated, most devices running Treck are not remotely exploitable.

Claim #3: “An attacker could broadcast an attack capable of taking over all impacted devices in the network simultaneously.”

CVE: CVE-2020-11896, CVE-2020-11897
Reality: Although an attacker could attempt a broadcast attack, gaining remote code execution is heavily reliant on the TM_ERROR_CHECKING or TM_USE_DRV_SCAT_RECV macro being disabled. Since many Treck devices have one of these macros enabled, many of them are not remotely exploitable; therefore, broadcasted RCE attacks will mostly fail. There has been no evidence or demonstrations of successful broadcasted attacks.

Claim #4: “An attacker may utilize affected device as a way to remain hidden within the network for years”

CVE: N/A
Reality: This claim requires an attacker to exploit a device and land a payload with privileges that are escalated at a high-enough level that they can install a persistence mechanism.  Alternatively, the attacker could keep their payload in memory until the device is rebooted. Although this is a logical progression of the standard exploitation process, achieving persistence is much more challenging than initial exploitation as attackers will need to overcome size, bandwidth, and latency constraints which will vary per device. There is no evidence that exploiting Ripple20 vulnerabilities guarantees a persistent presence.

Claim #5: “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.”

CVE: CVE-2020-11901
Reality: In order to execute this attack, the attacker must be able to take over an upstream DNS server or execute another type of MITM attack. This is a tall order regardless of the devices being targeted. Furthermore, our research has demonstrated that CVE-2020-11901 is not widely exploitable due to:

1. The lack of DNS functionality in most devices running Treck.
2. The differences in architectures and memory layouts present challenges that affect the reliability of achieving RCE; thus, exploitation of CVE-2020-11901 is unlikely on most devices.
3. CVE-2020-11901 has still only been demonstrated to be exploitable on a single device (APC Smart-UPS 750), which is due to its use of a bad RDLENGTH and is conveniently a 16-bit ISA. We have not seen the attacker controlled RDLENGTH code variant in any of our firmware.

The combination of a high-risk DNS MITM attack coupled with low probability exploits against devices in a target network make this scenario highly unlikely.

Claim #6: “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.”

CVE: CVE-2020-11901
Reality: According to JSOF’s whitepaper, “a sophisticated attacker can potentially reply to a DNS request from outside of the corporate network” and achieve “pre-authentication arbitrary remote code execution” if exploitation of CVE-2020-11901 is successful. As mentioned above, this scenario is also highly unlikely.

Claim #7: “In all scenarios, an attacker can gain complete control over the targeted device remotely, with no user interaction required.”

CVE: CVE-2020-11896, CVE-2020-11897, CVE-2020-11900, CVE-2020-11901
Reality: This is the most inaccurate of all of JSOF’s claims.  The issues with this claim are as follows:  

1. JSOF agreed that many devices are not vulnerable to CVE-2020-11896.
2. Finite State demonstrated that CVE-2020-11896 exists in a small minority of Treck-enabled devices and is dependent upon the macros TM_ERROR_CHECKING or TM_USE_DRV_SCAT_RECV being disabled.
3. CVE-2020-11897 describes a vulnerability that was fixed 11 years ago (in 2009); therefore, many modern devices today are likely not exploitable using this vulnerability.
4. CVE-2020-11900 depends on IPv4 tunneling like CVE-2020-11896. Similarly, most devices are not susceptible to this vulnerability, especially since a fix was released six years ago (in 2014). 
5. CVE-2020-11901 is rarely exploitable due to the issues described above in the table.  If it is exploitable, each device to be exploited will need a unique exploit payload to be generated, making mass exploitation virtually impossible.

As we have said all along, there are real vulnerabilities that need to be fixed in the Treck stack, and efforts have been made to address them. Devices that utilize the Treck TCP/IP software library, however, are not automatically vulnerable to all remotely exploitable Ripple20 CVEs. Our research continues to confirm that build-dependent, device-level configurations greatly influence the presence, usability, reachability, and the resulting effect of Ripple20 vulnerabilities. It has been proven by Finite State and several other researchers, as discussed below, that not all devices are remotely exploitable. In fact, a very small number of devices demonstrate this characteristic.

In analyzing these known vulnerabilities across 20 pre-patched firmwares, we observed that the final effects varied for each CVE. Most of the firmwares were not remotely exploitable as disclosed. For CVE-2020-11896, only 5% of our corpus had demonstrated a potential RCE effect. For CVE-2020-11898, an information leak was observed across 5% of our sample set. Lastly, only 10% of the firmware was affected by a heap overflow vulnerability which could possibly lead to remote code execution (CVE-2020-11901). 

To be clear, this does not mean that our sample is a complete representation of all Treck devices in the world.  We were able to analyze a random sampling of devices that had different vendors, architectures, and release dates, and thus, we feel it is a realistic randomized sample set. Within that sample set, our research revealed that only a small percentage of devices were remotely exploitable, bringing into question the true widespread impact of Ripple20. We have been responsibly transparent about our collaborative, multi-faceted research approach and our results which are clearly described in our publications. No zero days were disclosed and no embargos were violated in the process.

An independent cybersecurity firm also looked at a few of the firmware images in our report and confirmed our results1,2. Other vendors who were able to verify Ripple20’s impact on their products also confirmed that the resulting effects they observed were different than what was expected and disclosed3,4,5,6. It is becoming more clear that Ripple20 is not as grave as advertised. Due to the low percentage of devices that are remotely exploitable and the fact that each device requires complex customization to effectively exploit, immediate, widespread weaponization is unlikely. Thus, security teams should focus on accurate patching and verification following normal product security incident response procedures. Diligent verification will ensure that these vulnerabilities are mitigated without introducing additional vulnerabilities in the process.

We have also reassessed our research over time as more information became publicly available. As we gain new insights, we promptly communicate our latest findings, as demonstrated by our articles, to keep the community up-to-date and informed. The pointed remarks that were recently expressed about our September whitepaper were already addressed and communicated in our October publications (released well before JSOF’s remarks); thus, these remarks are obsolete, inaccurate, and have only served as an unnecessary distraction to the community. We welcome additional critiques of our research, but the burden of proof remains on JSOF to prove their claims to the public and actually demonstrate that these vulnerabilities are remotely exploitable on more than two devices.

Our Current Focus

We appreciate that the security firm responsible for the Ripple20 disclosure finally acknowledges that they do not know how many devices are affected by Ripple20 vulnerabilities.7 Their claim that Ripple20 vulnerabilities “affect hundreds of millions of devices (or more)” is highly speculative, and their claim that “in all scenarios, an attacker can gain complete control over the targeted device remotely, with no user interaction required” is based on the premise that if a device is using the Treck stack, then it is remotely exploitable. As demonstrated by our research, the research of the community, and JSOF’s own admissions, this is simply not true and a gross inflation of the true impact of the vulnerabilities.  

We strongly recommended that vendors include vulnerability verification as part of their patching process so that product security teams are making informed and appropriate security decisions. The only way to know for certain if a device is vulnerable is to analyze and test it. This can be a long, manual, and expensive process for product security teams, especially for verifying complex vulnerabilities. It is, therefore, imperative that product security teams are equipped with the necessary tools to quickly verify if their products are vulnerable. Finite State has a proven platform that can perform this analysis at scale, speed, and efficacy with a high level of confidence. We are focused on expanding our capabilities to continue providing objective, data-driven risk analysis to device manufacturers and asset owners, enabling them to understand and mitigate their risks before they are compromised.

Our Commitment

Finite State remains committed to serving our customers and the community at-large. We will continue sharing our work to provide the greatest transparency and to educate the public. We will continue following the responsible disclosure process when we discover new vulnerabilities.  We are glad that our publications have inspired vulnerability disclosing parties to improve their reporting process in order to better serve the community, and we look forward to equipping product security teams with solutions that can properly detect and verify these potential vulnerabilities at scale. The way in which Ripple20 was marketed has revealed the need for higher evidence standards to prevent the impairment of the security community through exaggerated disclosures. In the meantime, we will continue developing solutions that arm device manufacturers and asset owners with the necessary tools to quickly determine the true security risks of their products. If you have any questions about our security research or the Finite State platform, we encourage you to contact us here. We’ll gladly provide more information upon request.

—

1. https://twitter.com/ReverseICS/status/1316026429608394754
2. https://www.dragos.com/resource/ripple20-what-you-need-to-know/
3. https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2020-006.txt
4. https://blog.scadafence.com/ripple20-mixed-results-in-scadafences-exploitability-lab-tests
5. https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-treck-ip-stack-JyBQ5GyC
6. https://www.dell.com/support/article/en-us/sln321836/dell-response-to-the-ripple20-vulnerabilities
7. https://www.jsof-tech.com/the-return-of-information-anarchy/