eSIM / Java Card VM-Ausnutzung

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Übersicht

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

Diese Seite beschreibt eine reale vollständige Kompromittierung von Kigens eUICC (Infineon SLC37 ESA1M2, ARM SC300), verursacht durch fehlende Type-Safety-Prüfungen in den getfield- und putfield-Bytecodes. Dieselbe Technik kann gegen andere Anbieter wiederverwendet werden, die auf-card byte-code verification weglassen.

Angriffsfläche

  1. Remote Application Management (RAM) eSIM-Profile können beliebige Java Card Applets einbetten. Die Provisionierung erfolgt mit standardmäßigen APDUs, die über SMS-PP (Short Message Service Point-to-Point) oder HTTPS getunnelt werden können. Wenn ein Angreifer die RAM keys für ein Profil besitzt (oder stiehlt), kann er ein bösartiges Applet per INSTALL/LOAD remote installieren.
  2. Java Card byte-code execution Nach der Installation läuft das Applet innerhalb der VM. Fehlende Laufzeitprüfungen erlauben Speicherkorruption.

2024–2025 Änderungen im Ökosystem

  • GSMA TS.48 v7.0 (18 Jun 2025) entfernt öffentliche RAM-Keysets aus dem Generic Test Profile und blockiert INSTALL, sofern nicht zufallsgenerierte Keys bereitgestellt werden; gecachte v≤6-Profile exponieren weiterhin statische RAM keys und bleiben ausnutzbar.
  • GSMA AN‑2025‑07 (09 Jul 2025) empfiehlt on-card bytecode verification; die meisten eUICCs überspringen weiterhin die vollständige Verifikation, sodass VM-Speicher-Bugs nach der Applet-Installation erreichbar bleiben.
  • Kigen OTA hardening (Jul 2025) blockiert das Laden von Applets, wenn Legacy TS.48 Testprofile aktiv sind, und fügt Laufzeitprüfungen hinzu, aber ungepatchte Geräte bleiben verwundbar.

Die Type-Confusion-Primitive

getfield / putfield sollen nur auf Objektreferenzen operieren. In Kigen eUICC validieren die Instruktionen nie, ob das Operand auf dem Stack eine Objekt- oder eine Array-Referenz ist. Weil ein array.length-Wort genau am selben Offset wie das erste Instanzfeld eines normalen Objekts liegt, kann ein Angreifer:

  1. Erstelle ein Byte-Array byte[] buf = new byte[0x100];
  2. Cast es zu Object o = (Object)buf;
  3. Benutze putfield, um beliebigen 16-Bit-Wert innerhalb eines angrenzenden Objekts zu überschreiben (inklusive VTABLE / ptr translation entries).
  4. Benutze getfield, um beliebigen 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 stellt arbitrary read / write im eUICC-Adressraum bereit – ausreichend, um den geräteindividuellen ECC private key auszulesen, der die Karte gegenüber dem GSMA-Ökosystem authentifiziert.

Ende-zu-Ende Exploit-Workflow

  1. Firmware enumerieren – Verwende das undokumentierte GET DATA item DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  1. Malicious applet OTA installieren – Missbrauche öffentlich bekannte Keys des TS.48 Generic Test Profile und sende SMS-PP-Fragmente, die die CAP-Datei (LOAD) transportieren, gefolgt von einem INSTALL:
// simplified APDU chain
80 E6 02 00 <data>   // LOAD (block n)
80 E6 0C 00 <data>   // INSTALL for load
  1. Type-confusion auslösen – Wenn das applet selektiert wird, führt es das write-what-where aus, um eine Pointer-Tabelle zu kapern und memory durch normale APDU-Antworten leak zu lassen.
  2. GSMA certificate key extrahieren – Der private EC key wird in den RAM des Applets kopiert und in Chunks zurückgegeben.
  3. Die eUICC impersonieren – Das gestohlene Key-Paar + Zertifikate erlauben dem Angreifer, sich gegenüber jedem RSP-Server als legitime Karte zu authentifizieren (EID binding kann bei einigen Betreibern weiterhin erforderlich sein).
  4. Profile herunterladen und modifizieren – Klartext-Profile enthalten hochsensitive Felder wie OPc, AMF, OTA keys und sogar zusätzliche Applets. Der Angreifer kann:
  • Ein Profil auf eine zweite eUICC klonen (voice/SMS hijack);
  • Java Card-Anwendungen patchen (z. B. STK spyware einfügen) bevor er sie wieder hochlädt;
  • Operator-Secrets extrahieren für Missbrauch in großem Maßstab.

Klonen / Hijacking Demonstration

Die Installation desselben Profils auf PHONE A und PHONE B führt dazu, dass das Mobile Switching Centre eingehenden Traffic an das Gerät routet, das sich zuletzt registriert hat. Eine einzige Gmail 2FA SMS-Interception-Session reicht aus, um die MFA des Opfers zu umgehen.

Automatisiertes Test- & Exploit-Toolkit

Die Forscher veröffentlichten ein internes Tool mit einem bsc (Basic Security Check) Befehl, der sofort anzeigt, ob eine Java Card VM verwundbar 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]

Mit dem Framework ausgelieferte Module:

  • introspector – vollständiger VM- und Speicher-Explorer (~1.7 MB Java)
  • security-test – generisches verification bypass applet (~150 KB)
  • exploit – 100 % reliable Kigen eUICC compromise (~72 KB)

Gegenmaßnahmen

  1. On-card byte-code verification – vollständiges Control-Flow- und Data-Flow-Type-Tracking durchsetzen statt nur stack-top.
  2. Hide array header – platziere length außerhalb überlappender Objektfelder.
  3. Harden RAM keys policy – niemals Profile mit public keys ausliefern; INSTALL in Testprofilen deaktivieren (TS.48 v7 entfernt RAM keysets).
  4. RSP server side heuristics – Profile-Downloads pro EID rate-limitieren, geografische Anomalien überwachen, Zertifikatsfrische validieren.
  5. Keep devices off legacy test profiles – das July 2025 OTA anwenden, das Applet-Loading mit TS.48 v≤6 blockiert, oder das Testprofil aus Factory-Images entfernen.

Schnelle Checkliste für Pentesters

  • Query GET DATA DF1F – der vulnerable firmware string ECu10.13 weist auf Kigen hin.
  • Inspect loaded profiles: TS.48 test profiles mit statischen RAM keys (v≤6) sind direkt exploitable; v7 ohne RAM keys benötigen einen neuen key leak.
  • Check if RAM keys are known ‑> attempt OTA INSTALL/LOAD.
  • After applet installation, brute-force simple cast primitive (objarrconfusion).
  • Try to read Security Domain private keys – Erfolg = vollständige Kompromittierung.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks