NicheStack is a TCP/IP network stack commonly used in millions of Operational Technology (OT) devices around the world, including in critical infrastructure such as manufacturing plants, power generation/transmission/distribution, water treatment, and more.
JFrog’s security research team (formerly Vdoo), together with Forescout Research Labs, recently discovered 14 new security vulnerabilities affecting the NicheStack TCP/IP stack. These vulnerabilities enable remote code execution, denial of service, information leak, TCP spoofing, or DNS cache poisoning.
This blog post will detail these 14 vulnerabilities, which we named INFRA:HALT, and offer recommendations for mitigating them.
What is NicheStack?
NicheStack is a commonly-used, proprietary TCP/IP stack for embedded systems, developed by InterNiche Technologies in 1996. In 2003, NicheStack extended its support to IPv6.
NicheStack Protocol Support
These are the protocols that are currently supported by NicheStack:
NicheStack is commonly used in OT devices around the world. For example, it is used in Siemens S7 PLCs, which has the largest PLC market share. In addition, according to our research, we found usage among ~200 device vendors, including most of the top industrial automation companies, as well as 6,400 instances of devices running NicheStack according to Shodan search results.
14 New NicheStack Security Vulnerabilities
We analyzed two versions of NicheStack: a binary sample of version 4.0.1 (publicly available via the legacy InterNiche website) and the source code of version 3 (publicly available via a website exposing the source files for an embedded project). The binary version was manually and automatically analyzed by JFrog, leveraging both static and dynamic proprietary techniques.
The table below details all 14 newly discovered vulnerabilities that we found. All NicheStack versions before the latest version 4.3, including NicheLite, are affected.
|CVE ID||Vendor ID||Description||Affected component||Potential Impact||CVSSv3.1 Score|
|2020-25928||HCCSEC-000002*||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 client||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 server||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 client||DoS
|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 client||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 server||DoS||7.5|
|2021-31400||HCCSEC-000014||The TCP out-of-band urgent data processing function invokes a panic function if the pointer to the end of the out-of-band urgent data points out of the TCP segment’s data, which results in DoS (either an infinite loop or interrupt thrown, depending on NicheStack version).||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|
|2020-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||The DNS client does not set sufficiently random transaction IDs.||DNSv4client||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 client||DNS cache poisoning||4|
CVSS Score Color coding:
- – Medium or high
- – Critical
The best way to fully resolve all NicheStack security issues is to upgrade to NicheStack v4.3.
If that is not possible – here are a few practical ways to mitigate the vulnerabilities:
- Run the open-source script by Forescout Research Labs for detecting devices running NicheStack. The script is updated constantly with new signatures to follow the latest developments.
- Confine and segment vulnerable devices from the rest of the network until they can be patched. Mitigate according to the list below.
|CVE ID||Affected component||Mitigation Recommendation|
|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).|
|HTTP server||Disable the HTTP server if not needed, or whitelist HTTP connections.|
|TCP||For CVE-2021-31400, CVE-2021-31401, and CVE-2020-35684, we recommend monitoring traffic for malformed IPv4/TCP packets and blocking them. E.g., having a vulnerable device behind a properly configured firewall should be sufficient. For CVE-2020-35685, we suggest using the recommendations we outlined in Forescout’s NUMBER:JACK report, whenever it is feasible.|
|2020-35683||ICMPv4||Monitor traffic for malformed ICPMv4 packets and block them.|
- Monitor patches released by the device vendors and create a plan for business continuity until full remediation is complete. The patches released by HCC Embedded, the company that acquired InterNiche Technologies, are available upon request.
- Be on the lookout for malicious packets trying to exploit these vulnerabilities or others.
It is our intention to collaborate with the impacted vendors in a transparent manner. We aim to help them identify affected products and prepare advisories for the community. A detailed technical report of the research from JFrog and Forescout can be found here.
JFrog and Forescout research teams will deliver a joint webinar on August 19th, to provide more information about the vulnerabilities, how they were found and how they can be mitigated. For more information and to register click here.
JFrog and Forescout will also be delivering a talk about this disclosure in Hack In The Box (HITB) Singapore later in August.
For more information about delivering secure software to the edge and for the latest updates on JFrog DevOps Platform security features – click here.