[English]Sicherheitsforscher von JFrog und Claroty Team82 haben 14 Schwachstellen in dem beliebten Tool BusyBox gefunden. Alle Schwachstellen wurden dem Entwicklerder BusyBox vertraulich mitgeteilt und in der am 19. August veröffentlichen Version 1.34.0 behoben,. Die Schwachstellen hätten zumindest für einem Denial of Service (DoS) Angriff ausgenutzt werden können. In selteneren Fällen wären jedoch auch Informationslecks und möglicherweise Remotecodeausführung möglich gewesen.
Anzeige
BusyBox, was ist das?
BusyBox ist ein 1996 von Bruce Perens geschriebenes Computerprogramm, das verschiedene elementare Standard-Unix-Dienstprogramme vereint. Es läuft auf verschiedenen POSIX-Umgebungen wie Linux, Android oder FreeBSD. Viele Werkzeuge sind jedoch so gestaltet, dass sie mit den Schnittstellen eines Linux-Kernels funktionieren. Bruce Perens wollte damals ein auf eine einzelne Diskette passendes, vollständiges und bootbares Linux-System haben, das sowohl als Rettungssystem, als auch zur Installation eines Debian-Systems verwendbar wäre. BusyBox wurde entwickelt, um auf eingebetteten Betriebssystemen mit sehr beschränkten Ressourcen arbeiten zu können.
Noch etwas Hintergrund
Da viele smarte Geräte mit begrenztem Arbeitsspeicher und Speicherressourcen auskommen müssen, nutzen diese meist ein Tool wie BusyBox, das von Embedded Linux als eine Art „Schweizer Taschenmesser" vermarktet wird. Es handelt sich dabei um eine Software-Suite mit vielen nützlichen Unix-Hilfsprogrammen, so genannten Applets, die als eine einzige ausführbare Datei verpackt sind. BusyBox bietet eine vollwertige Shell, einen DHCP-Client/Server und auch kleine Dienstprogramme wie cp, ls, grep und andere und es läuft auch auf vielen OT- und IoT-Geräten. Außerdem ist es auf beliebten speicherprogrammierbaren Steuerungen (PLCs), Mensch-Maschine-Schnittstellen (HMIs) und Remote-Terminal-Einheiten (RTUs) zu finden.
Analyse der BusyBox auf Schwachstellen
Für die Untersuchung auf Schwachstellen wurde zunächst eine manuelle Überprüfung des BusyBox-Quellcodes in einem Top-Down-Ansatz (Verfolgung der Benutzereingaben bis hin zur spezifischen Applet-Verarbeitung) durchgeführt. Dabei wurde auch nach offensichtlichen Schwachstellen in Bezug auf logische/Speicherkorruption gesucht. Der zweite Ansatz war Fuzzing. BusyBox wurde mit Asan kompiliert und ein AFL-Harness für jedes BusyBox-Applet implementiert. Jedes Harness wurde anschließend optimiert, indem unnötige Teile des Codes entfernt, mehrere Fuzzing-Zyklen auf demselben Prozess ausgeführt (persistenter Modus) und mehrere Fuzzing-Instanzen parallel ausgeführt wurden.
Zuerst wurden alle Daemon-Applets dem Fuzzing unterzogen, einschließlich HTTP, Telnet, DNS, DHCP, NTP und anderer. Viele Codeänderungen waren erforderlich, um netzwerkbasierte Eingaben effektiv zu fuzzen. Es wurden für jedes Applet einige Beispiele vorbereitet und Hunderte von gefuzzten BusyBox-Instanzen wurden über einige Tage laufen gelassen. Dadurch wurden Zehntausende Abstürze generiert, die ausgewertet werden konnten. Dafür haben die Sicherheitsforscher ein automatisches Tool entwickelt, das alle Absturzdaten auf der Grundlage des Absturzanalyseberichts klassifiziert, der hauptsächlich den Stacktrace, die Register und den Assemblercode des betreffenden Codebereichs enthält. Schließlich fand eine Untersuchung jedes einzelnen Absturzes statt, mit minimierten Eingabevektor, um die Ursachen zu verstehen, was die Erstellung eines Proof-of-Concept (PoC) ermöglichte, der die für den Absturz verantwortliche Schwachstelle ausnutzt.
Anzeige
Zusammenfassend sind die folgenden Schritte in unserer Forschung zu nennen:
1. Überprüfung des Codes
2. Fuzzing
3. Reduktion & Minimierung
4. Triage
5. PoC
6. Testen mehrerer Versionen
7. Offenlegung
Bedrohungslandschaft
Für die Open-Source-Security- und Cybersecurity-Communities haben JFrog und Claroty einen einfachen Leitfaden erstellt, der beschreibt, wie man BusyBox fuzzt. Der Leitfaden wird zusammen mit allen Fuzzing-Harnessen veröffentlicht, mit der Hoffnung, dass diese Fuzzing-Logiken von der Community weiter verbessert werden können, um zukünftig noch mehr Fehler in BusyBox zu finden und zu beheben.Bei der Untersuchung von JFrogs Firmware-Datenbank mit mehr als 10.000 Embedded-Firmware fanden die Sicherheitsforscher heraus, dass 40 Prozent von ihnen eine ausführbare Version von BusyBox enthielten, die mit einem der betroffenen Applets verknüpft war, was zeigt, dass diese Probleme unter Linux-basierten Embedded-Firmware weit verbreitet sind.
Die Forscher kommen jedoch zu dem Schluss, dass diese Probleme derzeit keine kritische Sicherheitsbedrohung darstellen, weil:
- Die DoS-Schwachstellen trivial auszunutzen sind, aber die Auswirkungen werden in der Regel durch die Tatsache abgeschwächt, dass Applets fast immer als separater Forked-Prozess ausgeführt werden.
- Die Schwachstelle des Informationslecks ist nicht trivial auszunutzen.
- Die „Use-after-free"-Schwachstellen lassen sich möglicherweise für die entfernte Codeausführung ausnutzen, aber derzeit wurde nicht versucht, einen ausführbaren Exploit für sie zu entwickeln. Darüber hinaus ist es recht selten (und von Natur aus unsicher), ein awk-Muster aus einer externen Eingabe zu verarbeiten.
- Obwohl die Schwachstelle im LZMA-Dekomprimierungsalgorithmus gefunden wurde, unterstützen viele Applets eine LZMA-Komprimierung. Das allgegenwärtige ZIP-Format unterstützt beispielsweise die LZMA-Kompression als "Typ 14"-Kompression.
Aus der Sicht eines Angreifers ist ZIP ein viel besserer Angriffsvektor, da:
- unzip-Aufrufe viel gängiger sind als direkte unlzma-Aufrufe.
- Es bei diesem Angriffsvektor keine Einschränkungen hinsichtlich des Dateinamens gibt (im Gegensatz zum tar Angriffsvektor, der die .lzma Dateiendung erfordert)
- Die ausgespähten Daten können extrahiert und in Dateien gespeichert werden, die später aus der Ferne gelesen werden können.
Behebungen und Workarounds
Alle 14 Sicherheitslücken wurden in BusyBox 1.34.0 behoben und die Benutzer werden dringend gebeten, ein Upgrade durchzuführen. Wenn ein Upgrade von BusyBox nicht möglich ist (aufgrund spezifischer Anforderungen an die Versionskompatibilität), können BusyBox 1.33.1 und frühere Versionen ohne die verwundbaren Funktionen (Applets) als Workaround kompiliert werden. Weitere Informationen über die Untersuchung finden Sie hier.
Anzeige
Was vermutlich vielen Lesern trotz des "Hintergrund-Absatzes" nicht ganz klar sein dürfte: BusyBox ist sehr oft Teil eines größeren Firmwarepaketes und im Bootimage des betreffenden Gerätes gespeichert.
Insofern ist "Aktualisieren von Busybox" etwas was der Endanwender in den seltensten Fällen selbst machen kann sondern man muß warten, bis der Hersteller vom Router, NAS, Webcam oder intelligenten Toaster 😂 ein aktualisiertes Firmwareimage zum Flashen bereitstellt.
Das mag z.B. bei einer FRITZ!Box noch schnell gehen, viele chinesische Billigware wird aber überhaupt nicht mehr supported.
@Fritz gerade mit dem letzten Satz hast du sicher Recht. Außer man installiert Openwrt auf dem Billigrouter dann ist das unschlagbar. Ich gebe aber zu das OpenWRT und die Fritzbox sehr wahrscheinlich unterschiedliche Zielgruppen ansprechen.
Und die meisten anderen werden mangels Kenntnis, mangels Risikobereitschaft, Mut/Fähigkeit ihren eigenen Router umflashen.
Da draußen sind vielleicht Milliarden Geräte, nicht nur Router, welche diese Updates niemals bekommen werden.
In meinem Honey-Pot gab es viele Anfragen/Angriffe auf Busy-Box (ca alle 5 Minuten ein Versuch, x-% davon auf Busy-Box). Mangels Kenntnissen von Busy-Box kann ich aber nicht beurteilen, wie gefährlich das war/ist.