Thought Leadership
OTORIO, Experte für OT-Sicherheit veröffentlicht Details zu einer aktuellen OT-Sicherheitsschwachstelle in cloud-verwalteten Routern. InHand Networks ist ein Unternehmen in der industriellen IoT-Branche. Es hat sich auf eine breite Palette von Produkten wie industrielle M2M-Router (Machine to Machine), Gateways, industrielle Ethernet-Switches, Industrie-Computer und Management-Plattformen für IoT (Internet of Things) spezialisiert. Seine Lösungen sind in verschiedenen Bereichen zu finden, darunter Smart Grid, Industrieautomation, Fernüberwachung von Maschinen, automatische Verkaufskonzepte (Smart Vending), Entwicklungskonzepte für Städte (Smart City) oder Einzelhandel.
Der Device Manager, entwickelt und betrieben von InHand Networks, ist eine cloud-basierte Plattform für das Management von M2M- und IoT-Geräten. Sie bietet eine benutzerfreundliche Oberfläche und einfache Schritte zur Bedienung, die es den Anwendern ermöglichen, die Hardware-Geräte von InHand wie zum Beispiel industrielle Mobilfunk-Router und Gateways bequem zu verwalten und zu überwachen. Mit nur wenigen Klicks lassen sich diese Geräte problemlos in die Device Manager-Plattform integrieren und verwalten. Zu den unterstützten Geräten gehören zum Beispiel InRouter200, InRouter300, InRouter600, InRouter900, InGateway900, InGateway500, InVehicleG710 oder InVehicleG810.
Bei unserer Recherche haben wir uns auf das Modell InRouter615-S konzentriert, das zur InRouter600-Serie gehört. Der InRouter600-S (auch bekannt als IR600-S) besteht aus einer Serie von IoT-Routern, die Unterstützung für 3G/4G, Wi-Fi und VPN zur Verfügung stellen. Diese Router ermöglichen einen einfachen Netzwerkzugang für Feldgeräte, indem sie Technologien für 3G/4G Wireless WAN und Wi-Fi Wireless LAN verwenden.
Kommunikation zwischen InRouter und “Geräte-Manager“
Während des Startvorgangs des Routers erfolgt eine schwache Registrierung auf der Plattform des “Device Manager”, bei der die Seriennummer des Routers zusammen mit einem Cloud-Account des “Device Manager” gesendet wird. Wenn sowohl der Account als auch die Seriennummer gültig sind, ordnet der “Device Manager” das Gerät dem Account zu und sendet MQTT-Anmeldeinformationen (Message Queuing Telemetry Transport). Mit diesen MQTT-Zugangsdaten baut das Gerät dann sofort eine Verbindung zum “Device Manager” auf.
Der MQTT-Broker des “Device Manager” verwaltet zwei primäre MQTT-Themen für jeden mit der Cloud verbundenen Router:
- v1/id/task/notice – für den Empfang von Aufgaben vom “Device Manager”;
- v1/id/task/update – für die Veröffentlichung von Ergebnissen bei diesen Aufgaben.
Die “id” im Namen des Themas (auch “client_id” genannt) besteht aus einer 24-stelligen hexadezimalen Zeichenfolge, die zwischen den Namen der Themen verschiedener Router unterscheidet und sich bei jeder neuen Sitzung ändert.
Nach der Verbindung mit MQTT sendet der “Device Manager” umgehend die Aufgabe “Get Config”, und die Geräte antworten mit der Veröffentlichung ihrer Konfigurationsdateien.
Schwachstellen in der Plattform des “Device Manager”
- Verwendung von unzureichenden Zufallswerten (CVE-2023-22601)
Um den Registrierungsprozess genauer zu untersuchen, haben wir ein Python-Skript installiert, das in regelmäßigen Abständen wiederholte Registrierungen durchführt. Bei der Datenanalyse entdeckten wir ein interessantes Muster: Die ersten 8 hexadezimalen Zeichen in den Registrierungsdaten entsprachen dem Zeitstempel jeder Registrierung, während der zweite Teil der Daten bei jeder neuen Registrierung um die Anzahl 2 erhöht wurde.
Als Nächstes führten wir weitere Registrierungen mit einem Abstand von 5 Minuten zwischen den einzelnen Versuchen durch. Bei dieser Analyse stellten wir fest, dass sich der zweite Teil der Geräte-ID zwischen der zweiten und dritten Registrierung um die Anzahl 4 erhöhte. Dieses Ergebnis deutet darauf hin, dass es sich um ein echtes Gerät handelt, das mit der Cloud verbunden ist. Mit einem Zeitfenster von 300 Sekunden (5 Minuten) für den ersten Teil der Geräte-ID und dem bekannten Wert von 472 für den zweiten Teil konnten wir die Möglichkeiten eingrenzen und die IDs für andere Geräte leicht prognostizierbar machen.
- Unzulässige Zugriffskontrolle (CVE-2023-22600)
Nachdem wir versucht hatten, alle 300 verfügbaren Optionen für den Aufgabenamen der MQTT “v1/id/task/update” zu abonnieren, den der Router zur Veröffentlichung von Ergebnissen der Aufgaben verwendet, gelang es uns nach 175 Versuchen, die richtige ID zu finden. Dadurch konnten wir auf die Konfigurationsdatei des Geräts zugreifen und sie abrufen. Durch diesen Durchbruch ermutigt, haben wir unsere Fähigkeiten durch die erfolgreiche Änderung des Host-Namens weiter verbessert.
- Einschleusen von Befehlen des Betriebssystems (CVE-2023-22598)
Um eine “Remote Code Execution” zu erreichen, untersuchten wir die InRouter-Firmware eingehend und konzentrierten uns dabei auf die Funktionen, die für die Aufgliederung der Gerätekonfigurationen verantwortlich sind. Nachdem wir die Firmware extrahiert und gründlich untersucht hatten, machten wir eine wichtige Entdeckung: Innerhalb des Codes fanden wir eine geschäftskritische Schwachstelle “Command Injection”. Dieser Defekt befand sich in der Funktion, die für die Verarbeitung des Parameters “auto_ping” der Gerätekonfiguration zuständig ist.
Bei näherer Betrachtung stellten wir fest, dass die Funktion “ping_action_start” ausgelöst wird, wenn der Parameter “auto_ping_enable” auf “1” gesetzt ist. Diese Funktion verknüpft die Zeichenfolge aus dem Parameter “auto_ping_dst” mit einem Ping-Befehl, so dass das Gerät die Verbindung mit dem Internet prüfen kann.
Unter Ausnutzung der fehlenden Bewertung der IP-Adresseneingabe im Parameter “auto_ping_dst” haben wir einen “Reverse Shell”-Befehl angehängt, der zur Ausführung des entfernten Codes mit Root-Rechten führte. Bei dieser Auswertung wurden die relevanten Parameter geändert und die aktualisierte Konfiguration mit der Aufgabe “SET config” übertragen.
Einsatz von Routern, die über die Plattform “Device Manager” verwaltet werden
Durch die Verkettung dieser Schwachstellen konnten wir ein bestimmtes Gerät anhand seiner Seriennummer oder andere nach dem Zufallsprinzip mit der Cloud verbundenen Geräte angreifen. Um jedoch die Sicherheit realer Umgebungen zu gewährleisten, konzentrierten wir uns ausschließlich auf die Demonstration eines Angriffs auf unser eigenes Gerät, der ausschließlich auf dessen Seriennummer abzielte.
Indem wir uns auf den fehlerhaften Registrierungsmechanismus stützten, haben wir ein Skript entwickelt, das sich als unseren eigenen Router ausgibt und die Registrierung beim „Device Manager” unter Verwendung der Kennzahlen des Routers einleitet. Während dieses Vorgangs haben wir die Antwort des „Device Manager“ genau überwacht und dabei insbesondere den zweiten Teil des Parameters “id” analysiert.
Als Ergebnis dieses Prozesses wird der ursprüngliche Router automatisch neu registriert, was zu einer Erhöhung des zweiten Teils des “id”-Parameters um mehr als 2 Punkte im Vergleich zur vorherigen Registrierung führt. Dies deutet darauf hin, dass ein weiteres Gerät vorhanden ist, das sich erfolgreich bei der Cloud registriert hat.
Anschließend hat unser Skript systematisch alle 300 möglichen Themen für das neu registrierte Gerät abonniert, bis es schließlich das richtige Thema gefunden hat. Sobald das richtige Thema gefunden ist, veröffentlicht der “Device Manager” die letzte Nachricht, die der echte Router an dieses spezielle Thema gesendet hat und die die Konfigurationsdatei enthält. Um sicherzustellen, dass das Gerät unseren Erwartungen entspricht, führen wir dann einen Verifizierungsschritt durch.
Nach der Überprüfung ändern wir den Konfigurationsparameter “auto_ping”, indem wir den Befehl “reverse shell” hinzufügen und dann die aktualisierte Konfigurationsdatei mit der Aufgabe “SET config” auf dem Router veröffentlichen. Das kompromittierte Gerät startet automatisch neu und initiiert eine Remote-Shell mit Root-Rechten.
Entschärfung der Schwachstelle
InHand Networks hat die Cloud-Schwachstellen zusätzlich zu einer aktualisierten Firmware-Version entschärft. InHand empfiehlt Anwendern die betroffene Geräte-Firmware auf die neueste Version zu aktualisieren:
- Anwender von InRouter302 sollten die Firmware auf IR302 V3.5.56 oder später aktualisieren.
- Anwender von InRouter615 sollten die Firmware auf InRouter6XX-S-V2.3.0.r5542 oder später aktualisieren.
www.otorio.com
