[German]Security researchers from Forescout and JFrog have just made public the vulnerabilities in the NicheStack TCP/IP library grouped under the term INFRA:HALT. They had come across it while analyzing the library. This NicheStack TCP/IP library is used in products (industrial controllers and IOT industrial devices) from more than 200 vendors. More than 6,400 vulnerable devices are currently accessible online.
According to this post (report downloadable, article can be found here), Forescout Research Labs and JFrog Security Research have discovered 14 new vulnerabilities in the closed-source NicheStack TCP/IP stack. The vulnerabilities allow denial of service or remote code execution attacks. This primarily affects operational technology (OT) devices and industrial control systems (ICS).
I had seen it in above tweet, the topic was uncovered within the Memoria project, where TCPI/IP stacks are examined for vulnerabilities. INFRA:HALT is another example of the problems with TCP/IP stacks that have already been addressed with AMNESIA:33 (see Amnesia:33 – Vulnerability in TCP/IP stack put many IoT devices at risk) or NUMBER:JACK (see New vulnerabilities discovered in TCP/IP stacks, patches for Windows TCP/IP vulnerabilities).
Problem with INFRA:HALT is that the closed-source TCP/IP stack NicheStack is used in operational technology systems (OT) and industrial control systems (ICS). For example, Siemens uses the library in its S7 controllers, but also vendors such as Emerson, Honeywell, Mitsubishi Electric, Rockwell Automation and Schneider Electric are customers of HCC Embedded and use NicheStack. The following table contains the list of vulnerabilities, some of which are classified as 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|
Shodan threw up m ore than 6400 hits on March 8, 2021, in a search for Internet-connected devices that showed signs of using the NicheStack. The large is operated in Canada and the U.S.; in Europe, Spain, Sweden and Italy are at the top of the list. But there are probably also hits in Germany, as the map here shows.
The manufacturer HCC Embedded has removed the vulnerabilities in NicheStack version 4.3, as can be read in this security advisory. Now it is important that the manufacturers of automation devices provide this new version as a patch and that users then also install the updates. For administrators, I would like to point to this GitHub page from Forescout. There you can find the project-memoria-detector written in Python. The tool project-memoria-detector can be used to check if a target network device is running a certain embedded TCP/IP stack with vulnerable vulnerabilities.
Amnesia:33 – Vulnerability in TCP/IP stack put many IoT devices at risk
New vulnerabilities discovered in TCP/IP stacks, patches for Windows TCP/IP vulnerabilities
Do IoT devices with built-in "radio chips" endanger IT security?
Cookies helps to fund this blog: Cookie settings