Wir machen TOCTOU wieder großartig - X (R) IP

In diesem Blogbeitrag stellen wir eine neue Art von Angriff gegen eingebettete Systeme vor, die auf XiP (eXecute in Place) basieren und TOCTOU auf Hardwareebene ausnutzen, um den sicheren Start zu umgehen.

TOCTOU Sicherheitslücken auf der Hardware

TOCTOU-Schwachstellen (Time-of-Check to Time-of-Use) stellen eine erhebliche Bedrohung für eingebettete Systeme dar, insbesondere beim Umgang mit externem Flash-Speicher. Der Flash-Speicher dient als nichtflüchtiges Speichermedium für Firmware und ermöglicht die Speicherung von Code und Daten, selbst wenn das System ausgeschaltet ist. Die den TOCTOU-Schwachstellen innewohnende Zeitlücke birgt jedoch ein Risiko, das böswillige Akteure ausnutzen können.

Im Bereich des Flash-Speichers, wo die Firmware normalerweise in einem eingebetteten System gespeichert wird, beinhalten TOCTOU-Schwachstellen oft die Überprüfung einer Bedingung, wie z. B. die Firmware-Integrität, zu einem bestimmten Zeitpunkt und die anschließende Verwendung dieses Ergebnisses später während der Ausführung. Diese Zeitlücke bietet Angreifern die Möglichkeit, das System zu manipulieren, was zur unbefugten Codeausführung oder Datenmanipulation führt.

Beispielsweise könnte ein Angreifer den externen Flash-Speicher klonen, seinen Inhalt ändern und während der Ausführung eines kritischen Prozesses, wie z. B. Secure Boot, zum ursprünglichen Flash zurückkehren. Wenn das System die Integrität der Firmware erst zu Beginn des Startvorgangs überprüft, die Überprüfung während der Ausführung jedoch nicht erneut durchführt, öffnet es ein Fenster, in dem der Angreifer bösartigen Code eingeben kann.

Dieses Problem ist nicht auf eine bestimmte Plattform beschränkt und unterstreicht die umfassendere Herausforderung bei der Sicherung eingebetteter Systeme, bei denen externe nichtflüchtige Speicher eine zentrale Rolle für die Gesamtfunktionalität und Sicherheit des Geräts spielen.

Wie relevant ist es für XiP (eXecute in Place)? 

An Ort und Stelle ausführen (XiP), ein weit verbreiteter Ansatz, bei dem Code direkt aus dem Flash-Speicher ausgeführt wird, verstärkt die Auswirkungen von TOCTOU-Schwachstellen. Dies zeigt sich in der zeitlichen Lücke zwischen der Überprüfung von Bedingungen wie der Firmware-Integrität und der tatsächlichen Ausführung von Code während XiP.

Stellen Sie sich ein Szenario vor, in dem das System während des Startvorgangs eine erste Integritätsprüfung durchführt, danach aber weiterhin Code direkt aus dem Flash ausführt. In diesem Zusammenhang könnte ein Angreifer, der eine TOCTOU-Schwachstelle ausnutzt, den Flash-Inhalt nach der ersten Überprüfung auf subtile Weise manipulieren, was zur Laufzeit zur unautorisierten Codeausführung führt.

Die aktuelle Technik, Flash-Speicher zu emulieren, um TOCTOU-Schwachstellen zu untersuchen und zu beheben, führt jedoch zu einer gewissen Komplexität. Die Komplexität der Nachbildung des zeitlichen Verhaltens, der Zustandsfähigkeit und der protokollbasierten Merkmale von Flash-Speichern in einer Emulationsumgebung trägt zu den Herausforderungen bei, denen sich Forscher gegenübersehen. Diese Komplexität unterstreicht den Bedarf an fortschrittlichen Tools zur präzisen Emulierung von Flash-Speichern und zur Bewertung der Sicherheitsstabilität von Systemen, die XiP-Strategien verwenden, um den sich entwickelnden Bedrohungen im eingebetteten Bereich zu begegnen.

