Angriffsvektoren auf aktuelle embedded Linux Busybox/Buildroot Systeme (IoT/Router/Smart Home) wegen Sicherheitslücken in veralteter Softwarebasis

Der initiale Post wurde am 27.06.19 verfasst.
Veraltete Busybox oder Buildroot Versionen können zu einem Problem werden, da diese Sicherheitslücken enthalten.

Heutzutage ist Software Pflege das A und O um nicht verwundbar zu sein.
Die Hersteller sind in guter Gesellschaft, es ist keiner Besser als der andere. Viele setzen teilweise veraltete oder sehr veraltete Versionen als Basis ein!

Wichtig zu wissen: Das Datum in der Versionsausgabe von Busybox ist das Datum der Kompilierung und nicht das Release Datum!
Es gibt alleine 17 CVEs zur Busybox als eigenständiges Produkt:
Busybox on cvedetails.com
Und es gab weitere Sicherheitsupdates, die nicht explizit als CVE bekannt geworden sind.
Zumindest die bekannten Lücken im DHCP und NTP wären dann eine Angriffsmöglichkeit.

Und die Buildroot in einigen Systemen ist wahrscheinlich noch viel mehr betroffen
Buildroot changes
Alle CVEs aufgelistet in den Commits, mit 50 Einträge pro Seite
Search CVEs in Buildroot commits - page 1
bis
Search CVEs in Buildroot commits - page 900
ergeben Stand heute 2019-06-27 932 Updates wegen Zuordnungen zu CVEs !!!

Bisher habe ich drei Anfragen mit dieser Fragestellung rausgeschickt

Ist ihnen die veraltete Busybox/Buildroot „Problematik“ bewusst und gibt es allgemeine Bestrebungen Firmware Releases auf neuerer Basis rauszubringen?
Zumindest die bekannten Lücken im DHCP und NTP wären dann eine Angriffsmöglichkeit.

Dazu habe ich diese Antworten erhalten

Anfrage an Utimaco zu deren HSM Se2 Se1500 mit der Firmware FIPS-5.0.10.1, da diese eine BusyBox Installation besitzt.

strings /mnt/busybox/bin/busybox |grep "v1."
BusyBox v1.19.4 (2016-03-02 16:57:18 GMT)

