New Critical Operational Technology Vulnerabilities Found on NicheStack – Mitigation Advised
Forescout Research Labs and JFrog Security Research have discovered a set of 14 new vulnerabilities affecting the NicheStack TCP/IP stack, which we are collectively calling INFRA:HALT. The new vulnerabilities allow for remote code execution, denial of service, information leak, TCP spoofing, or DNS cache poisoning.
NicheStack is used in Operational Technology (OT) devices commonly found in several critical infrastructure sectors, and we estimate major OT device vendors are impacted by these vulnerabilities.
Forescout Research Labs and JFrog Security Research are committed to supporting vendors in identifying affected products (our open-source TCP/IP stack detector can be helpful in this respect) and to sharing our findings with the cybersecurity community. The nature of these vulnerabilities could lead to heightened risk and expose national critical infrastructure at a time when the industry is seeing an increase in OT attacks against global utilities, oil and gas pipeline operators as well as healthcare and the supply chain.
INFRA:HALT further illustrates the problems with TCP/IP stacks that we have seen before in Project Memoria. There are examples of memory corruption issues seen in AMNESIA:33 (on ICMPv4 and TCPv4, like CVE-2020-35683 and CVE-2020-35684), weak ISN generation seen in NUMBER:JACK (CVE-2020-35685), and DNSv4 issues seen in NAME:WRECK (CVE-2020-25767, CVE-2020-25926, CVE-2020-25927, CVE-2020-25928 and CVE-2021-31228).
The table below shows the newly discovered vulnerabilities. All versions of NicheStack before version 4.3 (the latest at the time of research), including NicheLite, are affected. The patches released by HCC Embedded are available upon request. Rows are colored according to the CVSS score: yellow for medium or high and red for critical.
| CVE ID | Vendor ID | Description | Affected component | Potential Impact | CVSSv3.1 Score |
|---|---|---|---|---|---|
| 2020-25928 | HCCSEC-000010 | The routine for parsing DNS responses does not check the “response data length” field of individual DNS answers, which may cause OOB-R/W. | DNSv4 | RCE | 9.8 |
| 2021-31226 | HCCSEC-000003 | A heap buffer overflow exists in the code that parses the HTTP POST request due to lack of size validation. | HTTP | RCE | 9.1 |
| 2020-25767 | HCCSEC-000007 | The routine for parsing DNS domain names does not check whether a compression pointer points within the bounds of a packet, which leads to OOB-R. | DNSv4 | DoS Infoleak | 7.5 |
| 2020-25927 | HCCSEC-000009 | The routine for parsing DNS responses does not check whether the number of queries/responses specified in the packet header corresponds to the query/response data available in the DNS packet, leading to OOB-R. | DNSv4 | DoS | 8.2 |
| 2021-31227 | HCCSEC-000004 | A heap buffer overflow exists in the code that parses the HTTP POST request due to an incorrect signed integer comparison. | HTTP | DoS | 7.5 |
| 2021-31400 | HCCSEC-000014 | The TCP out of band urgent data processing function would invoke a panic function if the pointer to the end of the out of band urgent data points out of the TCP segment’s data. If the panic function hadn’t a trap invocation removed it will result in an infite loop and therefore a DoS (continuous loop or a device reset). | TCP | DoS | 7.5 |
| 2021-31401 | HCCSEC-000015 | The TCP header processing code doesn’t sanitize the length of the IP length (header + data). With a crafted IP packet an integer overflow would occur whenever the length of the IP data is calculated by subtracting the length of the header from the length of the total IP packet. | TCP | App-dependent | 7.5 |
| 2020-35683 | HCCSEC-000011 | The code that parses ICMP packets relies on an unchecked value of the IP payload size (extracted from the IP header) to compute the ICMP checksum. When the IP payload size is set to be smaller than the size of the IP header, the ICMP checksum computation function may read out of bounds. | ICMP | DoS | 7.5 |
| 2020-35684 | HCCSEC-000012 | The code that parses TCP packets relies on an unchecked value of the IP payload size (extracted from the IP header) to compute the length of the TCP payload within the TCP checksum computation function. When the IP payload size is set to be smaller than the size of the IP header, the TCP checksum computation function may read out of bounds. A low-impact write-out-of-bounds is also possible. | TCP | DoS | 7.5 |
| 2020-35685 | HCCSEC-000013 | TCP ISNs are generated in a predictable manner. | TCP | TCP spoofing | 7.5 |
| 2021-27565 | HCCSEC-000017 | Whenever an unknown HTTP request is received, a panic is invoked. | HTTP | DoS | 7.5 |
| 2021-36762 | HCCSEC-000016 | The TFTP packet processing function doesn’t ensure that a filename is null-terminated, therefore a subsequent call to strlen() upon the file name might read out of bounds of the protocol packet buffer. | TFTP | DoS | 7.5 |
| 2020-25926 | HCCSEC-000005 HCCSEC-000008 | The DNS client does not set sufficiently random transaction IDs. | DNSv4 | DNS cache poisoning | 4 |
| 2021-31228 | HCCSEC-000006 | Attackers can predict the source port of DNS queries to send forged DNS response packets that will be accepted as valid answers to the DNS client’s request. | DNSv4 | DNS cache poisoning | 4 |
A video showing the effects of exploiting CVE-2020-25928 on Forescout Cyber Lab is available here. More details about some of the vulnerabilities and their exploitation are available on our technical report.
Impact
NicheStack is a proprietary TCP/IP stack developed originally by InterNiche Technologies and acquired by HCC Embedded in 2016. The earliest copyright messages indicate that the stack was created in 1996, although InterNiche was founded in 1989. The stack was extended to support IPv6 in 2003. 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. It also served as the basisfor other TCP/IP stacks, such as SEGGER’s emNet (formerly embOS/IP).
Understanding where the vulnerable code is present is notoriously challenging. We try to estimate the impact of INFRA:HALT based on the evidence collected during our research, using three main sources:
- A legacy website listing the main customers of InterNiche. According to the website, most of the top industrial automation companies in the world use the stack. Besides those, the website mentions a total of almost 200 device vendors.
- Shodan Queries. We queried Shodan, a search engine for connected devices, looking for devices showing some evidence of NicheStack (e.g., application-layer banners). As shown in Figure 16, with a query executed on 08/Mar/2021, we found more than 6400 instances of devices running NicheStack (using the simple query “InterNiche”). Of those devices, the large majority (6360) run an HTTP server (query “InterNiche Technologies Webserver”), while the others ran mostly FTP (“Welcome to InterNiche embFtp server”), SSH (“SSH-2.0-InternicheSSHServer (c)InterNiche”) or Telnet (“Welcome to InterNiche Telnet Server”) servers.
Figure 1 – Results for “InterNiche” on Shodan
Figure 2 – Results for “InterNiche Technologies Webserver” on Shodan
- Forescout Device Cloud. Forescout Device Cloud is the world’s largest device knowledge base with 13+ million device fingerprints. We queried it for similar banners as Shodan, as well as other information, based on DHCP signatures, for instance. We found more than 2500 device instances from 21 vendors. The most affected customer industry vertical is Process Manufacturing, followed by Retail and Discrete Manufacturing.
Device Functions running NicheStack (source: Forescout Device Cloud)
Devices running NicheStack in each vertical
Mitigation Recommendations
Complete protection against INFRA:HALT requires patching devices running the vulnerable versions of NicheStack. HCC Embedded has made its official patches available upon request and device vendors using this software should provide their own updates to customers.
Given that patching OT devices is notoriously difficult due to their mission-critical nature, we recommend the following mitigation strategy:
- Discover and inventory devices running NicheStack. Forescout Research Labs has released an open-source script that uses active fingerprinting to detect devices running NicheStack. The script is updated constantly with new signatures to follow the latest development of our research. Forescout has also released an updated Security Policy Template (SPT) for eyeSight to detect devices running the stack (more details below).
- 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 0-days. Anomalous and malformed traffic should be blocked, or at least alert its presence to network operators. Forescout has released a script for eyeInspect that detects exploitation attempts against the vulnerabilities in INFRA:HALT (more details below).
The table below provides recommended mitigations for each vulnerability.
| CVE | Affected component | Mitigation Recommendation |
| 2020-25928 2020-25767 2020-25927 2021-31228 2020-25926 |
DNSv4 client | Disable the DNSv4 client if not needed, or block DNSv4 traffic. Because there are several vulnerabilities that facilitate DNS spoofing attacks, using internal DNS servers may be not sufficient (attackers may be able to hijack the request-response matching). |
| 2021-27565 2021-31226 2021-31227 |
HTTP | Disable HTTP if not needed, or whitelist HTTP connections. |
| 2021-31400 2021-31401 2020-35684 2020-35685 |
TCP | For CVE-2021-31400, CVE-2021-31401, and CVE-2020-35684, monitor traffic for malformed IPv4/TCP packets and block them. E.g., having a vulnerable device behind a properly configured firewall should be sufficient. For CVE-2020-35685, we suggest using recommendations we outlined in our NUMBER:JACK report, whenever it is feasible. |
| 2020-35683 | ICMPv4 | Monitor traffic for malformed ICPMv4 packets and block them. |
Forescout Research Labs and JFrog Security Research are available to speak with vendors and asset owners that are affected by these vulnerabilities. If you would like to speak with us, please contact your account manager or send an email to [email protected].
How Forescout can help?
eyeSight uses the Security Policy Templates (SPTs) module to identify and group vulnerable/potentially vulnerable devices. A new version of the SPT package, which can identify devices vulnerable to INFRA:HALT can be downloaded here.
Devices in scope for the policy are scanned using active and passive techniques for five protocols (HTTP, TCP, ICMP, Telnet and DCHP) and can match the policy in three categories – high, medium, and low certainty – as follows:
- HTTP and Telnet fingerprint matches give High Certainty. Known vulnerable vendor/models that are classified by Forescout are also used to give High Certainty matches.
- ICMP fingerprint matches give Medium Certainty.
- TCP and DHCP request options matches give Low Certainty.
The results of an example scan are shown in the figure below.
Figure 5 – SPT scan showing devices with high certainty of being vulnerable
eyeInspect can detect exploitation attempts using the following scripts:
- “INFRA:HALT Monitor” detects exploitation attempts against the InterNiche webserver: CVE-2021-27565, CVE-2021-31226, CVE-2021-31227.
- “Threat Detection Add-Ons” contains detection logic for malformed DNS packets (among many others) that can detect various exploitation attempts against DNS clients, namely: CVE-2020-25928, CVE-2020-25767, and CVE-2020-25927. This script also detects exploitation attempts of vulnerabilities disclosed during the NAME:WRECK and AMNESIA:33 research.
The figure below shows the alert raised by eyeInspect when it detects an exploitation attempt against CVE-2021-31226.
Figure 6 – eyeInspect detecting the exploitation of CVE-2021-31226
Finally, eyeSegment provides network flow mapping of existing communications, which helps to identify unintended communications and enforce appropriate segmentation controls. Once vulnerable devices have been identified, they can be logically grouped to decrease the communications allowed to or from them, thereby limiting the likelihood of compromise and the blast radius if a compromise occurs.
The Challenges of Supply Chain Vulnerability Disclosure
In September 2020, Forescout and JFrog Security Research contacted HCC Embedded to notify them of a series of critical vulnerabilities we found on its privately owned TCP/IP stack NicheStack as part of Project Memoria.
Coordinated vulnerability disclosure (CVD), especially supply chain vulnerabilities is a complex process that involves considerable effort from multiple stakeholders. By following the CVD model, Forescout and JFrog contacted several coordination agencies including the Israel National Cyber Directorate, which is in the process of establishing a research collaboration with Forescout, the CERT Coordination Center, BSI (the German Federal Cyber Security Authority), and ICS-CERT (the Industrial Control Systems Cyber Emergency Response Team). According to CISA, ‘Vulnerability Coordination is the process by which multiple stakeholders in a software vulnerability work together to analyze and address a vulnerability with the goal of eventually disclosing to the public the existence of the vulnerability and guidance on how to mitigate or fix the vulnerability”.
After a lengthy period of discussion, the disclosure date was set for August 4th, but still there are many vendors that have not confirmed or denied being vulnerable
Forescout and JFrog’s intent is to collaborate with affected vendors in a transparent manner, help them to identify impacted products and prepare advisories and only then publish the list of impacted vendors and models alongside a detailed technical report of the research. This proven responsible disclosure process ensures all community stakeholders have the most complete information and time to prepare to take action on mitigation steps.
Security Advisories
You can get up-to-date information about impacted vendors and devices on the following links:
- Project Memoria advisories, maintained by Forescout Research Labs. We encourage any member of the security community that finds missing security advisories related to any of the Project Memoria disclosures (including INFRA:HALT) to contribute to that page by creating a pull request.
- ICS CERT Advisory