eSIM / Exploitation de la VM Java Card

Aperçu

Les SIM intégrées (eSIM) sont mises en œuvre sous forme de UICC intégrée (eUICC) cartes intelligentes qui exécutent une Machine Virtuelle Java Card (JC VM) sur un élément sécurisé. Étant donné que les profils et les applets peuvent être provisionnés over-the-air (OTA) via le Provisionnement à Distance de SIM (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é de l'appareil.

Cette page décrit un compromis complet dans le monde réel de l'eUICC de Kigen (Infineon SLC37 ESA1M2, ARM SC300) causé par l'absence de vérifications de sécurité de type dans les bytecodes getfield et putfield. La même technique peut être réutilisée contre d'autres fournisseurs qui omettent la vérification des bytecodes sur la carte.

Surface d'attaque

1. Gestion d'Application à Distance (RAM) Les profils eSIM peuvent intégrer des applets Java Card arbitraires. Le provisionnement est effectué avec des APDUs standard qui peuvent être tunnélisés via SMS-PP (Short Message Service Point-to-Point) ou HTTPS. Si un attaquant possède (ou vole) les clés RAM pour un profil, il peut INSTALL/LOAD une applet malveillante à distance.
2. Exécution de bytecode Java Card Après l'installation, l'applet s'exécute à l'intérieur de la VM. L'absence de vérifications à l'exécution permet la corruption de la mémoire.

Le Primitive de Confusion de Type

getfield / putfield sont censés fonctionner uniquement sur des références d'objet. Dans l'eUICC de Kigen, les instructions ne valident jamais si l'opérande sur la pile est une référence d'objet ou une référence de tableau. Étant donné qu'un mot array.length se trouve à exactement le même décalage que le premier champ d'instance d'un objet normal, un attaquant peut :

1. Créer un tableau d'octets byte[] buf = new byte[0x100];
2. Le caster en Object o = (Object)buf;
3. Utiliser putfield pour écraser n'importe quelle valeur de 16 bits à l'intérieur d'un objet adjacent (y compris les entrées de traduction VTABLE / ptr).
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 ...

Le primitive fournit une lecture / écriture arbitraire dans l'espace d'adresses eUICC – suffisant pour extraire la clé privée ECC unique au dispositif qui authentifie la carte dans l'écosystème GSMA.

Flux de travail d'exploitation de bout en bout

1. Énumérer le firmware – Utiliser l'élément GET DATA non documenté DF1F :

80 CA DF 1F 00   // → "ECu10.13" (vulnérable)

2. Installer un applet malveillant OTA – Abuser des clés publiquement connues du TS.48 Generic Test Profile et pousser des fragments SMS-PP qui transportent le fichier CAP (LOAD) suivi d'un INSTALL :

// chaîne APDU simplifiée
80 E6 02 00 <data>   // LOAD (bloc n)
80 E6 0C 00 <data>   // INSTALL pour le chargement

3. Déclencher une confusion de type – Lorsque l'applet est sélectionné, il effectue l'écriture-quoi-où pour détourner une table de pointeurs et divulguer de la mémoire à travers des réponses APDU normales.
4. Extraire la clé de certificat GSMA – La clé EC privée est copiée dans la RAM de l'applet et renvoyée par morceaux.
5. Imiter l'eUICC – La paire de clés volée + certificats permet à l'attaquant de s'authentifier auprès de n'importe quel serveur RSP en tant que carte légitime (le lien EID peut encore être requis pour certains opérateurs).
6. Télécharger et modifier des profils – Les profils en texte clair contiennent des champs hautement sensibles tels que OPc, AMF, clés OTA et même des applets supplémentaires. L'attaquant peut :

• Cloner un profil sur un second eUICC (détournement de voix/SMS) ;
• Patch les applications Java Card (par exemple, insérer un spyware STK) avant de les re-télécharger ;
• Extraire des secrets d'opérateur pour un abus à grande échelle.

Démonstration de clonage / détournement

Installer le même profil sur TÉLÉPHONE A et TÉLÉPHONE B entraîne le Centre de commutation mobile à router le trafic entrant vers le dispositif qui s'est récemment enregistré. Une session d'interception de SMS 2FA Gmail suffit à contourner la MFA pour la victime.

Outil de test et d'exploitation automatisé

Les chercheurs ont publié un outil interne avec une commande bsc (Basic Security Check) qui montre immédiatement si une VM Java Card 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 expédiés avec le framework :

• introspector – explorateur complet de VM et de mémoire (~1,7 Mo Java)
• security-test – applet de vérification générique de contournement (~150 Ko)
• exploit – compromis Kigen eUICC 100 % fiable (~72 Ko)

Atténuations

1. Vérification du byte-code sur la carte – appliquer un suivi complet du flux de contrôle et du flux de données au lieu de se limiter au sommet de la pile.
2. Cacher l'en-tête du tableau – placer length en dehors des champs d'objet qui se chevauchent.
3. Renforcer la politique des clés RAM – ne jamais expédier de profils avec des clés publiques ; désactiver INSTALL dans les profils de test (abordé dans GSMA TS.48 v7).
4. Heuristiques côté serveur RSP – limiter le taux de téléchargements de profils par EID, surveiller les anomalies géographiques, valider la fraîcheur des certificats.

Liste de vérification rapide pour les pentesters

• Interroger GET DATA DF1F – la chaîne de firmware vulnérable ECu10.13 indique Kigen.
• Vérifier si les clés RAM sont connues ‑> tenter INSTALL/LOAD OTA.
• Après l'installation de l'applet, forcer le brute-force d'un type primitif simple (objarrconfusion).
• Essayer de lire les clés privées du domaine de sécurité – succès = compromis total.

Références

• Security Explorations – eSIM security
• GSMA TS.48 Generic Test Profile v7.0
• Java Card VM Specification 3.1