Hacker's Cookbook: Ausnutzen von IoT-Küchengeräten mit WHIDBOARD

HUNGRIG NACH HARDWARE-HACKS

Vor kurzem habe ich die Forschung und Entwicklung eines neuen Spielzeugs namens WHIDBOARD abgeschlossen und um es zu testen, habe ich mich entschlossen, mir ein IoT-Küchengerät anzusehen, das ich gebraucht bei Amazon gekauft habe. Das Ergebnis war unerwartet amüsant!

Das Ziel

Das Testgerät (DUT) dieses Blogbeitrags ist ein intelligentes Kochgerät namens Mambo Touch von Cecotec, einem spanischen Unternehmen.

Dieses All-in-One-Kochgerät ist eine multifunktionale Küchenmaschine mit 37 Funktionen, die über einen 5-Zoll-Touchscreen verfügt und über eine mobile App ferngesteuert werden kann (wie Sie auf den Bildern unten sehen können) und sich über ein WLAN-Netzwerk verbindet.

Da das generalüberholte Gerät günstiger war und ich es ohnehin nicht zum Kochen verwenden werde, habe ich mich direkt dafür entschieden.

Überholt ≠ Zurücksetzen auf Werkseinstellungen

In der Regel erlaubt Amazon seinen Kunden, Artikel zurückzugeben, die ihnen nicht gefallen oder die nicht ihren Erwartungen entsprechen...

Es stellt sich jedoch die berechtigte Frage: Was geschieht anschließend mit diesen Artikeln? Wie werden sie generalüberholt? Was ist mit einer Werksrücksetzung VOR dem Wiederverkauf?

Nach dem Einschalten habe ich mich mit meinem WLAN-Netzwerk verbunden und versucht, das Gerät mit der mobilen App zu koppeln... doch es kam zu einer ungewöhnlichen Situation. Das Testgerät war bereits mit einem anderen (vermutlich früheren) Besitzer gekoppelt...

Ich frage mich, was ein DPO dazu sagen würde...

DUT-Teardown

Bei einer ersten Inspektion des Äußeren fällt ein erster Hinweis auf: ein versteckter USB-Micro-Anschluss.

Nach dem Anschließen an einen Computer geschieht jedoch nichts Besonderes. Der nächste Schritt bestand darin, das Gerät zu öffnen. Unter allen anderen Komponenten (Touchscreen, Schalter, Sensoren, Motoren, Netzteil usw.) wurde ich vom Mainboard begrüßt.

Hier können wir die wichtigsten Komponenten leicht erkennen:

• A213Y Amlogic SoC
• KLM8G1GETF-B041 ist ein 8 GB eMMC-Flash-Speicher mit einer FBGA-153-Grundfläche
• RS256M16V0DB-107AT DDR SDRAM mit einem FBGA-96-Footprint

Darüber hinaus sind einige interessante Einstiegspunkte für Debugging-Schnittstellen vorhanden.

Der interessanteste Einstiegspunkt befand sich jedoch auf der anderen Seite: einige Testpads, die mit der üblichen Pinbelegung der UART-Debugging-Schnittstelle gekennzeichnet waren (d. h. GND, RX, TX).

Der nächste Schritt war einfach... Ich lötete ein paar Drähte an diese Pads, nahm mein WHIDBOARD zur Hand und überprüfte mit dem Logikanalysator und dem Pin-Enumerator, ob es sich tatsächlich um eine UART-Debugging-Schnittstelle handelte...

Zunächst habe ich alle Drähte an den Logikanalysator-Anschlussblock des WHIDBOARDS angeschlossen, um einige Daten zu erfassen... und das habe ich auf Pulseview erhalten:

Root-Zugriff über UART

Ausgezeichnet! Wir konnten leicht bestätigen, dass die drei Testpads auf der Rückseite der Leiterplatte tatsächlich eine funktionierende UART-Konsole sind. Wir können sehen, wie das DUT die Startsequenz aus dem Logikanalysator ausgibt. Als Nächstes versuchen wir, eine direkte Verbindung mit dem WHIDBOARD und dem Pin Enumerator herzustellen.

Die Pin-Enumerator-Funktion des WHIDBOARD basiert auf dem (leider nicht mehr erhältlichen) JTAGulator von Joe Grand. Damit können Sie Pins von Debugging-Schnittstellen wie UART, JTAG und SWD erkennen. In meinem Fall habe ich jedoch hauptsächlich die Passthrough-Funktion verwendet, um mit dem an den Anschlussblock angeschlossenen Ziel zu kommunizieren (und natürlich die richtige UART-Pin-Kombination zu bestätigen).

Nachdem ich mit dem Pin Enumerator bestätigt hatte, dass ich tatsächlich vor einem UART-Debug-Port stand, nutzte ich die Passthrough-Funktion und wurde von einer ansprechenden Terminal-Konsole mit Root-Zugriff begrüßt.

Wie geht es weiter?

An dieser Stelle wird deutlich, dass das Gerät leicht kompromittiert werden kann. Ich wollte jedoch noch etwas experimentieren und überprüfen, wie die Fernverbindung funktioniert.

Zunächst habe ich die ADB-Fernverbindung über WLAN mit den folgenden Befehlen aktiviert:

Und ich habe überprüft, ob alles einwandfrei funktioniert:

Bereits jetzt verfügen wir über eine dauerhafte Fernverbindung (d. h. dasselbe LAN) mit dem DUT. Da der ADB-Server-Daemon auch nach dem Neustart bestehen bleibt.

Als Nächstes war es an der Zeit, einige Erkundungen durchzuführen und nach interessanten Informationen zu suchen. Zunächst habe ich die installierten Apps aufgelistet, um zwei Dinge zu überprüfen: Welche Android-Version läuft und welche sind die wichtigsten Apps des Anbieters (d. h. Cecotec).

Die beiden interessantesten Apps sind:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Bevor ich jedoch mit der Überprüfung fortfuhr, führte ich schnell die übliche Android-Einstellungs-App aus (mit diesem Befehl am start -n com.android.settings/.Settings), um weitere Informationen über die Betriebssystemversion zu erhalten ... und wie erwartet lief auf dem DUT eine alte Android-Version: 4.4.2.

Gut, lassen Sie uns weiterforschen. Es ist Zeit für eine Netzwerküberprüfung. Anhand der netstat-Ausgabe kann ich einige Verbindungen mit Internet-IP-Adressen erkennen:

Nichts Besonderes, aber eine Verbindung weckte meine Neugier... Da es sich offensichtlich um ein Backend handelte, das nicht zu meinem Zuständigkeitsbereich gehörte, wurde es als außerhalb meines Aufgabenbereichs liegend betrachtet, und ich fuhr fort...

Als Nächstes habe ich mich nach den üblichen Tools für Hacker umgesehen, mit denen sich IoT-Ziele exfiltrieren oder Reverse-Shells erstellen lassen... eines für alle... Seine Majestät BUSYBOX :D

Und tatsächlich war hier alles enthalten, was ich benötigte:

Nur damit konnte ich Daten extrahieren, hochladen, manipulieren und auch eine Reverse-Shell mit netcat erhalten. Aber lassen Sie uns weitermachen! Da wir bereits eine persistente ADB-Shell haben, benötigen wir BusyBox dieses Mal nicht.

