eSIM / Java Card VM Exploitation

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Panoramica

Le eSIM (Embedded SIM) sono implementate come smart-card Embedded UICC (eUICC) che eseguono una Java Card Virtual Machine (JC VM) su un elemento sicuro. Poiché i profili e gli applet possono essere provisionati over-the-air (OTA) via Remote SIM Provisioning (RSP), qualsiasi vulnerabilità di type-safety all’interno della JC VM diventa immediatamente una primitive di remote code-execution all’interno del componente più privilegiato del handset.

Questa pagina descrive una compromissione completa nel mondo reale dell’eUICC di Kigen (Infineon SLC37 ESA1M2, ARM SC300) causata dalla mancanza di controlli di type-safety nei bytecode getfield e putfield. La stessa tecnica può essere riutilizzata contro altri vendor che omettono la on-card byte-code verification.

Superficie di attacco

  1. Remote Application Management (RAM) I profili eSIM possono incorporare applet Java Card arbitrari. Il provisioning è effettuato con APDU standard che possono essere tunnelizzati tramite SMS-PP (Short Message Service Point-to-Point) o HTTPS. Se un attacker possiede (o ruba) le RAM keys di un profilo, può INSTALL/LOAD un applet malevolo da remoto.
  2. Java Card byte-code execution Dopo l’installazione, l’applet viene eseguito all’interno della VM. La mancanza di run-time checks permette la corruzione di memoria.

2024–2025 ecosystem changes

  • GSMA TS.48 v7.0 (18 Jun 2025) ha rimosso i public RAM keysets dal Generic Test Profile e blocca INSTALL a meno che non siano forniti randomized keys; i profili cached v≤6 espongono ancora static RAM keys e rimangono sfruttabili.
  • GSMA AN‑2025‑07 (09 Jul 2025) raccomanda la on-card bytecode verification; la maggior parte degli eUICCs salta ancora la verifica completa quindi i VM memory bugs restano raggiungibili dopo l’install dell’applet.
  • Kigen OTA hardening (Jul 2025) blocca il caricamento di applet quando profili di test legacy TS.48 sono attivi e aggiunge runtime checks, ma i dispositivi non patchati rimangono vulnerabili.

The Type-Confusion Primitive

getfield / putfield dovrebbero operare solamente su object references. Nell’eUICC Kigen le istruzioni non verificano mai se l’operando sullo stack è un riferimento a object o ad array. Poiché una parola array.length si trova esattamente allo stesso offset del primo instance field di un object normale, un attacker può:

  1. Creare un byte-array byte[] buf = new byte[0x100];
  2. Castarlo in Object o = (Object)buf;
  3. Usare putfield per sovrascrivere qualsiasi valore a 16-bit all’interno di un oggetto adiacente (inclusi VTABLE / ptr translation entries).
  4. Usare getfield per leggere memoria arbitraria una volta che i puntatori interni sono stati dirottati.
// 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 ...

La primitiva fornisce lettura/scrittura arbitraria nello spazio di indirizzi dell’eUICC – sufficiente per dumpare la chiave privata ECC univoca del dispositivo che autentica la card nell’ecosistema GSMA.

Flusso di sfruttamento end-to-end

  1. Enumerare il firmware – Usare l’item non documentato GET DATA DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerabile)
  1. Installare un applet malevolo OTA – Abusare delle chiavi pubblicamente note del TS.48 Generic Test Profile e inviare frammenti SMS-PP che trasportano il CAP file (LOAD) seguito da un INSTALL:
// simplified APDU chain
80 E6 02 00 <data>   // LOAD (block n)
80 E6 0C 00 <data>   // INSTALL for load
  1. Trigger type-confusion – Quando l’applet viene selezionato esegue il write-what-where per dirottare una tabella di puntatori e leak di memoria attraverso risposte APDU normali.
  2. Estrarre la chiave del certificato GSMA – La chiave privata EC viene copiata nella RAM dell’applet e restituita a pezzi.
  3. Impersonare l’eUICC – La coppia di chiavi rubata + i certificati consentono all’attaccante di autenticarsi a qualsiasi server RSP come una card legittima (l’EID binding può ancora essere richiesto per alcuni operatori).
  4. Scaricare e modificare i profili – I profili in chiaro contengono campi altamente sensibili come OPc, AMF, chiavi OTA e persino applet aggiuntive. L’attaccante può:
  • Clonare un profilo su un secondo eUICC (dirottamento voce/SMS);
  • Patchare le applicazioni Java Card (es. inserire spyware STK) prima di ricaricarle;
  • Estrarre segreti dell’operatore per abusi su larga scala.

Dimostrazione di clonazione/dirottamento

Installare lo stesso profilo su PHONE A e PHONE B fa sì che il Mobile Switching Centre instradi il traffico in arrivo verso il dispositivo che si è registrato più di recente. Una singola sessione di intercettazione SMS 2FA di Gmail è sufficiente per bypassare l’MFA della vittima.

Toolkit automatizzato per test e exploit

I ricercatori hanno rilasciato uno strumento interno con un comando bsc (Basic Security Check) che mostra immediatamente se una Java Card VM è vulnerabile:

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]

Moduli forniti con il framework:

  • introspector – full VM and memory explorer (~1.7 MB Java)
  • security-test – generic verification bypass applet (~150 KB)
  • exploit – 100 % reliable Kigen eUICC compromise (~72 KB)

Mitigazioni

  1. On-card byte-code verification – applicare il tracciamento completo dei tipi per control-flow e data-flow invece di limitarsi al top dello stack.
  2. Hide array header – posizionare length al di fuori dei campi oggetto sovrapposti.
  3. Harden RAM keys policy – non distribuire profili con chiavi pubbliche; disabilitare INSTALL nei profili di test (TS.48 v7 rimuove i keyset RAM).
  4. RSP server side heuristics – rate-limitare i download dei profili per EID, monitorare anomalie geografiche, validare la freschezza dei certificati.
  5. Keep devices off legacy test profiles – applicare l’OTA di luglio 2025 che blocca il caricamento di applet con TS.48 v≤6 o rimuovere il profilo di test dalle immagini di fabbrica.

Checklist rapida per Pentesters

  • Interrogare GET DATA DF1F – la stringa firmware vulnerabile ECu10.13 indica Kigen.
  • Ispezionare i profili caricati: i profili di test TS.48 con RAM keys statiche (v≤6) sono direttamente sfruttabili; v7 senza RAM keys richiedono un nuovo key leak.
  • Verificare se le RAM keys sono note ‑> tentare OTA INSTALL/LOAD.
  • Dopo l’installazione dell’applet, brute-force della primitiva simple cast (objarrconfusion).
  • Tentare di leggere le private key del Security Domain – successo = compromissione totale.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks