Zero-day flaws in widespread TCP/IP library open millions of IoT devices to remote attack

19 vulnerabilities – some of them allowing remote code execution – have been discovered in a TCP/IP stack/library used in hundreds of millions of IoT and OT devices deployed by organizations in a wide variety of industries and sectors.

“Affected vendors range from one-person boutique shops to Fortune 500 multinational corporations, including HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, Baxter, as well as many other major international vendors,” say the researchers who discovered the flaws.

About the vulnerable TCP/IP software library

The vulnerable library was developed by US-based Treck and a Japanese company named Elmic Systems (now Zuken Elmic) in the 1990s. At one point in time, the two companies parted ways and each continued developing a separate branch of the stack/library.

The one developed by Treck – Treck TCP/IP – is marketed in the U.S. and the other one, dubbed Kasago TCP/IP, is marketed by Zuken Elmic in Asia.

The library’s high reliability, performance, and configurability is what made it so popular and widely deployed.

“The [Treck TCP/IP] library could be used as-is, configured for a wide range of uses, or incorporated into a larger library. The user could buy the library in source code format and edit it extensively. It can be incorporated into the code and implanted into a wide range of device types,” the researchers explained.

“The original purchaser could decide to rebrand, or could be acquired by a different corporation, with the original library history lost in company archives. Over time, the original library component could become virtually unrecognizable. This is why, long after the original vulnerability was identified and patched, vulnerabilities may still remain in the field, since tracing the supply chain trail may be practically impossible.”

The vulnerabilities were discovered by Moshe Kol and Shlomi Oberman from JSOF in the Treck TCP/IP library, and Zuken Elmic confirmed that some of them affect the Kasago library.

About the vulnerabilities

Collectively dubbed Ripple20, the vulnerabilities (numbered CVE-2020-11896 through CVE-2020-11914) range from critical to low-risk. Four enable remote code execution. Others could be used to achieve sensitive information disclosure, (persistent) denial of service, and more.

“One of the critical vulnerabilities is in the DNS protocol and may potentially be exploitable by a sophisticated attacker over the internet, from outside the network boundaries, even on devices that are not connected to the internet,” the researchers noted.

“Most of the vulnerabilities are true zero-days, with 4 of them having been closed over the years as part of routine code changes, but remained open in some of the affected devices (3 lower severity, 1 higher). Many of the vulnerabilities have several variants due to the stack configurability and code changes over the years.”

The researchers plan to release technical reports on some of them and are scheduled to demonstrate exploitation of the DNS vulnerability on a Schneider Electric APC UPS device at Black Hat USA in August.

Coordinated disclosure

The Treck TCP/IP library did not receive much attention from security researchers in the past. After JSOF researchers decided to probe it and discovered the flaws, they also discovered that contacting the many, many vendors who implement it was going to be a time-consuming task.

Treck was made aware of the vulnerabilities and fixed them, but insisted on contacting clients and users of the code library themselves and to provide the appropriate patches directly.

But, since some of the vulnerabilities affect also the Kasago library, JSOF involved multiple national computer emergency response team (CERT) organizations and regulators in the disclosure process.

“CERT groups focus on ways to identify and mitigate security risks. For example, they can reach a much larger target group of potential users with blast announcements, ‘mass-mailings’ that they broadcast to a long list of participating companies to notify them of the potential vulnerability. Once users are identified, mitigation comes into play,” the researchers explained.

“While the best response might be to install the original Treck patch, there are many situations in which installing the original patch is not possible. CERTs work to develop alternative approaches that can be used to minimize or effectively eliminate the risk, even if patching is not an option.”

The Ripple20 vulnerabilities have been dubbed thusly because of extent of its impact.

“The wide-spread dissemination of the software library (and its internal vulnerabilities) was a natural consequence of the supply chain ‘ripple-effect’.​ ​A single vulnerable component, though it may be relatively small in and of itself, can ripple outward to impact a wide range of industries, applications, companies, and people,” they noted.

“The inclusion of the number ’20’ denotes our disclosure process beginning in 2020, while additionally symbolizing and giving deference to our belief in the potential for additional vulnerabilities to be found from the original 19,” they told Help Net Security.

The researchers have pointed out that the vulnerability disclosure process, their own efforts to identify users of the Treck library, and the patch/mitigation dissemination process have been immensely aided by Treck, various CERTs, the CISA, and several security vendors (Forescout, CyberMDX).

Risk mitigation

A number of vendors have confirmed that their offerings are affected by the Ripple20 flaws. JSOF has compiled a list of affected and non affected vendors, which will be constantly updated as additional information becomes available.

Device vendors should update the Treck library to a fixed version (6.0.1.67 or higher), while organizations should check their network for affected devices and contact the vendors for more information on how to mitigate the exploitation risk. The researchers will make available, upon request, a script to help companies identify Treck products on their networks.

“Fixing these vulnerabilities presents its own set of challenges, even once they’ve been identified on the network. Some already have patches available. But there are also complicating factors,” Forescout CEO and President Michael DeCesare noted.

“With these types of supply chain vulnerabilities and embedded components, the vendor that is creating the patch isn’t necessarily the one that will release it. That can delay the issuance of a patch. There are also no guarantees that the device vendor is still in business, or that they still support the device. The complex nature of the supply chain may also mean the device is not patchable at all, even if it needs to remain on the network. In such cases, mitigating controls such as segmentation will be needed to limit its risk.”

Mitigation advice has been privided by CERT/CC and ICS-CERT (CISA).