Insgesamt habe ich mit ADB Explorer alle möglichen interessanten Dateien extrahiert, die ich gefunden habe. Allerdings nichts wirklich Interessantes... Dieses Gerät verfügt weder über ein Mikrofon noch über eine Kamera... wir können nicht einmal aus der Ferne Personen überwachen... leider... :(

APK-Analyse

An diesem Punkt habe ich meinen Fokus auf die APKs des Anbieters verlagert:

• package:/data/app/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest
• package:/data/app/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501

Die com.zavier.androidrk3326functiontest-1.apk scheint eine Funktionstestsuite zu sein, um zu überprüfen, ob alle Sensoren und Motortreiber ordnungsgemäß funktionieren. Bedenken Sie, dass dieses IoT-Kochgerät über eine integrierte Waage, eine Heizung, einen Motor zum Mischen der Lebensmittel und verschiedene Sensoren verfügt. Und offenbar werden sie alle von diesen beiden Apps gesteuert (auch aus der Ferne vom Benutzer mit seinem Mobiltelefon...).

In Bezug auf die com.kitchenidea.cecotec.k2501-2.apk stellte ich schnell fest, dass es sich um eine Kopie der anderen update.apk in /sdcard/, sodass es nicht erforderlich ist, beide zu überprüfen:

Ein Blick auf die zweite APK hat keine besonderen Auffälligkeiten ergeben, jedoch wurde bestätigt, dass die App vollen Zugriff auf alle Sensoren, Heizungen, Motoren usw. hat. Theoretisch könnten wir eine Malware erstellen, die das Opfer aus der Ferne beeinträchtigen könnte, indem sie beliebige Befehle an die seriellen Schnittstellen sendet.

Ich habe auch überprüft, ob in diesen beiden Apps weitere interessante URLs/IPs fest codiert sind, jedoch scheinen es sich um die üblichen durchschnittlichen Daten zu handeln:

Da ich in Eile und genervt war, habe ich schließlich MobSF ausgeführt, um mir einen schnellen Überblick über das Risikoniveau dieser beiden Apps zu verschaffen...

TL;DR: Nichts Besonderes. Eine durchschnittliche App für ein durchschnittliches Produkt. 8)

Insgesamt ist klar, dass dieses Gerät mit einer benutzerdefinierten APK, die von einem Angreifer ferngesteuert werden kann, potenziell als Waffe eingesetzt werden kann, um die internen Funktionen zu manipulieren und physische Schäden zu verursachen (z. B. Sicherheitsmaßnahmen außer Kraft setzen, den Topf überhitzen usw.).

Streiche und Reverse Shell

Als letzte Übung, bevor ich dieses Produkt zurückschicke und es Amazon zurückschicke, wollte ich überprüfen, ob eine Meterpreter-Reverse-Shell funktionieren würde und ob ich damit DOOM oder einige Streiche mit meiner Frau spielen könnte. Nun ja... :D

Zunächst bereiten wir eine Meterpreter-APK vor, die mit ADB übertragen werden kann:

Anschließend übertragen wir sie über ADB und installieren sie:

Nun führen wir sie aus:

In der Zwischenzeit wurde auf der virtuellen WHIDOS-Maschine bereits der MSF-Listener eingerichtet:

Jedes Mal, wenn das Gerät neu gestartet wird, wird nun automatisch die Reverse Shell ausgeführt und der C2 des Angreifers zurückgerufen:

Zu diesem Zeitpunkt war die Installation und Ausführung von DOOM nur noch eine Frage von Sekunden... :D

Fazit

Der IoT-Markt ist allgemein dafür bekannt, dass er voller anfälliger Geräte ist. Leider nehmen die meisten Unternehmen die Produktsicherheit nicht ernst genug, was für den Durchschnittsverbraucher bedauerlich ist. In den meisten Fällen hat ein kompromittiertes IoT-Gerät möglicherweise keine großen Auswirkungen auf das Leben der Verbraucher, aber in einigen Fällen kann es zu physischen Schäden führen. Wie in diesem Fall, in dem Heizung und Motor über die App ferngesteuert werden und ein potenzieller Angreifer ebenfalls die Kontrolle darüber erlangen könnte.

Darüber hinaus ist es offensichtlich, dass der Kauf von generalüberholten IoT-Geräten in manchen Fällen möglicherweise keine kluge Entscheidung ist.

Was wäre, wenn ich vor der Rücksendung des Geräts an Amazon eine schädliche Payload hinterlassen hätte? (Haftungsausschluss: Nein, das habe ich nicht getan.)