Introducing the First Virtual Conference for Product Security - Left to Our Own Devices: The Conference.
Introducing the First Virtual Conference for Product Security - Left to Our Own Devices: The Conference.

Ripple20 and What it Means to Your Product Security

Ripple20 and What it Means to Your Product Security

Writing good code is hard. Making it secure is harder. Doing so with 3rd party components is a nightmare. That’s what R&D organizations realize as they embrace software supply chains to speed up innovation and development.

This gets more challenging by the day, as security becomes ever more critical to the safety of connected systems and people, and regulations mandate solid, secure baselines along with ongoing security maintenance.

A security flaw introduced through the supply chain of IoT devices – connected vehicles, medical devices or industrial IoT equipment – can have devastating consequences. Figuring out the impact of vulnerabilities and mitigating them, especially post-production when devices are in service, is quite a challenge. A case-in-point – Ripple20!

Ripple20 hits IoT devices

In June 2020 cyber security experts from JSOF discovered a series of high-risk vulnerabilities collectively known as Ripple20. These 19 zero-day vulnerabilities were found in the TCP/IP software library developed by Treck.

This library is a proprietary TCP/IP stack that has been commonly available for more than 20 years. The Treck networking stack is a software component that provides network connectivity over standard internet protocols such as IPV4,IPV6, ARP,TCP and UDP.

These vulnerabilities have been skulking inside Treck’s TCP/IP stack for at least 10 years and have been integrated into millions (!!) of IoT devices affecting a wide range of industries including manufacturing, healthcare, energy markets, governments and the automotive industry.

The extensive media coverage of these vulnerabilities is therefore not surprising. The vulnerabilities have left both technology vendors and users concerned.

Why “Ripple20” you ask?

A common assumption is that researchers named this set of vulnerabilities “Ripple20” because there were 20 vulnerabilities from the start, but the truth is that the name reflects the ripple effect caused by these vulnerabilities on the product development supply chain, the year they were discovered (2020) and the age of the Treck TCP/IP library (20 years).

Exploiting Ripple20 vulnerabilities

Amongst the 19 vulnerabilities, there are several dangerous CVEs whose exploitation can enable remote code execution and denial-of-service (DoS) with no need for any user interaction.

Hackers could potentially steal data, command a certain behavior change or make devices malfunction. These threats could even put people’s lives at risk, i.e. connected cars could be hacked putting the car owner in danger. These threats could also prove fatal in the healthcare industry as it could directly jeopardize patient safety.

Ripple20 vulnerabiliies_CVSS3Ripple20 CVEs

While not all of the vulnerabilities are severe, you should definitely address Ripple20 sooner rather than later, because these vulnerabilities could lure remote attackers. They are located at the beginning of a very complex supply chain, making the Treck TCP/IP library a good attack vector. A successful exploit could impact multiple parties within the software supply chain.

Additional complications

To investigate whether your components are affected by these threats, it is important to understand the different aliases this library has. Other known software libraries based on the Treck TCP/IP stack are ELMIC, Ghnet2, Kasago, Net+ OS, Kwiknet, Quadnet, and AMX.

Experts warn that many of the affected devices will remain unpatched because this library is highly configurable, so each Treck TCP/IP instance differs from the next.

This is why many companies don’t even know that this library is used in one of the components powering their product.

Impact analysis through context-awareness

It’s important to note that if one of the above software libraries is integrated into your product, it doesn’t mean you are immediately exposed to the vulnerabilities, but it does deserve a closer inspection.

Vulnerabilities can be filtered out as irrelevant to your firmware based on the specific context in which the software is used e.g. depending on your CPU architecture, OS type, certain source files that are not compiled inside your file system or even certain vulnerable code scope that is missing. This powerful logic can save you lots of time and stress.

Lets, for example, take a scenario where the Ghnet2 package is integrated into your product. The following CVE-2020-11899 – “The Treck TCP/IP stack before 6.0.1.66 has an IPv6 Out-of-bounds Read” – is theoretically supposed to affect your system, however it is irrelevant to your firmware if IPV6 is disabled and the packets are not encapsulated within IPV4.

This is what we call context based filtering. Cybellum_context_based_filtering_CVE-2020-11899

Context-based filtering of a Ripple20 CVE

Another possible context-aware analysis relates to whether the kernel architecture is isolated from the application. If that’s the case, the vulnerability’s impact is far less severe as this separation protects the entire system in cases where the application misbehaves.

At Cybellum, we help organizations detect Ripple20 (and other vulnerabilities) inside their binary software components using our automatic vulnerability detection mechanism. Moreover, our solution highlights the actual CVEs that are affecting your firmware.

Over the past few months, we have discovered these vulnerabilities at a few of our clients’ firmware. They were surprised to discover that they were using this library. Some cases ended up with immediate mitigation plans, others were identified as not relevant via context based filtering.

Mitigating Ripple20

Treck has released security guidelines referring to these vulnerabilities. We encourage you to follow their updates, patch your products, and take security measures to defend your IoT devices. Also, try to minimize network exposure, by placing your devices behind firewalls and enforcing the use of VPNs whenever you access your internal devices remotely.