Die Busybox Version ist wie oben erwähnt nicht vom 2016-03-02, da wurde sie nur kompiliert.
Die Version 1.19.4 wurde am 04.02.2012 Released und ist somit mit nun 7 Jahren deutlich älter (https://www.busybox.net/oldnews.html)

Antwort vom Utimaco Support:

Busybox wird nur beim Hochfahren der CSLAN und beim booten in earlyboot benutzt.
Wenn die CSLAN gestartet wird, wird der init-Prozess ausgeführt; dieser mounted die Partitionen und startet das Linux from Scratch Betriebssystem.
Erst durch das LFS-Betriebssystem wird der Netzwerkstack und die benötigten Dienste gestartet.
Busybox wird zu diesem Zeitpunkt nicht mehr benutzt;
Die Busybox Sicherheitslücken sind damit im Betrieb des CryptoServer LAN nicht mehr relevant.

Dann möchte ich das mal glauben

Anfrage an eQ-3 zur Homematic CCU2 mit einer BusyBox v1.20.2 aus dem Jahre 2012 & Buildroot 2012.08 und der CCU3 mit einer BusyBox v1.29.2 & Buildroot 2018.08.2. Die CCU3 ist also recht aktuell aus 2018.
Antwort von eQ-3:

Hier prüfen wir, welche Teilaspekte wir beheben werden und ob ggf. einzelne Aspekte nicht behoben werden.
Tests bezogen auf neue Versionen von Fremdsoftware sind häufig sehr aufwendig und können teilweise auch zu dem Ergebnis führen, dass eine Interoperabilität mit unseren Softwareanteilen nicht mehr gegeben ist, so dass alternative Lösungen gefunden werden müssen.
Insofern ist die Einschätzung der Umsetzbarkeit/ zeitlichen Umsetzung nicht einfach.

Im speziellen zur CCU2 diese Antwort

Die Aspekte dieser Schwachstelle, die einen potentiellen Zugriff von außen ermöglichen werden hier priorisiert angegangen. Hier prüfen wir, wie wir das Thema möglichst schnell in den Griff bekommen.

Hier muss/wird etwas passieren, siehe CVE-2019-9582 –> am 09.12.2019 ist es dann passiert. Die Buildroot wurde hochgezogen und ist aktuell sogar neuer als auf einer CCU3.

Anfrage an AVM zu deren Produkten

Die FRITZ.Box 7490
    Die Firmware 06.93 enthält die Buildroot 2013.05 und BusyBox 1.22.1 (stable) vom 20 January 2014
    Die Firmware 07.01 bis 7.12 enthalten die Buildroot 2016.05 und BusyBox 1.24.2 (stable) vom 24 March 2016
    Die aktuelle 07.12 Beta/Labor Version vom 19.12.2019 wurde auf die BusyBox v1.29.3 vom 9 September 2018 hochgezogen

Der FRITZ.Box WLAN Repeater 1750E
    Die Firmware 06.93 enthält die Buildroot 2013.05
    Die Firmware 07.01 und 07.10 enthalten die Buildroot 2016.05

Antwort vom AVM Support:

Vielen Dank für Ihren Hinweis. Bzgl. der von Ihnen angeführten Schwachtstellen im Bereich dhcp und ntp können wir entwarnung geben: Fritz!OS verwendet keine dieser Funktionen aus dem Busybox-Projekt.
Wir nehmen Ihr Schreiben dennoch zum Anlass, die Integration neuerer Busybox-Versionen in künftige FRITZ!OS-Releases zu prüfen.

Anhand der 07.12 Beta/Labor Version sieht man, das etwas passiert ist….

(Noch) nicht nachgefragt habe ich bei Netgear zu deren Produkten, aber da wird eingesetzt:

R8000 – Nighthawk X6 – AC3200 Tri-Band-Gigabit-WLAN-Router
R8000-V1.0.4.28_10.1.54.zip und auch die R8000-V1.0.4.40_10.1.60_BETA.zip
	BusyBox v1.7.2 --> Releasedatum 10 September 2007 !

NETGEAR Nighthawk Gaming WLAN Router XR700 Pro
XR700-V1.0.1.8.zip
	BusyBox v1.4.2  --> Releasedatum 18 March 2007 !

Ist das Wahr? So ein alter Stand?
Beim Schreiben dieses Artikel möchte ich das für die Busybox glauben, habe aber durch die Recherchen zu der Anzahl der CVEs in der Buildroot Zweifel bei den Produkten die auf einen Buildroot Release aufbauen.

Update am 03.12.19:
Mittlerweile habe ich auch die Gateways der KNX Welt aus der Gebäudeautomation entdeckt. Es gibt Gateways verschiedener Markenersteller wie Jung, Gira, Hager, ise, …. um einen KNX Bus ins lokale LAN oder Internet zu bringen, um sie zu steuern. Oder anders herum, um aus der KNX Welt heraus dann Sonos oder Philips HUE Geräte im WLAN zu steuern.
Alle haben sie auch eine Busybox, teilweise von 2012, nutzen z.B. einen veralteten Dropbear SSH 2 Server von 2012, ein socat 2.0.0-b8 von 2015, ein nxing von 2016 oder andere Standard-Software Anteile, die allesamt mit CVEs behaftet sind.
Diese “kleinen” Geräte für den Schaltschrank sind teuer, locker 400 € aufwärts. Das hält mich davon ab, mir aus Spass ein Gateway zu kaufen, nur um es kaputt zu testen.

Meine Analysen sind somit erst mal nur auf theoretischer Basis erstellt und haben aber mind. eine Schwachstelle identifiziert.
Die Antwort aus der KNX Welt eines jetzt noch nicht namentlich erwähnten Herstellers lässt mich hoffen, das mein Anliegen ernst genommen wird:

wir bedanken uns ganz herzlich für Ihre mühevolle Arbeit, verbunden mit den wertvollen Informationen, die Sie uns zur Verfügung stellen.
Ihre Recherchen nehmen wir ernst und selbstverständlich zum Anlass für weitere interne Prüfungen. 
Diese werden weitere Zeit beanspruchen, wofür wir bereits jetzt auf Ihr Verständnis hoffen, bevor wir Ihnen dazu qualifiziert antworten können.
Wir werden uns unaufgefordert wieder bei Ihnen melden und bedanken uns nochmal abschließend für Ihre Mühen.

Die unaufgeforderte Antwort kam dann auch Prompt:

vielen Dank für Ihre freundliche, ausführliche und fundierte E-Mail. Erst einmal: Ihre Beobachtungen können wir so bestätigen.
[...]
Da die Produktreleasezyklen in unserem Geschäftsfeld, der Gebäudeautomatisierung, etwas langläufiger sind, [...] Derzeit wird hier an einer neuen Version gearbeitet, die wir in Q2/2020 in den Markt geben werden.
[...]
Nochmals vielen Dank für die ausführliche Analyse und weiterhin viel Erfolg!

Aber ansonsten, die Spiele können beginnen und ich bin kein professioneller Pentester…..
Jeder Hersteller hat meiner Meinung nach die Pflicht, seine Produkte auf CVEs zu scannen. Ich tue das ja auch und ja es kostet Zeit und Arbeit, aber es lohnt sich. Für beide Seiten.
Ist die Basis Software besonders alt, ist es deutlich wahrscheinlicher, Schwachstellen zu haben. Damit sind noch nicht die eigenen Applikationen gemeint, es reicht schon das embedded Linux mit seinen Anteilen.

Disclaimer

The information provided is released “as is” without warranty of any kind. The publisher disclaims all warranties, either express or implied, including all warranties of merchantability. No responsibility is taken for the correctness of this information. In no event shall the publisher be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if the publisher has been advised of the possibility of such damages.

Written on June 27, 2019 | Last modified on December 19, 2019