#Chip Wähle für den Sieg 

Zur Bekämpfung der Herausforderungen, die sich aus Time-of-Check to Time-of-Use (TOCTOU) -Schwachstellen in eingebetteten Systemen ergeben. Bei diesem Ansatz kommen zwei Flash-Speichermodule zum Einsatz, die die Embedded Chip Select (CS) -Reihe nutzen. Im Gegensatz zur komplexen Flash-Emulation ermöglicht diese Methode einen einfachen und dennoch robusten dynamischen Wechsel zwischen normaler und potenziell geänderter Firmware zur Laufzeit.

So funktioniert es: Zunächst arbeitet das System mit einem Flash-Speichermodul, das beim Booten validiert wird. Der clevere Einsatz der CS-Reihe ermöglicht jedoch einen reibungslosen Übergang zum zweiten Flash-Speichermodul zur Laufzeit. Dadurch wird die zeitliche Lücke zwischen Integritätsprüfungen und Ausführung ausgenutzt und ein dynamischer Wechsel ermöglicht, ohne dass eine komplizierte Emulation erforderlich ist.

Die Sicherheitslücke betrifft nicht nur die Chips, die auf XiP angewiesen sind, sondern auch Dateisysteme, die die Seiten auf Anfrage laden. Zum Beispiel ein intelligentes Gerät, das die Firmware von einem NAND-Flash lädt, um sie zu überprüfen, und das Linux/RTOS-Dateisystem dynamisch lädt. Dies kann theoretisch mit dieser Technik manipuliert werden, da NAND-Flash Chip Select unterstützt. Vielleicht ist es auch mit DRAM möglich? Ich überlasse es dem Leser, zu experimentieren

Umgehen Sie den sicheren Start in ESP32 mit X (R) iP 

Der ESP32 verwendet Execute-in-Place (XiP), eine wichtige Strategie, die sowohl die Leistung als auch die Sicherheit von Mikrocontroller-Anwendungen verbessert. XiP ermöglicht es dem ESP32, Code direkt aus einem externen Flash-Speicher auszuführen, sodass er nicht in den Arbeitsspeicher kopiert werden muss. Dies spart nicht nur RAM-Speicherplatz, sondern erleichtert auch die Handhabung größerer Firmware-Größen, ein wichtiger Aspekt bei eingebetteten Systemen mit eingeschränkten Ressourcen.

In der Architektur des ESP32-Speichers spielt die sorgfältige Zuweisung und Nutzung von IRAM, DROM und IROM eine zentrale Rolle: Instruction RAM (IRAM) befindet sich in der internen SRAM0-Region und ist für die Speicherung von Teilen der Anwendung vorgesehen, die eine schnelle Ausführung erfordern.

Andererseits ist Data Stored in Flash (DROM) ein Repository für konstante, schreibgeschützte Daten, die der Linker in einer Region platziert, die dem MMU-Flash-Cache zugeordnet ist. Dies dient als Referenzpunkt, der sich von dem ausführbaren Code unterscheidet, der sich in IROM befindet.

Code, der von Flash (IROM) ausgeführt wird, wird zum Standardspeicherort für Funktionen, die nicht explizit in IRAM platziert werden. IROM nutzt den Flash-MMU-Mechanismus und ermöglicht die direkte Codeausführung von Flash aus, was die betriebliche Effizienz erhöht. Dies optimiert die Ausführungsgeschwindigkeit und verwaltet die Speicherressourcen innerhalb des ESP32-Frameworks.

Die folgende Tabelle zeigt die Speicherzuordnung des externen Flash-Speichers für Daten und Anweisungen.

POC||GTFO 

Um des PoC willen esp-idf/beispiele/protocole/http_server/einfach Demo-Anwendung wird verwendet. Es ist ein einfacher Webserver, der eine Verbindung zum WLAN herstellt und den Text „Hallo Welt“ auf der Webseite ausdruckt.

