Serious flaws in widespread embedded TCP/IP stack endanger industrial control devices

Critical vulnerabilities potentially affect millions of devices, but finding and patching them will be difficult.

Embedded devices, especially those designed for industrial automation that have long shelf lives, are known to use a mixture of in-house and third-party code that was created at a time when software vulnerabilities were not as well understood as today. Critical flaws found in proprietary components that hardware vendors have widely used for years have far-reaching implications. Patching is not always an option.

This is highlighted by the findings over the past year of researchers from Forescout Research Labs and JFrog Security Research, who have investigated the TCP/IP stacks used in a variety of IoT and other embedded systems. This has resulted in major flaws being identified that impact millions of devices in reports such as Ripple20, NAME:WRECK, NUMBER:JACK or AMNESIA:33.

Their latest report, published today under the name INFRA:HALT, covers 14 critical and high-risk vulnerabilities found in a proprietary TCP/IP stack called NicheStack that's widely used in operational technology (OT) devices from up to 200 vendors. These devices include programmable logic controllers (PLCs), such as the Siemens S7, which are the building blocks of industrial automation and are used in critical infrastructure sectors.

TCP/IP stacks have a huge attack surface

TCP/IP stacks, or internet protocol suites, consist of implementations of common internet protocols including DNS, HTTP, FTP, ARP, and ICMP. They enable the operating systems and their applications to send and receive data over IP networks. Given the multitude of protocols these stacks support and the amount of data and packet formats they process, they expose a significant attack surface that can often be exploited without authentication.

Industrial control devices traditionally communicated over serial interfaces, but over the years they've increasingly been equipped with Ethernet interfaces, too, and implicitly with TCP/IP stacks so they can communicate with regular computers and IT devices. Many modern IoT devices run Linux, so they use the Linux TCP/IP stack which has been well scrutinized by security researchers and Linux kernel developers over three decades. However, industrial control devices tend to run proprietary real-time operating systems (RTOS) that use proprietary TCP/IP stacks with inconsistent versioning, custom-made modifications and shifting ownership, all of which complicates identifying vulnerable products and, ultimately, patching.

NicheStack is a TCP/IP stack that was originally developed in 1996 or earlier by a company called InterNiche Technologies and was extended to support the new IPv6 technology in 2003. In 2016, InterNiche Technologies was acquired by another company called HCC Embedded that still maintains the stack.

"In the last two decades, the stack was distributed in several 'flavors' by OEMs such as STMicroelectronics, Freescale (NXP), Altera (Intel) and Microchip for use with several (real-time) operating systems or its own simple RTOS called NicheTask," researchers from Forescout said in their report. "It also served as the basis for other TCP/IP stacks, such as SEGGER’s emNet (formerly embOS/IP)."

Memory corruption

The majority of the 14 vulnerabilities found by the Forescout and JFrog researchers are buffer overflows and out-of-bounds memory reads and writes that result from insecure parsing of packets over different protocols. These can be exploited over ​​DNSv4, HTTP, TCP, ICMP or TFTP and can lead to remote code execution (two vulnerabilities) and denial-of-service conditions (eight vulnerabilities).

The other flaws stem from predictable TCP ISNs, insufficiently random DNS transaction IDs and predictable source port numbers for DNS queries, enabling attacks such as TCP spoofing or DNS cache poisoning. All the vulnerabilities impact all versions of NicheStack before version 4.3, which was the latest available version when the research was performed.

The two remote code execution flaws are located in the DNSv4 and the HTTP implementation and are rated 9.8 and 9.1, respectively, on the CVSS scale, meaning they're critical. The denial-of-service (DoS) issues are rated with 7.5 or 8.2 severity scores. However, it's worth noting that in the context of industrial control systems, the potential impact of a DoS issue can be severe, depending on the type of industrial process that the affected device controls.

For example, to recover from attacks exploiting these vulnerabilities, including DoS, the affected devices would have to be switched on and off. This means having physical access to them, Elisa Costante, Forescout's vice president of research, tells CSO. "This actually makes it quite impactful. Imagine if that device is offshore for substations or oil extraction."

