Protecting Your Network Against Ripple20 Vulnerabilities

By Brien Posey

In the realm of technology, some events can disrupt the landscape and force practitioners to reevaluate daily operations.

Earlier this year, the arrival of the Ripple20 breach was that kind of event—reminding IT pros across the globe that vulnerable third-party code can wreak havoc on IT systems, opening the door to malicious attacks.

Earlier this year, the JSOF research lab discovered a series of vulnerabilities that became collectively known as Ripple20 (). The Ripple20 vulnerabilities exist within the Trek Inc. TCP/IP library, which is used by hundreds of millions of IoT devices ranging from industrial IoT devices to consumer grade devices used in the home. The affected software library has also been used in other types of connected devices such as point-of-sale terminals, medical equipment, and aviation-related devices. These vulnerabilities can be exploited for remote code execution and even complete device takeover. These code bugs have been difficult to track and remove because of the widespread adoption of this third-party code in various systems. Indeed, the bugs may never be fully patched in some products.

The seriousness of the Ripple20 vulnerabilities has been well established through various proof of concept demonstrations. At this point, organizations must work to determine whether they are using devices that are affected by this collection of vulnerabilities, and if so, how to go about addressing the problem.

Locating Ripple20-Affected Devices

Unfortunately, determining which of an organization’s devices are affected by the Ripple20 vulnerability is not an easy task. As previously noted, the vulnerability exists in a low-level software library that dozens of different vendors use. Because so many devices use this library, automated detection of the vulnerability is difficult at best.

But automated detection methods do exist, several tools help identify vulnerable devices. GitHub for example, contains a tool that is designed to passively monitor TCP/IP traffic flowing across a network to detect signs that devices suffer from the Ripple20 vulnerabilities.

Similarly, Forescout has released guidance to help IT pros detect Ripple20 vulnerabilities on their networks. ExtraHop has also developed a detection method.

As helpful as these tools might be, using them may not be an option for every organization. Smaller organizations for example, might lack the IT expertise to use such tools, or the licensing costs may be cost-prohibitive (although the GitHub tool is open source). If an organization can’t use the available tools to detect vulnerable devices, there is an alternative, albeit a much more tedious method, to use.

Here, an organization would method involves manually determining which of an organization’s devices suffer from the vulnerability.

The first step is to perform a comprehensive inventory of all network-connected devices. With a hardware inventory in hand, the next step is to look for devices manufactured by vendors whose products are known to be vulnerable. As of this writing, there are 31 vendors with vulnerable products, and dozens more are still being evaluated. There is the most recent list of affected vendors.

The list of includes links to each vendors’ Ripple20 response page, which for most of the affected vendors includes information about which devices are affected and on what the vendor is doing to address the vulnerability.

The best way to secure an affected device is to update the device’s firmware using a manufacturer-provided patch. Unfortunately, patching isn’t always an option. Some devices simply do not contain updatable firmware. Similarly, a manufacturer may not choose to offer patches for older devices that it no longer officially supports. It’s also possible that a vendor may still be in the process of developing or testing a patch, and does not yet have a patch available.

Organizations also have to consider the possibility that some of their devices may be vulnerable even though they do not appear on any of the lists of devices that are known to be problematic. After all, there are numerous vendors whose products are still being evaluated. Some vendors’ products will never be evaluated because the vendor is small and obscure or because it has gone out of business.

Alternative Options for Securing Affected Devices

If an organization has affected devices that cannot be patched or devices that are not confirmed but are suspected of being vulnerable, the organization will need to take other measures to protect itself. Ideally, insecure devices that cannot be made secure should be replaced with devices that known to be unaffected by the Ripple20 vulnerability. If this isn’t an option there are some things that can be done.

Make sure that potentially vulnerable devices are not accessible from the Internet. This is an extremely important step, because attacks against such devices generally originate in the outside world. If possible, organizations should also relocate potentially vulnerable devices to dedicated subnets that are isolated from the end-user network. This further reduces the chances of an attacker being able to access the device.

IT pros should also filter any traffic going to or from potentially vulnerable devices. Generally speaking, IoT devices only need to communicate with specific IP addresses. Therefore, it’s a good idea to block traffic to or from any other addresses. Firewalls should also be used to block traffic on any ports that are unnecessary, and it might even be possible to block IPv6 traffic without affecting the device’s functionality.