Schutzlos im Feld Warum Embedded Systems der Desktop-Sicherheit um Jahre hinterherhinken

Buffer Overflows gelten seit Jahrzehnten als verstanden – auf Desktop-Systemen sind sie durch Compiler-Flags und Betriebssystem-Mechanismen weitgehend entschärft. Doch auf Embedded Devices fehlen diese Schutzmaßnahmen oft vollständig. Mit dem Cyber Resilience Act wird die Exploit Mitigation zur regulatorischen Pflicht. Für Hersteller bedeutet das: Handeln, bevor es der Gesetzgeber erzwingt.

Embedded Systeme stecken in Industriesteuerungen, Medizingeräten, Routern und vernetzten Sensoren – und sie sind für Angreifer aus gleich mehreren Gründen attraktiv. Wer die Firmware eines Geräts analysieren kann, findet dort oft nicht nur ausnutzbare Schwachstellen, sondern auch hartcodierte Schlüssel, proprietäre Algorithmen oder Lizenzprüfungen, die sich umgehen lassen. Ein kompromittiertes Embedded Device kann darüber hinaus als Brückenkopf ins übergeordnete Netzwerk dienen.

Verschärfend kommt hinzu, dass die Sicherheitslandschaft in der Embedded-Welt fragmentiert ist. Hersteller investieren typischerweise in Netzwerksicherheit, Hardware-Security, Kryptografie oder physische Zugangskontrollen – die Absicherung der Binärdatei selbst wird dabei häufig übersehen. Genau diese Schicht hat jedoch das Potenzial, alle anderen Schutzmaßnahmen zu unterlaufen. Wer den Binärcode lesen und manipulieren kann, findet Wege an sämtlichen vorgelagerten Verteidigungslinien vorbei.

Exploit Mitigations: Auf Desktops Standard, auf dem Mikrocontroller Fehlanzeige

Die Geschichte der Exploit Mitigations zeigt ein verräterisches Gefälle. Auf Desktop- und Serversystemen unter Linux, Windows oder macOS gehören Maßnahmen wie Stack Canaries, Address Space Layout Randomization (ASLR), No-Execute-Flags (NX/DEP) und Read-Only Relocations (RELRO) längst zum Standardrepertoire. Compiler und Betriebssysteme aktivieren sie in der Regel automatisch. Wer heute einen Desktop-Exploit schreiben will, muss diese Mechanismen zunächst umgehen, was den Aufwand erheblich erhöht.

In der Welt der Deeply Embedded Systems – also auf Bare-Metal- und RTOS-basierten Plattformen – sieht das anders aus. Eine 2019 auf dem IEEE European Symposium on Security and Privacy veröffentlichte Studie untersuchte die gängigsten eingebetteten Betriebssysteme auf ihre Exploit-Mitigation-Fähigkeiten. Das Ergebnis war ernüchternd: Die überwiegende Mehrheit der untersuchten Systeme – von Cisco IOS über freeRTOS bis TI-RTOS – unterstützte weder ASLR noch Stack Canaries. Selbst die grundlegende No-Execute-Policy war nur bei einer Handvoll Systeme aktiv.

Dass diese Lücke keine theoretische Schwäche ist, zeigen aktuelle Praxisbeispiele. Im Februar 2025 dokumentierte das Sicherheitsteam Doyensec einen Stack-based Buffer Overflow im Tenda AC15 Router (CVE-2024-2850). Die Analyse der Binärdatei mit dem Werkzeug checksec förderte zutage, was in der Embedded-Welt erschreckend häufig vorkommt: kein RELRO, keine Stack Canaries, kein PIE. Lediglich das NX-Bit war gesetzt. Die Forscher notierten trocken, dass mangels aktiver Schutzmaßnahmen keinerlei Einschränkungen bei der Wahl der Exploit-Technik bestanden. Ein ähnliches Bild zeigte sich 2023 bei der Wyze Cam v3, wo ein Buffer Overflow in der JSON-Verarbeitung direkt zu Remote Code Execution führte – ebenfalls ohne Stack Canaries oder PIE.

Perspektive aus der Praxis – Wenn Schutzmaßnahmen fehlen, wird es trivial

