hacktricks/src/generic-hacking/esim-javacard-exploitation.md

# eSIM / Java Card VM Exploitation

{{#include ../banners/hacktricks-training.md}}

## Ü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`/`LOAD`en.
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.
```java
// 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](https://security-explorations.com/esim-security.html)
- [GSMA TS.48 Generic Test Profile v7.0](https://www.gsma.com/get-involved/working-groups/gsma_resources/ts-48-v7-0-generic-euicc-test-profile-for-device-testing/)
- [Java Card VM-Spezifikation 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)

{{#include ../banners/hacktricks-training.md}}