eSIM / Java Card VM Exploitation

Übersicht

Embedded SIMs (eSIMs) werden als Embedded UICC (eUICC) Smartcards implementiert, die eine Java Card Virtual Machine (JC VM) auf einem sicheren Element ausführen. Da Profile und Applets over-the-air (OTA) über Remote SIM Provisioning (RSP) bereitgestellt werden können, wird jeder Speicherfehler innerhalb der JC VM sofort zu einem Remote-Code-Ausführungsprimitive innerhalb der privilegiertesten Komponente des Geräts.

Diese Seite beschreibt einen realen vollständigen Kompromiss von Kigens eUICC (Infineon SLC37 ESA1M2, ARM SC300), verursacht durch fehlende Typ-Sicherheitsprüfungen in den getfield und putfield Bytecodes. Die gleiche Technik kann gegen andere Anbieter wiederverwendet werden, die die Überprüfung des Bytecodes auf der Karte weglassen.

Angriffsfläche

1. Remote Application Management (RAM) eSIM-Profile können beliebige Java Card Applets einbetten. Die Bereitstellung erfolgt mit standardmäßigen APDUs, die über SMS-PP (Short Message Service Point-to-Point) oder HTTPS tunneln können. Wenn ein Angreifer die RAM-Schlüssel für ein Profil besitzt (oder stiehlt), kann er ein bösartiges Applet remote INSTALL/LOADen.
2. Java Card Bytecode-Ausführung Nach der Installation wird das Applet innerhalb der VM ausgeführt. Fehlende Laufzeitprüfungen ermöglichen Speicherbeschädigungen.

Der Typ-Verwirrungsprimitive

getfield / putfield sollen nur auf Objektverweisen arbeiten. In Kigen eUICC validieren die Anweisungen niemals, ob der Operand auf dem Stack ein Objekt oder ein Array-Verweis ist. Da ein array.length Wort an genau demselben Offset wie das erste Instanzfeld eines normalen Objekts liegt, kann ein Angreifer:

1. Ein Byte-Array erstellen byte[] buf = new byte[0x100];
2. Es in Object o = (Object)buf; umwandeln.
3. putfield verwenden, um irgendeinen 16-Bit-Wert innerhalb eines benachbarten Objekts (einschließlich VTABLE / ptr Übersetzungseinträge) zu überschreiben.
4. getfield verwenden, um willkürlichen Speicher zu lesen, sobald interne Zeiger übernommen wurden.

// Pseudo-bytecode sequence executed by the malicious applet
// buf = newarray byte 0x100
// o   = (Object) buf            // illegal but not verified
// putfield <victimObject+offset>, 0xCAFE // arbitrary write
// ... set up read-what-where gadgets ...

Die Primitive bietet willkürlichen Lese-/Schreibzugriff im eUICC-Adressraum – genug, um den gerätespezifischen ECC-Privatschlüssel zu dumpen, der die Karte im GSMA-Ökosystem authentifiziert.

End-to-End-Ausbeutungsworkflow

1. Firmware auflisten – Verwenden Sie den nicht dokumentierten GET DATA-Eintrag DF1F:

80 CA DF 1F 00   // → "ECu10.13" (anfällig)

2. Bösartiges Applet OTA installieren – Missbrauch von öffentlich bekannten Schlüsseln des TS.48 Generic Test Profile und Push von SMS-PP-Fragmenten, die die CAP-Datei (LOAD) transportieren, gefolgt von einem INSTALL:

// vereinfachte APDU-Kette
80 E6 02 00 <data>   // LOAD (Block n)
80 E6 0C 00 <data>   // INSTALL für Load

3. Typverwirrung auslösen – Wenn das Applet ausgewählt wird, führt es den Write-What-Where aus, um eine Zeigertabelle zu übernehmen und Speicher durch normale APDU-Antworten zu leaken.
4. GSMA-Zertifikatschlüssel extrahieren – Der private EC-Schlüssel wird in den RAM des Applets kopiert und in Stücken zurückgegeben.
5. Das eUICC impersonifizieren – Das gestohlene Schlüsselpaar + Zertifikate ermöglichen es dem Angreifer, sich als legitime Karte bei irgendeinem RSP-Server zu authentifizieren (EID-Bindung kann für einige Betreiber weiterhin erforderlich sein).
6. Profile herunterladen und modifizieren – Klartextprofile enthalten hochsensible Felder wie OPc, AMF, OTA-Schlüssel und sogar zusätzliche Applets. Der Angreifer kann:

• Ein Profil auf ein zweites eUICC klonen (Voice/SMS-Hijack);
• Java Card-Anwendungen patchen (z. B. STK-Spyware einfügen), bevor sie erneut hochgeladen werden;
• Betreibergeheimnisse für großflächigen Missbrauch extrahieren.

Klon- / Hijacking-Demonstration

Die Installation desselben Profils auf PHONE A und PHONE B führt dazu, dass das Mobile Switching Centre den eingehenden Verkehr an das Gerät weiterleitet, das sich zuletzt registriert hat. Eine Sitzung der Gmail 2FA-SMS-Abfangung reicht aus, um MFA für das Opfer zu umgehen.

Automatisiertes Test- und Exploit-Toolkit

Die Forscher veröffentlichten ein internes Tool mit einem bsc (Basic Security Check)-Befehl, der sofort zeigt, ob eine Java Card VM anfällig ist:

scard> bsc
- castcheck        [arbitrary int/obj casts]
- ptrgranularity   [pointer granularity/tr table presence]
- locvaraccess     [local variable access]
- stkframeaccess   [stack frame access]
- instfieldaccess  [instance field access]
- objarrconfusion  [object/array size field confusion]

Module, die mit dem Framework geliefert werden:

• introspector – vollständiger VM- und Speicherscanner (~1,7 MB Java)
• security-test – generische Verifizierungs-Bypass-Applet (~150 KB)
• exploit – 100 % zuverlässiger Kigen eUICC-Kompromiss (~72 KB)

Minderung

1. On-Card-Bytecode-Verifizierung – vollständige Kontrolle über den Kontrollfluss & Datenfluss-Tracking durchsetzen, anstatt nur den Stack-Top.
2. Array-Header verbergen – length außerhalb von überlappenden Objektfeldern platzieren.
3. RAM-Schlüsselrichtlinie härten – niemals Profile mit öffentlichen Schlüsseln ausliefern; INSTALL in Testprofilen deaktivieren (behandelt in GSMA TS.48 v7).
4. RSP-Server-seitige Heuristiken – Download von Profilen pro EID drosseln, geografische Anomalien überwachen, Frische der Zertifikate validieren.

Schnelle Checkliste für Pentester

• Abfrage GET DATA DF1F – verwundbare Firmware-Zeichenfolge ECu10.13 weist auf Kigen hin.
• Überprüfen, ob RAM-Schlüssel bekannt sind ‑> OTA INSTALL/LOAD versuchen.
• Nach der Installation des Applets einfache Cast-Primitiven brute-forcen (objarrconfusion).
• Versuchen, private Schlüssel des Sicherheitsbereichs zu lesen – Erfolg = vollständiger Kompromiss.

Referenzen

• Security Explorations – eSIM-Sicherheit
• GSMA TS.48 Generic Test Profile v7.0
• Java Card VM-Spezifikation 3.1