7 Steps to Protect Against Ripple20 Vulnerabilities in OT/ICS

The JSOF research lab recently released a series of vulnerabilities named Ripple20 that are present in a software stack that provides core networking functionality to several different families of devices and vendors.

While the media estimates millions of devices have been effected, embedded products regularly contain a number of vulnerabilities, and many of those vulnerabilities affect far more devices than that of a relatively obscure network stack that was purchased or re-distributed by a few vendors.

It’s one thing if a device is affected by a vulnerability, but another thing if it is in an un-exploitable location. Further, it’s important to determine if the System under Consideration (SuC) has mitigable risks – even if a fix may exist.

What is Ripple20?

Ripple20 is a collection of nineteen vulnerabilities that affect a software implementation of a network stack developed by Treck, Inc.  It is a specific piece of software that can be licensed and integrated into an embedded solution as part of a product’s firmware, or into a specific application for distribution.

Most of the Ripple20 vulnerabilities are the result of logic errors and a lack of careful memory management, resulting in attackers exploiting these flaws by transmitting malicious network packets to the device in specific situations.  This is not unlike a similar family of vulnerabilities called URG11 (or Urgent11) that was present in certain versions of an embedded operating system (OS) called VxWorks.

It is important to note that Treck, Inc. has a historical relationship with KASAGO TCP/IP software from Zuken Elmic (previously known as Elmic Systems), so further industrial systems may be discovered as vulnerable.

How does Ripple20 attack?

The Ripple20 vulnerabilities have been implemented in slow-to-update embedded firmware and can be exploited if network connectivity is present (and direct in almost all cases).

To exploit these systems, the Treck IP stack requires relatively low expertise to potentially execute the following attacks (at a minimum):

• Install and execute unauthorized code (e.g., execute a shell using remote code execution)
• Modify running software and configurations on a device (e.g., as a consequence of exploitation)
• Potentially compromise and/or disrupt industrial network protocol stacks that are built-upon or expand upon the Treck TCP/IP stack implementation
• Exploit IP tunneling to traverse networks or to be forwarded (applicable in situations where VPNs or routing is used by an affected device)
• Affect the stability of the system and/or potentially render it completely unavailable

Most concerning is the potential for this stack to deploy in medical devices and industrial control system products.  This represents an opportunity for exploitation by enterprising malicious entities with a particularly low barrier to potentially affect hypothetically vast numbers of hosts with catastrophic consequences.

How does Ripple20 impact the security of OT/ICS environments?

Creating secure products is hard, and fixing flaws in embedded solutions by either the vendor or by an asset owner can be even more complicated.  This is the same for nearly any Internet of Things (IoT) product, and nearly any Industrial Automation and Control System (IACS) product on the market today.

Fortunately, many of these devices do not, and should not have direct access to the Internet. They are often deployed in networks where change is slow and easily identified due to their “steady-state” nature. In other words, device behavior or network traffic should remain consistent for long periods of time.

In fact, most of the devices that are likely to run contain vulnerable versions of the Treck IP stack are protected by firewalls, layers of network security, may not even be networked altogether, and can be protected with a well-orchestrated security program with multiple compensating controls.

Secondly, Operational Technology (OT) may have a series of secondary controls and processes to help manage any safety and visibility implications. However, this does not necessarily equate to intrinsic safety nor infallibility.

If one of these systems is in a position where compromise is trivial, either directly, or through another host (which is far more statistically possible, and likely to be a commodity system such as a workstation, or Internet-facing networking equipment), there could be negative consequences.

Protect vulnerable systems from Ripple20:

• Maintain an accurate inventory of deployed assets and consider embedded systems as part of your vulnerability, risk, and OT systems management programs. Most vulnerabilities are exploited from compromised commodity IT/OT convergent systems, endpoints, and misconfigured infrastructure.
• Patch or update effected devices that have a firmware update available, and/or re-configure devices so they do not use vulnerable protocols where feasible, but instead have a dedicated, closed-loop vulnerability management system for all assets.
• Protect systems, network infrastructure, endpoints and points of access that are commonly compromised, have a higher risk exposure, and/or possess a statistical likelihood of being targeted. This includes protection against commodity malware threats, security updates and patches, application whitelisting, secure configuration/hardening, firewalls, monitoring, and other technologies
• Sanitize network protocols for irregularities or non-standard usage by a capable network security device may reduce the risk or reduce unintended behavior by a device using a stack such as this one. However, it may cause issues for devices or vendors that regularly exhibit non-standard behavior and disrupt network communications.
• Monitor ARP tables, DHCP requests, DNS lookups, IP connections, and other network-related infrastructure for Indicators of Compromise that would enable an organization to identify malicious activity or an anomaly. All logs should be forwarded, monitored, tracked, and investigated as part of a continuous process to manage alarms in a way to detect events, and differentiate those from accidental, steady-state, and malicious activity.
• Use secure remote access technologies when remote access is required to access these systems or sites home to these systems with the acknowledgement that a VPN is only as secure as the connected devices (e.g., the remote workstation may be insecure and pose a threat if compromised).
• Possess adequate governance, policies and procedures to sufficiently handle risk, vulnerabilities, and incidents. This should be part of a comprehensive OT cyber security program.

Not all OT systems will be disclosed as vulnerable, so the best strategy to secure embedded systems is to identify, track, manage, and protect them, even if zero vulnerabilities have been reported in a specific product.

It is one thing to receive an alarm, an event, or a vulnerability report, but it is altogether another to act upon it and be able to effectively reduce cyber security risk in OT/ICS environments.