Wie sich diese Schutzlücken in der Praxis eines Angreifers auswirken, beschreibt Dr. Tobias Scharnowski aus erster Hand. Er ist Sicherheitsforscher und Gründer von Fuzzware, einem auf die Schwachstellensuche in eingebetteten Systemen mittels Fuzz Testing spezialisierten Startup, und hat bei Pwn2Own mehrfach Embedded Devices erfolgreich kompromittiert.

„Wenn ich die Firmware eines IoT-Geräts in Ghidra lade, finde ich vor allem im Bereich der Deeply Embedded Systems regelmäßig keinerlei aktive Schutzmaßnahmen vor. Aktive Exploit Mitigations erschweren die Ausnutzung von Sicherheitslücken erheblich und führen häufig dazu, dass ein Angreifer eine Kombination zweier Schwachstellen ausnutzen muss, um überhaupt zu einem vollen Exploit zu gelangen. Würden Hersteller solche Mechanismen flächendeckend einsetzen, müsste ein Angreifer deutlich mehr Zeit in die Ausnutzung stecken und unter Umständen mehrere Sicherheitslücken finden, bis ein erfolgreicher Exploit gelingt.”, so Dr. Scharnowski.

Warum ist die Umsetzung so schwierig?

Die Gründe für das Schutzdefizit sind vielschichtig und haben weniger mit Nachlässigkeit als mit strukturellen Hürden zu tun. Auf Desktop-Systemen sind Exploit Mitigations in der Regel durch das Zusammenspiel von Compiler, Betriebssystem und Hardware abgesichert und standardmäßig aktiv. Auf Deeply Embedded Plattformen fehlt dieses Zusammenspiel an fast jeder Stelle.

Viele eingebettete Betriebssysteme sind von Grund auf unsicher konfiguriert. Die Dokumentation zu sicherheitsrelevanten Compiler-Flags ist lückenhaft oder gar irreführend. Entwicklungswerkzeuge und Toolchains sind häufig veraltet und bieten keinerlei Unterstützung für gängige Schutzmaßnahmen. Selbst grundlegende Mechanismen wie Stack Canaries setzen eine Standardbibliothek voraus, die auf Bare-Metal-Systemen oft nicht verfügbar ist. Modernere Schutzkonzepte wie Control Flow Integrity (CFI) sind für viele Embedded-Targets schlicht nicht implementiert. Hinzu kommt, dass die benötigte Hardwareunterstützung – etwa eine Memory Protection Unit mit ausreichender Granularität – auf vielen Mikrocontrollern fehlt oder stark eingeschränkt ist.

Der Cyber Resilience Act macht Exploit Mitigation zur Pflicht

Was bisher eine Frage der Best Practice war, wird mit dem EU Cyber Resilience Act (CRA) zur regulatorischen Anforderung. Artikel 13 Absatz 2 Buchstabe k verlangt, dass Produkte mit digitalen Elementen so konzipiert, entwickelt und hergestellt werden, dass sie die Auswirkungen eines Sicherheitsvorfalls durch geeignete Exploit-Mitigation-Mechanismen und -Techniken reduzieren. Für Hersteller von Embedded Devices bedeutet das konkret: Die bloße Existenz eines Bugs darf nicht mehr automatisch zu einer ausnutzbaren Schwachstelle führen. Schutzmechanismen müssen eingebaut sein, die den Weg vom Fehler zum erfolgreichen Angriff erschweren.

Angesichts der oben beschriebenen strukturellen Hindernisse stellt sich die Frage, wie Hersteller diese Anforderung in der Praxis umsetzen sollen – insbesondere für bereits im Feld befindliche Geräte oder für Plattformen, deren Toolchain keine eingebaute Unterstützung bietet.

Firmware-Extraktion und Reverse Engineering: Der Weg zum Angriff

Die typische Angriffskette gegen ein Embedded Device verläuft in zwei Phasen. In der ersten Phase verschafft sich der Angreifer Zugang zur Firmware. Die Wege dorthin sind vielfältig. Firmware-Dateien stehen häufig unverschlüsselt auf Hersteller-Webseiten zum Download bereit, lassen sich aus Over-the-Air-Updates abfangen oder werden als kompilierte Bibliotheken direkt an Kunden ausgeliefert. Wo das nicht möglich ist, bieten spezialisierte Dienstleister den physischen Readout von Mikrocontrollern an – ein florierender Markt, der Schwachstellen in Fuse-Bits, Bootloader-Glitches oder – wenn Geld keine Rolle spielt – sogar Circuit Editing nutzt.

