SIM-Karten als Angriffsfläche: Forscher zeigen Codeausführung auf IoT-Modems über Standardfunktion
Dennis Knake
Veröffentlicht am 17. August 2026
Eine SIM-Karte darf dem Gerät, in dem sie steckt, Befehle erteilen, so steht es in den Mobilfunk-Spezifikationen. Forscher der University of Birmingham haben untersucht, was passiert, wenn diese Karte feindlich ist: Sechs von acht getesteten IoT-Modulen ließen sich über diesen Weg ansteuern, bei den Smartphones waren es drei von 18.
- Forscher der University of Birmingham und der Sicherheitsfirma Fuzzware haben auf der USENIX-Konferenz WOOT 2026 in Baltimore gezeigt, dass die standardisierte Proactive-SIM-Funktion einer SIM-Karte erlaubt, über den Befehl RUN AT beliebige AT-Befehle im Modem eines Geräts auszuführen.
- Von 26 untersuchten Geräten öffneten neun diese SIM-AT-Schnittstelle: sechs der acht getesteten IoT-Module und drei der 18 Smartphones; demonstrierte Angriffe reichen von Codeausführung auf einer Wallbox und Dateidiebstahl über einen erzwungenen 2G-Downgrade bis zum Abschalten des Geräts.
- Qualcomm liefert inzwischen eine gehärtete Standardkonfiguration, die die Schnittstelle abschaltet, Quectel hat die SIM-AT-Schnittstelle entfernt, und die GSM Association führt den Fall unter CVD-2026-0122.
Was ist die Proactive-SIM-Funktion und was macht RUN AT?
Eine SIM-Karte ist kein passiver Speicherchip, sondern ein kleiner Computer. Normalerweise fragt der Kommunikationsprozessor des Modems die Karte ab. Die Spezifikationen sehen aber unter dem Namen „Proactive SIM“ auch den umgekehrten Weg vor: Die Karte darf dem Gerät eine begrenzte Anzahl von Befehlen erteilen. Einer davon, RUN AT, fordert das Gerät auf, einen bestimmten AT-Befehl auszuführen – also einen Steuerbefehl aus jenem Kommandosatz, der seit dem Hayes-Smartmodem von 1981 Modems konfiguriert.
Faktisch entsteht damit eine Befehlsschnittstelle von der Karte ins Gerät. Ein Team um Tomasz Piotr Lisowski und Dr. Marius Muench von der University of Birmingham entwickelte gemeinsam mit Kristian Covic von der Sicherheitsfirma Fuzzware das Werkzeugpaket CATana, um diese Schnittstelle systematisch abzuklopfen. Es besteht aus vier Komponenten: einer interaktiven Kommandozeile, einem SIM-Applet, einem Automatisierungsmodul für Massentests und einem Auswerter.
Die Ergebnisse stellte das Team am 10. August 2026 auf der USENIX-Konferenz WOOT in Baltimore vor; das Paper ist frei zugänglich, der Quellcode liegt als Forschungsartefakt auf Zenodo. Fertige Angriffs-Applets veröffentlichten die Autoren bewusst nicht. Muench betont, dass es sich nicht um einen Bruch mit dem Standard handelt, sondern um dessen konsequente Ausnutzung. Die proaktiven Fähigkeiten einer SIM und die daraus folgende Angriffsfläche seien „explizit in den technischen Spezifikationen für Mobilfunkkommunikation definiert“, sagt er in der Mitteilung der University of Birmingham (Übersetzung aus dem Englischen). Die Angriffe folgen damit der Spezifikation, statt sie zu verletzen.
Welche Geräte öffnen die SIM-AT-Schnittstelle?
Das Team untersuchte 26 Geräte: 18 Smartphones von zehn Herstellern und acht cellulare IoT-Module von vier Herstellern. Neun Geräte gaben der SIM eine AT-Befehlsschnittstelle. Bei den Modulen sind es sechs von acht. Getestet wurden unter anderem ein Modul aus einer Wallbox, eines aus einem Industrierouter und eines aus einer Telematikeinheit eines Autos. Nur das Entwicklungsboard Nordic nRF9160-DK und das Simcom SIM800C unterstützten RUN AT nicht.
Auf der Smartphone-Seite sind es drei von 18: OPPO Find X5, OPPO Reno14 F 5G und Asus Zenfone 9. Zwei davon stammen vom selben Hersteller, alle drei nutzen einen Qualcomm-Kommunikationsprozessor. Andere Hersteller verbauen denselben Prozessor, ohne die Funktion anzubieten – die Forscher schließen daraus, dass sie bei der Gerätepersonalisierung bewusst hinzugefügt wird.
Die getesteten Geräte von Apple und Google meldeten keine Unterstützung. Entwarnung ist das nur bedingt. Bei der Analyse zweier Samsung-Exynos-Basisbänder fand das Team, dass der Parser den Befehl RUN AT lediglich auf eine Sperrliste setzt. Der Code zum Verarbeiten und Weiterreichen des Befehls liegt weiterhin in der Firmware und wäre über einen Kontrollfluss-Angriff erreichbar.
Was konnten die Forscher konkret demonstrieren?
Aus den Befunden ergaben sich vier Schwachstellen, illustriert an drei Fallstudien.
Codeausführung auf einer Wallbox
Untersucht wurde eine Ladestation vom Typ AUTEL Maxi US AC W12-L-4G, in der ein Quectel-EC25AFXDGA-Modul steckt. Das Programm atfwd_daemon im Modul nimmt AT-Befehle entgegen, auch von der SIM-Schnittstelle, und setzt einige davon zu Shell-Aufrufen zusammen. An zwei Stellen fanden die Forscher eine unsichere Formatzeichenkette, über die sich eigener Text in den Shell-Befehl schmuggeln lässt. Eine Zeichensperre sollte das verhindern, ließ sich aber mit einem Zeilenumbruch umgehen. In zwei Stufen erreichte das Team so Codeausführung, ausgelöst allein durch Befehle von der Karte.
Abschalten und 2G-Rückfall beim Smartphone
Auf dem OPPO Reno 14 F 5G fand CATana 198 über die SIM erreichbare AT-Befehle und Varianten. Drei davon reichten für die Demonstration: einer fährt das Telefon herunter, einer schaltet den Kommunikationsprozessor ab, einer beschränkt das Gerät auf 2G-Netze. Diesen Rückfall bekam der Nutzer nicht zurückgesetzt – weder über den Flugmodus noch über manuelle Netzwahl, das Abschalten der Mobilfunkdaten, das Deaktivieren der SIM oder die Einstellung der bevorzugten Netzgeneration.
Dateidiebstahl über ein Modem
Bei Quectel-Modulen liegt das Dateisystem nicht im Kommunikationsprozessor, sondern beim internen Anwendungsprozessor, angebunden über das Protokoll TFTP. Dessen Dienst prüft nicht, ob ein Pfad ein symbolischer Link ist. Am Modul EG25-G kombinierte das Team einen zuvor platzierten Link mit SIM-Befehlen und ließ sich die verlinkte Datei über die modemeigenen SMTP-Befehle an einen eigenen Server mailen. Der Angriff hat eine Vorbedingung: Den Link muss ein Angreifer erst ins Dateisystem bringen, etwa über eine präparierte SD-Karte oder durch Flashen einer manipulierten Partition.
Warum trifft es IoT-Geräte härter als Smartphones?
Der Grund liegt in der Bauweise der Module. Fast alle untersuchten Module betreiben neben dem Funkteil einen zweiten, stärkeren Prozessor. Bei allen getesteten Quectel-Modulen läuft darauf ein Android auf einem ARM-Cortex-A7-Kern – auch dann, wenn der Hauptprozessor des umgebenden Geräts schwächer ist. Der Funkteil beantwortet die wenigsten AT-Befehle selbst und reicht den Rest an diesen internen Rechner weiter. Die Karte redet damit, wie das Paper formuliert, mit einer „reichen Angriffsfläche für feindliche SIMs“. Hinzu kommt: Gerade weil IoT-Geräte üblicherweise abgeriegelt sind und nur wenige Schnittstellen anbieten, wiegt eine übersehene schwer. Und der Schaden endet nicht im Modul. Bei einem der untersuchten Geräte fanden die Forscher in der Firmware des Hauptprozessors einen Speicherfehler, der sich auslösen lässt, wenn das Modul eine fehlerhafte IP-Adresse liefert. Ein übernommenes Modul wird so zum Sprungbrett ins Gesamtsystem.
Wie realistisch ist eine feindliche SIM-Karte?
Der Einwand liegt nahe: Wer die SIM kontrolliert, hat ohnehin schon viel gewonnen. Das Team übernimmt deshalb ein Bedrohungsmodell aus früherer Arbeit mit vier Quellen für feindliche Karten – und belegt jede mit einem realen Präzedenzfall.
- Erstens Schwachstellen in der SIM-Software, wie sie die SIMJacker-Angriffe ausnutzten.
- Zweitens physischer Zugriff, um die Karte zu tauschen oder einen Zwischenstecker einzubauen; der ANT-Katalog der NSA führt SIMs als Angriffsvektor.
- Drittens die Fernverwaltung von SIMs durch böswillige oder kompromittierte Betreiber – bei einem beobachteten Datenabfluss bei einem Betreiber waren SIM-Authentifizierungsgeheimnisse betroffen.
- Viertens Manipulationen in der Lieferkette zwischen Fertigung und Auslieferung.
Da eSIMs technisch denselben Weg gehen, betrifft besonders der dritte Punkt IoT-Flotten mit Fernbereitstellung. Neben den RUN-AT-Befunden stießen die Forscher auf eine weitere Schwäche: Auf aktuellen Android-Versionen kann eine feindliche Karte über den Befehl LAUNCH BROWSER das Telefon dazu bringen, ohne jede Nutzerinteraktion eine vom Angreifer gewählte Website zu öffnen – auch bei gesperrtem Bildschirm. Google hat den Fall unter CVE-2025-48618 anerkannt und einen Patch veröffentlicht.
Wie haben die Hersteller reagiert?
Das Team meldete seine Befunde im März 2026 an Google, Oppo, Quectel, Semtech (vormals Sierra Wireless) und Qualcomm; nach ersten Rückmeldungen informierte es im Mai 2026 zusätzlich die GSM Association. Die Reaktionen fielen unterschiedlich aus. Oppo und Google prüften die Meldungen, stuften sie als informativ ein, sahen sie aber außerhalb der jeweiligen Bug-Bounty-Programme. Semtech bestätigte die Befunde und will Patches des Basisband-Herstellers Qualcomm übernehmen.
Quectel bestätigte ebenfalls, wies aber darauf hin, dass die Shell-Command-Injection bereits bekannt und in neueren Firmware-Versionen behoben war; das Unternehmen hat die SIM-AT-Schnittstelle inzwischen entfernt. Qualcomm stellte eine gehärtete Konfiguration bereit, die die Schnittstelle standardmäßig abschaltet. Die GSMA gab den Bericht an ihr CVD-Gremium weiter, führt den Fall unter CVD-2026-0122 und will 3GPP und ETSI über die Befunde unterrichten. Die Pressemitteilung der Universität nennt zusätzlich die Kennung CVE-2026-57550, ohne sie einem Hersteller zuzuordnen. Für die Zukunft plädieren die Autoren dafür, die Schnittstelle nicht nur per Sperrliste zu blockieren, sondern die zugehörigen Codepfade aus Basisband und Softwarestapel zu entfernen, damit sie nicht durch einen Rückschritt wieder auftaucht.
Fazit
Der eigentliche Befund liegt nicht in vier Einzelschwachstellen, sondern in der Schnittstelle, die sie erreichbar macht. Sie ist kein Fehler, sondern eine dokumentierte Funktion – und ob sie im ausgelieferten Produkt aktiv ist, entscheidet jeder Hersteller für sich. Genau das zeigt der Smartphone-Befund: Dieselben Prozessoren, unterschiedliche Konfiguration, unterschiedliches Ergebnis. Für Betreiber von IoT-Flotten verschiebt das die Frage weg von „ist mein Gerät gepatcht“ hin zu „warum ist diese Funktion in meinem Modul überhaupt eingeschaltet“. Dass Qualcomm und Quectel nachgezogen haben, löst das Grundproblem nicht: Solange der Standard die Funktion vorsieht und Sperrlisten den Code nur verdecken, bleibt sie eine Konfigurationsentscheidung – und Konfigurationsentscheidungen überleben Firmware-Generationen.
Häufige Fragen zur Proactive-SIM-Angriffsfläche
Proactive SIM ist eine in den Mobilfunk-Spezifikationen vorgesehene Fähigkeit, mit der eine SIM-Karte dem Gerät, in dem sie steckt, eine begrenzte Anzahl von Befehlen erteilen kann. Der Befehl RUN AT fordert das Gerät auf, einen bestimmten AT-Befehl auszuführen, also einen Steuerbefehl aus dem seit 1981 gebräuchlichen Modem-Kommandosatz. Dadurch entsteht faktisch eine Befehlsschnittstelle von der Karte ins Gerät.
In der Studie der University of Birmingham öffneten neun von 26 getesteten Geräten die AT-Befehlsschnittstelle gegenüber der SIM. Bei den acht getesteten IoT-Modulen waren es sechs, bei den 18 Smartphones drei. Betroffen sind damit vor allem Geräteklassen wie Ladesäulen, Industrierouter und Telematikeinheiten in Fahrzeugen.
Das Bedrohungsmodell der Studie schließt eSIMs ein, weil sie technisch denselben Weg zum Modem nutzen. Als eine von vier Quellen für feindliche Karten nennen die Forscher ausdrücklich die Fernverwaltung durch böswillige oder kompromittierte Betreiber. Dieser Weg ist für eSIM-basierte IoT-Flotten mit Fernbereitstellung besonders relevant.
Die GSM Association führt den Fall unter der Kennung CVD-2026-0122. CVE-2025-48618 gehört zu einem separaten Befund, den das Team an Google meldete: Über den Befehl LAUNCH BROWSER konnte eine feindliche SIM auf aktuellen Android-Versionen ohne Nutzerinteraktion eine Website öffnen. Die Pressemitteilung der University of Birmingham nennt zusätzlich CVE-2026-57550.
Qualcomm stellt eine gehärtete Konfiguration bereit, die die SIM-AT-Schnittstelle standardmäßig abschaltet, und Quectel hat die Schnittstelle in seinen Modulen entfernt. Betreiber sollten beim Modulhersteller klären, ob die Schnittstelle in der eingesetzten Firmware noch aktiv ist, und entsprechende Updates einspielen. Die Autoren der Studie empfehlen, die zugehörigen Codepfade ganz zu entfernen statt sie nur per Sperrliste zu blockieren.
CATana ist ein Werkzeugpaket aus vier Komponenten, das Tomasz Piotr Lisowski und Marius Muench von der University of Birmingham gemeinsam mit Kristian Covic von der Sicherheitsfirma Fuzzware entwickelt haben. Es prüft systematisch, welche AT-Befehle ein Gerät über die SIM-Schnittstelle entgegennimmt. Der Quellcode ist als Forschungsartefakt auf Zenodo veröffentlicht; fertige Angriffs-Applets hielten die Autoren bewusst zurück.
