Zum Verständnis der Anwendbarkeit von Runtime Moving Target Defense für das Internet der Dinge und cyber‑physikalische Systeme

Warum winzige Computer große Abwehr brauchen

Von intelligenten Thermostaten bis zu Industrierobotern hängt das tägliche Leben inzwischen von kleinen vernetzten Geräten ab, die still und heimlich messen, steuern und automatisieren. Dieselben Geräte können jedoch von Angreifern übernommen werden, die seit langem bekannte Softwarelücken ausnutzen, um Kontrolle zu erlangen. Dieses Paper untersucht, ob ein mächtiger Sicherheitstrick, genannt Moving Target Defense, auf der bescheidenen Hardware funktioniert, die die meisten Internet‑of‑Things‑(IoT‑) und cyber‑physikalischen Systeme (CPS) antreibt — und welche Konsequenzen das für die Sicherheit unserer zunehmend automatisierten Welt hat.

Ein sich bewegendes Ziel für Hacker

Traditionelle Sicherheitswerkzeuge wie Firewalls oder Antivirus reagieren meist erst, nachdem ein Angriff begonnen hat. Moving Target Defense verfolgt einen anderen Ansatz: Sie verändert ständig zentrale Teile eines Systems, sodass Angreifer nie sicher wissen, wo sie ansetzen sollen. Die hier untersuchte Technik ist Address Space Layout Randomization (ASLR), die bei jedem Start die Lage von Programmen und Bibliotheken im Speicher durcheinanderwirbelt. So können Angreifer, selbst wenn sie eine Schwachstelle kennen, die genaue Adresse nicht mehr leicht wiederfinden. ASLR ist auf großen Betriebssystemen mittlerweile Standard, doch sein Verhalten auf kleinen, ressourcenbeschränkten Geräten — wie sie in IoT und CPS üblich sind — war bisher wenig untersucht.

Drei Systeme im Test

Die Autorinnen und Autoren vergleichen, wie gut ASLR auf drei Linux‑basierten Setups funktioniert: ein 64‑bit Kali‑Linux auf einem typischen Intel‑Prozessor und zwei 32‑bit‑ARM‑Systeme mit Raspberry Pi OS und OpenWRT, die näher an Edge‑Geräten, Routern und Gateways liegen. Statt blind einzubrechen, wählen sie eine wissenschaftliche Perspektive: Sie protokollieren wiederholt, wo eine gängige Systembibliothek (libc) im Speicher landet und bauen große Datensätze realer Adressen auf. Anschließend analysieren sie, wie weit diese Adressen streuen, wie sich einzelne Bytes einer Adresse von Lauf zu Lauf ändern und wie unvorhersehbar das Gesamtmuster mittels einer Maßzahl namens Entropie ist. So lässt sich quantifizieren, wie schwer es für einen Angreifer wäre, die richtige Adresse zu erraten.

Wie zufällig ist "zufällig genug"?

Die Ergebnisse zeigen einen deutlichen Unterschied zwischen dem großen 64‑bit‑System und den 32‑bit‑Geräten. Auf dem 64‑bit‑Kali‑Linux sind die Adressen nahezu gleichmäßig über einen großen Bereich verteilt: die meisten Bytes der Adresse ändern sich stark, sehr wenige Orte wiederholen sich, und ein statistischer Test bestätigt, dass die Verteilung nahe an echter Zufälligkeit liegt. Für einen Angreifer bedeutet das einen enormen Suchraum und kaum Aussicht, die richtige Stelle schnell zu erraten. Auf den 32‑bit‑Systemen dagegen erscheinen in der Praxis nur eine kleine Menge von 256 unterscheidbaren Adressen, selbst bei 100.000 Stichproben. Mehrere Bytes ändern sich kaum, was größtenteils architekturbedingten Einschränkungen und der Ausrichtung von Speicherseiten geschuldet ist. Praktisch heißt das, dass ein Angreifer unter Umständen nur einige hundert Versuche — nicht Millionen oder Milliarden — benötigt, um die richtige Adresse zu treffen.

Praxisangriff und geringe Kosten

Um zu prüfen, ob diese Unterschiede praktisch relevant sind, implementieren die Forschenden eine Form der Kontrollübernahme namens Return‑Oriented Programming (ROP) auf allen drei Systemen. Wenn eine wichtige Härtungsoption namens Position Independent Executable (PIE) deaktiviert ist, gelingt der Angriff: Der normale Programmablauf wird auf vom Angreifer ausgewählte, versteckte Funktionen umgelenkt. Sobald PIE jedoch aktiviert ist und zusammen mit ASLR auch die Position des Hauptprogramms variabel macht, stürzt der Angriff zuverlässig ab, statt die Kontrolle zu übernehmen — sowohl auf der leistungsstarken 64‑bit‑Maschine als auch auf den bescheidenen 32‑bit‑ARM‑Geräten. Messungen zeigen außerdem, dass das Aktivieren von ASLR, Stack‑Schutzmechanismen und nicht ausführbarem Speicher nur einen kleinen Mehraufwand beim Speicherverbrauch und der Ausführungszeit verursacht, in der Größenordnung von etwa einem Prozent.

Was das für Alltagsgeräte bedeutet

Die Studie kommt zu dem Schluss, dass ASLR auf 32‑bit‑ARM‑Systemen zwar mathematisch schwächer und weniger zufällig ist als auf 64‑bit‑Desktops und Servern, dennoch Schutz in ähnlicher Größenordnung wie bei älteren 32‑bit‑PCs bietet und einfache Angriffe in Kombination mit anderen integrierten Abwehrmechanismen erfolgreich verhindern kann. Für sehr kleine IoT‑Sensoren ist ASLR oft nicht möglich, weil die Hardware die notwendigen Speicherfunktionen nicht bietet; dort sind andere Maßnahmen wie Secure Boot und leichte Verschlüsselung besser geeignet. Für Edge‑Geräte wie Router und Raspberry‑Pi‑ähnliche Boards ist das Aktivieren von ASLR, PIE und ähnlichen Schutzmaßnahmen jedoch sowohl praktikabel als auch lohnend. Die Umstellung dieser Plattformen auf 64‑bit‑Architekturen und die Kombination von ASLR mit weiteren Moving‑Target‑Techniken auf Netzwerk‑ und Softwareebene können die Hürde für Angreifer, die alltägliche Gegenstände missbrauchen wollen, deutlich erhöhen.

Zitation: Gurung, D., Pradhan, M.P. & Gurung, S. Towards understanding the applicability of runtime moving target defense for the internet of things and cyber physical systems. Sci Rep 16, 5907 (2026). https://doi.org/10.1038/s41598-026-36797-4

Schlüsselwörter: Moving Target Defense, ASLR, Sicherheit im Internet der Dinge, cyber‑physikalische Systeme, Buffer‑Overflow‑Angriffe