In der zweiten Phase kommt Software Reverse Engineering zum Einsatz. Werkzeuge wie Ghidra, IDA Pro oder Binary Ninja übersetzen den Binärcode zunächst in Assembler-Anweisungen (Disassembly) und anschließend in eine Pseudo-C-Darstellung (Dekompilierung). Selbst ohne Zugang zum originalen Quellcode lässt sich so die Logik der Software rekonstruieren; einschließlich kryptografischer Schlüssel, die im Klartext in der Binärdatei liegen, oder sicherheitsrelevanter Funktionen, deren Verwundbarkeit im dekompilierten Code offen zutage tritt.

Software Hardening auf Binärebene – Schutz ohne Toolchain-Umbau

Ein vielversprechender Ansatz, um das Schutzdefizit auf Embedded Plattformen zu adressieren, ist das sogenannte Binary Rewriting. In der Praxis stehen Hersteller häufig vor der Situation, dass sich etliche Geräte seit Jahren im Feld befinden und an Toolchains oder Quellcode in dieser Zeit nicht mehr gearbeitet wurde. Exploit Mitigations auf konventionellem Weg nachzurüsten, ist hier ohne gravierenden Aufwand kaum noch möglich, in vielen Fällen existiert der originale Quellcode schlicht nicht mehr. Genau hier setzt Binary Rewriting an. Sicherheitsmechanismen werden nachträglich auf die bereits kompilierte Binärdatei angewendet, ein Eingriff in Quellcode oder Build-System ist nicht erforderlich.

Per Binary Rewriting lässt sich grundsätzlich eine Vielzahl unterschiedlicher

Schutzmaßnahmen einfügen. emproof hat den Fokus auf zwei Bereiche gelegt, die in der Praxis besonders wirksam sind. Auf der Seite der Exploit Mitigation lassen sich Stack Canaries, Control Flow Integrity und weitere Mechanismen nachrüsten, die auf dem ursprünglichen Target nicht verfügbar waren. Auf der Seite des Reverse-Engineering-Schutzes erhöhen Code-Obfuscation, Daten-Encoding, Anti-Debug-Maßnahmen und Anti-Tamper-Checks den Aufwand für die Analyse der Firmware erheblich. Zusammen bilden diese Maßnahmen eine mehrschichtige Verteidigung, die sowohl den Weg zum Exploit als auch den Diebstahl geistigen Eigentums erschwert.

Einen solchen Binary-Rewriting-Ansatz verfolgt beispielsweise das Bochumer Startup emproof, dessen Werkzeug Nyx aus der Forschung an der Ruhr-Universität und dem Max-Planck-Institut für Sicherheit und Privatsphäre hervorgegangen ist. Nyx setzt nach dem Kompilieren an und rüstet sowohl Exploit Mitigations als auch Reverse-Engineering-Schutz direkt auf der Firmware nach – ohne Eingriff in Quellcode oder Toolchain. Für Hersteller, deren Entwicklungsumgebung keine eigene Unterstützung für diese Schutzmaßnahmen bietet, entfällt damit eine der größten praktischen Hürden auf dem Weg zur CRA-Konformität.

Wer jetzt nicht handelt, handelt zu spät

Die Diskrepanz zwischen Desktop- und Embedded-Sicherheit ist kein Geheimnis – aber sie wird mit der zunehmenden Vernetzung und den Anforderungen des CRA zu einem akuten Problem. Hersteller, die ihre Geräte ohne Exploit Mitigations auf den Markt bringen, setzen nicht nur ihre Kunden einem vermeidbaren Risiko aus, sondern bewegen sich auf einen regulatorischen Konflikt zu. Die Technologie, um Embedded-Firmware wirksam zu schützen, existiert. Wer sie einsetzt, gewinnt damit Sicherheit und sichert sich zusätzlich einen Vorsprung bei der CRA-Konformität.  (sg)

* Dr.-Ing. Nils Albartus ist Chief Product Officer bei der emproof GmbH in Bochum. Er hat an der Ruhr-Universität Bochum und dem Max-Planck-Institut für Sicherheit und Privatsphäre zu Hardware Reverse Engineering, Hardware-Trojanern und Hardware-Schutzmaßnahmen promoviert und referiert zu diesem Themenfeld auf diversen Fachkonferenzen.

(ID:50873133)