Anfänglich wurde das System mit einer validierten Firmware im Flash-Speicher 1 mit sicherer Startfunktion konfiguriert. Dadurch wurde ein sicherer und validierter Startvorgang gewährleistet und die Integrität der Firmware während der Systeminitialisierung bestätigt.

Der Flash-Speicher 2 ist dieselbe Kopie des Flash-Speichers 1, wobei der gerenderte Text jedoch in „Hacko World“ statt in „Hello World“ geändert wird, wodurch die sichere Bootkette unterbrochen wird, da die Integrität ungültig wird. Dabei hat Secure Boot eine bewundernswerte Leistung erbracht, indem der Startversuch von Flash-Speicher 2 abgewiesen wurde.

Jetzt kann der ESP32 mit Flash-Speicher 1 booten und darf sich mit dem WLAN verbinden. Dann wurde ein Übergang von Flash-Speicher 1 zu Flash-Speicher 2 über die Chip Select-Leitung veranlasst, was eine erhebliche Anfälligkeit aufwies. Der ESP32 führte Inhalte aus dem modifizierten Flash-Speicher 2 aus, wodurch die Integrität des sicheren Startvorgangs beeinträchtigt wurde. Dieses Vorkommnis unterstreicht die inhärenten Risiken, die mit TIME-of-CHECK TO TIME-OF-USE (TOCTOU) -Schwachstellen einhergehen. Durch die Zeitlücke zwischen der ersten Überprüfung und der nachfolgenden Ausführung entsteht ein Fenster, das ausgenutzt werden kann.

Demo-Video

Im Video unten demonstrieren wir den Angriff, indem wir den Text ersetzen, der vom HTTP-Server zurückgegeben wird, der auf diesem ESP32-Ziel läuft.

Fazit

Die Sicherheitsanfälligkeit besteht sowohl in Secure Boot V1 als auch in V2. Diese Sicherheitsanfälligkeit wurde Espressif gemeldet, und sie haben die Sicherheitsanfälligkeit bestätigt. Ihr Vorschlag zur Abwehr bestand in der Verwendung von Flash-Verschlüsselung, wodurch dieses Problem bis zu einem gewissen Grad behoben wird, da die in ESP32 verwendete Flash-Verschlüsselung AES XTS ist und jede Seite ihren eigenen Verschlüsselungsschlüssel hat. Sie können die Binärdatei nicht patchen, ohne die Seitenbegrenzung zu durchbrechen. Unserer Meinung nach wird das Problem jedoch nicht vollständig entschärft, wenn der bösartige Flash zufällig Code ausführen könnte, der auf einem Textblock mit falscher Chiffre auf einer bestimmten Seite basiert, was als Sicherheitseinschränkung gedacht ist

Dies gilt auch für alle SoC/MCU-Anbieter, die die Execute-in-Place-Sicherheitslücke unterstützen und die die XIP-Verschlüsselung nicht unterstützen oder die Benutzer sie standardmäßig nicht aktivieren.

Forschung unterstützt von Gewissheit.

Bei ONEKEY bieten wir umfassende Dienstleistungen im Bereich Hardware-Penetrationstests die über typische Checklisten hinausgehen und innovative, forschungsbasierte Ansätze zur Suche nach Sicherheitslücken verwenden. Unser Expertenteam ist bestrebt, Sicherheitslücken in Ihren Hardwaresystemen aufzudecken und Ihnen umsetzbare Empfehlungen zur Verbesserung Ihrer Sicherheitslage zu geben. Wir verwenden die neuesten Tools und Techniken, um Schwachstellen in Ihrer Hardware zu identifizieren, und unser Team verfügt über jahrelange Erfahrung in diesem Bereich.

Warte nicht, bis es zu spät ist. Kontakt ONEKEY noch heute, um einen Hardware-Penetrationstest zu vereinbaren und die Sicherheit der Hardwaresysteme Ihres Unternehmens zu gewährleisten.