Hallo zusammen, ich beschäftige mich zur Zeit mit code injection attacks im context von Mikrocontrollern. (z.B klassische memory boundary attacks wie Stack-based Buffer Overflow aber auch im weiteren Sinne wie SQL Injection auf der Web Oberfläche von IoT Geräten). Ich würde gerne eine Übersicht verschaffen von Angriffen, die Firmware Code injection erlauben, um ein Framework zu haben, um die Robustheit von "Detection and Recovery" -Mechanismen zu testen. Ich finde viel Info zu Fault-Injection und Side-Channel Attacks aber wenig zu code injection und wollte fragen ob ihr dazu gute Ressourcen (z.B. Bücher, Paper oder einfach gute Suchbegriffe) damit ich da mein Wissen vertiefen kann. Vielen Dank!
Andrew schrieb: > wie SQL Injection auf der Web Oberfläche von IoT Geräten Mir fällt spontan kein IoT Gerät ein welche mit einem SQL Server für eine mögliche injection daherkommt. Da IoT Geräte meist sehr rudimentär aufgebaut sind. Würde ich daher bei der Codeinjection viel eher z.b. bei der Injection anfangen wenn man das WLan über eine Weboberfläche konfiguriert. Da dies meist als String im rom gespeichert wird, könnte man ansetzen.
Bei dem hiesigen IoT Gerät würde ich mir als erstes über die absichtlich eingebaute Hintertür Gedanken machen, dann veraltete Pakete, dann elektrische Gefahren.
Andrew schrieb: > ich beschäftige mich zur Zeit mit code injection attacks im context von > Mikrocontrollern Dann informiere dich über die Harvard Architektur mit (Flash)ROM im Code und RAM im Datenbereich. rPi mit Linux sind KEINE Microcontroller mehr. Mikrocontroller mit over-the-air update der Firmware kann man mit allem flashen wenn man den Mechanismus kennt.
Kommt schon mal sehr auf die Architektur an. Wenn du irgendwie an einen Bootloader-Code rankommst, oder ein JTAG-Interface funktioniert, hast du einen Einstiegspunkt, kannst rauskriegen, was fuer Libraries verwendet werden, den Code reversen, usw. Wenn sich die Hinweise verdichten, dass die standard C lib mit im Spiel ist, ist der erste Versuch dein genannter Buffer-Overflow. Google mal nach Fuzzing. Hast du mal das Wissen, was passiert, ist der Rest das entsprechende Daten I/O. Das kann man natuerlich auch "black box" machen, aber fuer ne gezielte Attacke reichts meistens nicht. Viel dazu finden wirst du vermutlich ausser Code und generischem Halbwissen nicht, die Leute die sich mit Sicherheitsanalysen beauftragen lassen, unterschreiben meist einen NDA. Und zudem darf man den §202c nicht vergessen, der Publikationen erschwert.
Hängt halt alles stark vom Device ab: - Ständige Verbindung zu einer Cloud außerhalb deiner Kontrolle? -> Sowieso unsicher. Weitere Betrachtung kann man sich eigentlich sparen. - µC mit Harvard-Architektur: "Code Injection" als solches gibt es nicht. Aber u.U. lässt sich über geschickte Manipulation des Stacks was erreichen, wenn die Return-Adressen plötzlich an gut gewählte Stellen in der Firmware springen. - Geräte mit Weboberfläche: Hier ist ein ganzer Zoo an Webbasierten Angriffen möglich, z.B. wenn die Oberfläche nicht gegen CSRF gesichert ist. Beispiel: ich schalte eine Werbeanzeige, verknüpfe die mit passenden Keywords, und in die Werbeanzeige pack ich jede Menge `<img src="http://192.168.177.x/?cmd=OFF">` Wenn das Gerät garkeinen Login vorsieht, klappt das sofort. Wenn das Gerät einen Session/Cookie-Basierten Login hat, und du zufällig vorher auf dem Gerät eingeloggt warst, auch. - Geräte mit Linux: Da kommen oft Uralte Versionen mit Bergen an bekannten, veröffentlichten Sicherheitslücken zum Einsatz. ...
Chipkarten wurden / werden zum Beispiel mit Glitching - Angriffen attakiert. Dabei werden zu bestimmten Zeitpunkten durch Spannungsspitzen und oder Spannungseinbrüche durch die Änderung des Befehlszählers Befehle des Prozessors übersprungen. Außerdem werden durch Messen der Stromaufnahme bestimmte Programmabschnitte detektiert, so das man bei glechzeitiger Überwachung des Prozessor- taktes sich im ROM "umsehen" kann. Das erfordert dann natürlich schnelle eigenkonstruierte Überwachungshardware mit schnellen Analog-Digitalwandlern u.s.w. mfg
Für Code Injection muss das Gerät irgendwelche Daten bekommen, in denen Code steht, der dann falsch interpretiert und versehentlich ausgeführt wird. Also: 1. Daten bekommen 2. "falsch" auswerten/validieren 3. ausführen Der Klassiker Buffer Overflow hat fehlende Längenprüfung (2) und die geschriebenen Daten werden dann vom Prozessor ausgeführt (3). Braucht natürlich eine Von-Neumann-Architektur. Klassische SQL-Injection ist eine Webanfrage (1), in der Daten stehen, die in eine DB sollen. Die Daten werden vom Programm unzureichend überprüft, so dass SQL-Escape-Codes unbemerkt bleiben (2). Der SQL-Server führt das dann aus (3). Shell-Injection bzw. OS-Command Injection geht ähnlich (1). Fehlerhaft kann der Webserver (CGI) oder das Programm sein (2), Ausführung dann durch die Shell (3). Es kommt in allen Stufen sehr drauf an, wie komplex die Geräte sind. Es braucht auf jeden Fall eine Schnittstelle, über die das Gerät Daten bekommt (1). Das kann z.B. eine Netzwerkschnittstelle oder eine serielle Schnittstelle sein. Das kann aber auch ein Datenspeicher sein, aus dem irgendwas gelesen werden soll, z.B. eine Konfig-Datei auf einem Dateisystem. Oder ein binärer Konfig-Struct im EEprom/Flash. Wenn ein Gerät hunderttausend Features hat, zahlreiche Protokolle unterstützt oder weitreichend anpassbar ist, dann werden sich mehr solche Vektoren finden, als bei einem einfachen Gerät. Jetzt braucht es die fehlerhafte Auswertung/Überprüfung (2). Parser sind notorisch unsicher implementiert. Ein Grund dafür ist, dass oft nur nach bestimmten Zeichen gesucht wird und nicht alle Fehlermöglichkeiten abgefangen werden. Um einen "richtigen" Parser (wie lex&yacc) zu bauen, fehlt oft der Speicher, aber auch die Zeit und Sachkenntnis. Sind die Daten komplex, kommt oft eine fertige Bibliothek zum Einsatz. Z.B. der Netzwerk- oder USB-Stack, auf Applikationsebene z.B. ein XML-Parser. Aufgrund der Verbreitung sind da Fehler seltener bzw. hoffentlich schon behoben. Problematischer sehe ich Erweiterungsfeatures, die man nicht kennt oder an die man nicht denkt. Beispielsweise XXE. Oder die log4j-Schwachstelle vor ein paar Jahren, die erstaunlich viele Geräte betroffen hat, wo man kein Java erwartet hätte. Zum Schluss die Ausführungsumgebung (3). Bei einem Bare-Metal-System geht nur Maschinencode. Vorteilhaft für den Angreifer ist, dass Embedded-Systeme i.d. Regel weder ASLR noch NX-Bits haben. Gibt es einen eingebauten Interpreter oder eine Scriptsprache, kann ich mir mehr Angriffsmöglichkeiten vorstellen. Ehrlicherweise weiß ich aber nicht, ob es z.B. bei uPython oder Lua schon entsprechende Probleme gab. Embedded heißt aber nicht immer Bare-Metal. Viele Mikrokontroller werden mit einem kleinen (Echtzeit-) OS benutzt. Je nachdem, wo du die Grenze zu embedded ziehen willst kann aber auch ein Linux dabei sein. Ich weiß, dass ich dir damit nicht unmittelbar helfen konnte. Ich hoffe aber, dass die Systematisierung dir hilft, die Suche ein bisschen einzugrenzen. Generell: der Embedded-Bereich ist vielseitig. Wilde/unerwartete Konstruktionen wird man hier häufiger sehen als z.B. bei Webentwicklern. Ich hatte neulich den Fall, da hat jemand eine Cortex-M0-Virtualisierung gebaut, die dann auf einem M4 lief. Da war Code-Injection quasi Entwicklungsziel.
Achja: Andrew meinte: > Ich finde viel Info > zu Fault-Injection und Side-Channel Attacks aber wenig zu code injection > und wollte fragen ob ihr dazu gute Ressourcen (z.B. Bücher, Paper oder > einfach gute Suchbegriffe) damit ich da mein Wissen vertiefen kann. > Vielen Dank! Wer ist Stacey Faithful? mfg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.