[English]Sicherheitsforscher von Forescout und JFrog haben gerade die unter dem Begriff INFRA:HALT zusammengefassten Schwachstellen in der NicheStack TCP/IP-Bibliothek öffentlich gemacht. Sie waren auf bei der Analyse der Bibliothek darauf gestoßen. Diese NicheStack TCP/IP-Bibliothek wird in Produkten (Industriesteuerungen und IOT-Industriegeräte) von mehr als 200 Anbietern verwendet. Mehr als 6.400 anfällige Geräte sind derzeit online erreichbar.
Anzeige
Gemäß diesem Blog-Beitrag (Report herunterladbar, Artikel findet sich hier), haben Forescout Research Labs und JFrog Security Research 14 neue Schwachstellen im Closed-Source-TCP/IP-Stack NicheStack entdeckt. Die Schwachstellen ermöglichen Denial of Service- oder Remote Code Execution-Angriffe. Das betrifft vor allem Geräte der Betriebstechnik (OT, Operational Technology) und industrielle Kontrollsysteme (ICS, Industrial Control Systems).
Ich hatte es in obigem Tweet gesehen, heise hat diesen deutschsprachigen Beitrag zum Thema veröffentlicht. Das Ganze läuft im Projekt Memoria, wo TCPI/IP-Stacks auf Schwachstellen untersucht werden. INFRA:HALT ist ein weiteres Beispiel für die Probleme mit TCP/IP-Stacks, die bereits mit AMNESIA:33 (siehe Amnesia:33 – Schwachstelle im TCP/IP-Stack gefährdet viele IoT-Geräte) oder NUMBER:JACK (Neue Lücken in TCP/IP-Stacks entdeckt, Patches für Windows TCP/IP-Schwachstellen) angesprochen wurden.
Problem bei INFRA:HALT ist, dass der Closed-Source-TCP/IP-Stack NicheStack in Industrie-Steuerungen eingesetzt wird. So verwenden Siemens in den S7-Steuerungen, aber auch Anbieter von Steuer- und Kontrollsystemen wie Emerson, Honeywell, Mitsubishi Electric, Rockwell Automation und Schneider Electric die Bibliothek. Nachfolgende Tabelle enthält die Liste der Schwachstellen, von denen einige kritisch eingestuft werden.
Anzeige
| 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 warf am 8. März 2021 bei einer Suche nach mit dem Internet vernetzten Geräten, die Anzeichen für eine Verwendung des NicheStack aufweisen, m ehr als 6400 Treffer aus. Das Groß wird in Kanada und den USA betrieben, in Europa liegen Spanien, Schweden und Italien auf den vorderen Plätzen. Es gibt aber wohl auch Treffer in Deutschland, wie die Karte hier zeigt.
Der Hersteller HCC Embedded hat die Schwachstellen in NicheStack Version 4.3 beseitigt, wie sich in diesem Sicherheitshinweis nachlesen lässt. Jetzt kommt es darauf an, dass die Hersteller von Automatiserungsgeräten diese neue Version als Patch bereitstellen und Anwender dann die Updates auch installieren. Für Administratoren möchte ich auf diese GitHub-Seite von Forescout verweisen. Dort gibt es den in Python geschriebenen project-memoria-detector. Mit dem Tool project-memoria-detector kann überprüft werden, ob auf einem Ziel-Netzwerkgerät ein bestimmter eingebetteter TCP/IP-Stack mit angreifbaren Schwachstellen läuft.
Ähnliche Artikel:
Amnesia:33 – Schwachstelle im TCP/IP-Stack gefährdet viele IoT-Geräte
Neue Lücken in TCP/IP-Stacks entdeckt, Patches für Windows TCP/IP-Schwachstellen
Gefährden IoT-Geräte mit eingebauten "Radio-Chips" die IT-Sicherheit
Anzeige
"Die einzige Lösung bei all den schlimmen Lücken ist eine Zugangsbeschränkung für das gesamte Internet mit nur noch eindeutig identifizierten Teilnehmern über komplett abgesicherte Hardware (TPM usw.), dann können die bösen Hacker nichts mehr angreifen."
Oder so ähnlich. Siehe auch Cyber Polygon Agenda…