Noch kein Update: DNS-Poisoning-Lücke in vielen IoT-Geräten
Eine Sicherheitslücke in den Bibliotheken uClibc und uClibc-ng vereinfacht DNS-Poisoning-Angriffe, die Anfragen auf fremde Server umleiten.
(Bild: Outflow_Designs / Shutterstock.com)
Bei der Untersuchung der DNS-Anfragen eines Gerätes stießen Forscher von Nozomi Networks auf eine Schwachstelle in den DNS-Auflösungsfunktionen der uClibc und uClibc-ng. Das Domain Name System (DNS) löst in der Regel menschenlesbare Adressen (etwa heise.de) in die eigentlichen IP-Adressen der Zielmaschinen (hier 193.99.144.80) auf. Da der Maintainer der Bibliothek uClibc keine Lösung für das Problem findet, soll die jetzige Veröffentlichung Experten ermuntern, bei der Lösungssuche mitzuhelfen.
Die Bibliotheken uClibc und uCLibc-ng kommen insbesondere in Geräten mit wenig Speicher und wenig Prozessorleistung wie Internet-Router und Internet-of-Things-Geräten zum Einsatz. uC steht dabei für Mikrocontroller, korrekter als µC geschrieben. Während uClibc-ng eine speziell für OpenWRT angepasste Version der Bibliothek ist, nutzen etwa Axis, Linksys, Netgear oder Linux-Distributionen wie Embedded Gentoo uClibc. Diese Standard-C-Bibliotheken stellen für in der Programmiersprache C programmierte Anwendungen Grundfunktionen bereit, etwa Textausgaben auf Schnittstellen oder eben die DNS-Auflösungsabwicklung.
Manipulierbare Namensauflösung
Eine DNS-Anfrage nutzt das UDP-Protokoll, ist also verbindungslos. Sie enthält neben dem Satz aus Quell-IP, Quell-Port, Ziel-IP, Ziel-Port und Protokoll-Angabe die angefragten Daten sowie einen Parameter Transaction-ID. Diese ID ist eine einmalige, vom anfragenden Client erstellte Nummer. Der DNS-Server muss unter anderem diese ID in der Antwort aufführen, die der Client andernfalls als ungültig verwirft.
Innerhalb eines Netzwerkes sind Quell-IP (des anfragenden Clients), Ziel-IP sowie Ziel-Port (DNS-Server des Netzes, Standard-Port für herkömmliches DNS ist 53) und Protokoll (DNS nutzt UDP) bekannt. Unbekannt bleiben also der Quell-Port des anfragenden Geräts und die Transaction-ID. Wenn der Angreifer diese korrekt errät und an das anfragende Gerät eine manipulierte Antwort mit einem eigenen Server als Ziel der Auflösung sendet, die vor der Antwort des echten DNS-Servers ankommt, kann ein bösartiger Akteur die Anfragen auf seinen eigenen Server umleiten.
Daher sollten aus Sicherheitserwägungen beide Parameter möglichst zufällig und schwer zu erraten sein. Andernfalls könnten Angreifer nach erfolgreicher Attacke möglicherweise weiter reichende Angriffe innerhalb eines betroffenen Netzwerkes ausführen.
Die entdeckte Sicherheitslücke betrifft die Transaction-ID, die uClibc und uClibc-ng erzeugen. Sie lässt sich sehr leicht erraten. In ihrem Blog-Beitrag beschreiben die Nozomi-Forscher, wie sie die Lücke im Quellcode nachvollziehen konnten. Einige weitere Nebenbedingungen erläutern sie zudem, dass etwa für Angreifer hilfreich wäre, wenn Geräte häufiger DNS-Auflösungen erzeugen oder etwa die konkrete Implementierung in dem Gerät den Quell-Port ebenfalls einfacher vorhersagbar machten.
Problem an IoT-Geräten noch ungelöst
Die Ursache bleibt derzeit ungelöst. Daher wollen die Forscher nicht genau benennen, mit welchen Geräten sie die Tests gemacht haben. Es waren jedoch mehrere namhafte IoT-Geräte mit aktueller Firmware, die mit hoher Wahrscheinlichkeit nahezu überall in kritischer Infrastruktur installiert sind.
Nozomi arbeitet dem eigenen Bekunden nach mit dem Projekt-Maintainer bei der Lösungsfindung zusammen.
Der zeitliche Verlauf des Falles listet seit September 2021 zahlreiche Kontakte mit unterschiedlichen CERTs (Computer Emergency Response Teams) auf. Zudem wurden mehr als 200 Hersteller diesbezüglich kontaktiert. Bis schließlich vor etwa sechs Wochen der Projekt-Maintainer selber mit in die Kommunikation aufgenommen wurde. Dieser erklärte, er könne das Problem nicht lösen und bat um Mithilfe. Nun hoffen alle Beteiligten auf Hilfe aus der Community.
Update 05.05.2022 11:40 Uhr: Einer der OpenWRT-Entwickler, Hauke Mehrtens, hat uns darauf hingewiesen, dass uClibc lediglich bis OpenWRT 15.05 eingesetzt wurde. Darauf basieren Firmwares auch aktuell noch im Verkauf stehender Produkte mehrerer ungenannter Hersteller. Seit OpenWRT / Lede 17.01 kommt die musl libc zum Zuge, außer für Synopsys ARC CPUs – da kam uClibc-ng zum Einsatz. Seit OpenWRT 21.02 wurde uClibc-ng jedoch vollständig aus dem Projekt entfernt.
Themenseite zu Internet of Things auf heise online
(dmk)