Vulnerability coordination hell

Coordination for the disclosure INFRA:HALT vulnerabilities lasted almost a year, much longer than the 90 days that's standard for software vulnerabilities. Forescout and JFrog Security Research contacted HCC Embedded about the flaws in September 2020 and worked with the CERT Coordination Center (CERT/CC), the German Federal Cyber Security Authority (BSI), and the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) that's part of the US government's Cybersecurity and Infrastructure Security Agency (CISA).

Even so, identifying the potentially impacted devices and vendors has been very hard and is an ongoing process. Using queries on the SHODAN search engine, the researchers found around 6,400 publicly accessible devices that run NicheStack. Using its own proprietary database with millions of device fingerprints, Forescout identified 2,500 potentially vulnerable devices from 21 vendors with the most affected industry verticals being process manufacturing, retail, and discrete manufacturing. Around half the identified devices were energy and power industrial control systems.

This is far from the actual impact of these flaws, though. According to the researchers, a legacy website for InterNiche that is no longer online listed almost 200 device vendors as customers, including major OT vendors like Siemens, Emerson, Honeywell, Mitsubishi Electric, Rockwell Automation and Schneider Electric.

Only a small number of vendors will come out with public advisories, but the projection is that the actual number of impacted devices is probably in the millions, Costante says. "I think this study impacts the largest variety of ICS vendors ever [...] but not many OT devices are actually exposed to the public, so it's a bit more difficult for us to get information around those."

Forescout maintains a list of advisories on GitHub from vendors impacted by its research into TCP/IP stacks and this list will be updated with the new advisories related to INFRA:HALT as they come out.

Mitigation requires visibility

HCC Embedded has developed patches for the vulnerabilities, but they are only available upon request by customers, who are mostly device manufacturers. End users of affected products must wait for patches from their respective device manufacturers.

The issue is further complicated by the fact that it's unlikely all vendors, especially the smaller ones, who integrated this TCP/IP stack into their products over the years still have active contracts with HCC Embedded. Also, some of the affected devices might have reached end-of-support and might never get patches.

"Another problem is that for an asset owner, even if a patch is available, do they know that they have those [affected] devices?" Costante says. "Sometimes they do not have a full inventory of all the devices they have, so even assessing the risk it might be not so straightforward."

Forescot has developed an open-source script that asset owners can use on their networks to discover devices running NicheStack or the other TCP/IP stacks in which the company found vulnerabilities in the past as part of its larger study dubbed Project Memoria. The company has also updated its own commercial products to find affected devices and detect exploitation attempts.

Another issue with patch deployment is that some of the affected devices probably control critical or always-on processes in factories and industrial facilities, or are deployed in the field in remote locations, so they cannot be immediately shut off and updated without planned maintenance. "Mitigation will work better than patching for the majority of the vendors, especially the minor ones," Costante says.

Forescout provides the following mitigation advice for the INFRA:HALT vulnerabilities:

  • Enforce segmentation controls and proper network hygiene to mitigate the risk from vulnerable devices. Restrict external communication paths and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched.
  • Monitor progressive patches released by affected device vendors and devise a remediation plan for your vulnerable asset inventory balancing business risk and business continuity requirements.
  • Monitor all network traffic for malicious packets that try to exploit known vulnerabilities or possible zero-days. Anomalous and malformed traffic should be blocked, or at least alert its presence to network operators.
  • Disable the DNSv4 client if not needed, or block DNSv4 traffic. Because several vulnerabilities facilitate DNS spoofing attacks, using internal DNS servers may be not sufficient (attackers may be able to hijack the request-response matching).
  • Disable HTTP if not needed, or whitelist HTTP connections.
  • Monitor traffic for malformed IPv4/TCP and ICPMv4 packets and block them.

Copyright © 2021 IDG Communications, Inc.

How to choose a SIEM solution: 11 key features and considerations