eSIM / Java Card VM Exploitation

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Vue d’ensemble

Embedded SIMs (eSIMs) sont implémentées comme des cartes à puce Embedded UICC (eUICC) qui exécutent une Java Card Virtual Machine (JC VM) au-dessus d’un secure element. Parce que les profils et applets peuvent être provisionnés over-the-air (OTA) via Remote SIM Provisioning (RSP), toute faille de sécurité mémoire à l’intérieur de la JC VM devient instantanément un primitive d’exécution de code à distance à l’intérieur du composant le plus privilégié du terminal.

Cette page décrit une compromission complète en conditions réelles de l’eUICC de Kigen (Infineon SLC37 ESA1M2, ARM SC300) causée par l’absence de vérifications de type dans les bytecodes getfield et putfield. La même technique peut être réutilisée contre d’autres vendors qui omettent la vérification des bytecodes sur la carte.

Surface d’attaque

  1. Remote Application Management (RAM) Les profils eSIM peuvent embarquer des applets Java Card arbitraires. Le provisioning est réalisé avec des APDUs standards qui peuvent être tunnelisés via SMS-PP (Short Message Service Point-to-Point) ou HTTPS. Si un attaquant possède (ou vole) les RAM keys d’un profil, il peut INSTALL/LOAD un applet malveillant à distance.
  2. Java Card byte-code execution Après l’installation, l’applet s’exécute dans la VM. L’absence de vérifications à l’exécution permet des corruptions mémoire.

2024–2025 ecosystem changes

  • GSMA TS.48 v7.0 (18 Jun 2025) a retiré les jeux de clés RAM publiques du Generic Test Profile et bloque INSTALL à moins que des clés randomisées ne soient fournies ; les profils en cache v≤6 exposent toujours des RAM keys statiques et restent exploitables.
  • GSMA AN‑2025‑07 (09 Jul 2025) recommande la vérification des bytecodes sur la carte ; la plupart des eUICCs sautent encore la vérification complète, donc les bugs mémoire du VM restent accessibles après l’installation d’un applet.
  • Kigen OTA hardening (Jul 2025) bloque le chargement d’applets lorsque des profils de test TS.48 legacy sont actifs et ajoute des vérifications à l’exécution, mais les appareils non patchés restent vulnérables.

The Type-Confusion Primitive

getfield / putfield sont censés opérer uniquement sur des object references. Dans l’eUICC Kigen, les instructions ne valident jamais si l’opérande sur la pile est une référence object ou une référence array. Parce qu’un mot array.length se trouve au même offset exact que le premier champ d’instance d’un objet normal, un attaquant peut :

  1. Créer un byte-array byte[] buf = new byte[0x100];
  2. Le caster en Object o = (Object)buf;
  3. Utiliser putfield pour écraser n’importe quelle valeur 16 bits à l’intérieur d’un objet adjacent (y compris VTABLE / ptr translation entries).
  4. Utiliser getfield pour lire de la mémoire arbitraire une fois que les pointeurs internes sont détournés.
// 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 primitive fournit lecture/écriture arbitraires dans l’espace d’adresses eUICC – suffisant pour extraire la clé privée ECC unique de l’appareil qui authentifie la carte auprès de l’écosystème GSMA.

End-to-End Exploitation Workflow

  1. Énumérer le firmware – Utiliser l’élément non documenté GET DATA DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  1. Installer un applet malveillant OTA – Abuser des clés publiquement connues du TS.48 Generic Test Profile et envoyer des fragments SMS-PP transportant le fichier CAP (LOAD) suivi d’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 – Lorsque l’applet est sélectionné il effectue le write-what-where pour détourner une table de pointeurs et leak la mémoire via des réponses APDU normales.
  2. Extract GSMA certificate key – La clé EC privée est copiée dans la RAM de l’applet et renvoyée par morceaux.
  3. Impersonate the eUICC – La paire de clés volée + les certificats permettent à l’attaquant de s’authentifier auprès de any serveur RSP en tant que carte légitime (EID binding peut encore être requis pour certains opérateurs).
  4. Download and modify profiles – Les profils en clair contiennent des champs hautement sensibles tels que OPc, AMF, les clés OTA et même des applets supplémentaires. L’attaquant peut :
  • Cloner un profil sur un second eUICC (détournement voix/SMS);
  • Modifier des applications Java Card (par ex. insérer un spyware STK) avant de les ré-uploader;
  • Extraire les secrets opérateur pour un abus à grande échelle.

Cloning / Hijacking Demonstration

L’installation du même profil sur PHONE A et PHONE B fait que le Mobile Switching Centre achemine le trafic entrant vers l’appareil qui s’est enregistré le plus récemment. Une seule interception de SMS 2FA Gmail suffit à contourner le MFA de la victime.

Automated Test & Exploit Toolkit

Les chercheurs ont publié un outil interne avec une commande bsc (Basic Security Check) qui indique immédiatement si une Java Card VM est vulnérable:

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]

Modules fournis avec le framework :

  • introspector – explorateur complet de VM et de mémoire (~1.7 MB Java)
  • security-test – applet de contournement de vérification générique (~150 KB)
  • exploit – compromis Kigen eUICC fiable à 100 % (~72 KB)

Contre-mesures

  1. On-card byte-code verification – enforce full control-flow & data-flow type tracking instead of stack-top only.
  2. Hide array header – place length outside of overlapping object fields.
  3. Harden RAM keys policy – never ship profiles with public keys; disable INSTALL in test profiles (TS.48 v7 removes RAM keysets).
  4. RSP server side heuristics – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.
  5. Keep devices off legacy test profiles – apply the July 2025 OTA that blocks applet loading with TS.48 v≤6 or remove the test profile from factory images.

Checklist rapide pour pentesters

  • Interroger GET DATA DF1F – la chaîne de firmware vulnérable ECu10.13 indique Kigen.
  • Inspecter les profils chargés : les profils de test TS.48 avec des clés RAM statiques (v≤6) sont directement exploitables ; v7 sans clés RAM nécessite un nouveau key leak.
  • Vérifier si les clés RAM sont connues -> tenter OTA INSTALL/LOAD.
  • Après l’installation de l’applet, brute-force la primitive de cast simple (objarrconfusion).
  • Tenter de lire les clés privées du Security Domain – succès = compromission totale.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks