eSIM / Java Card VM Exploitation

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Resumen

Las eSIM están implementadas como Embedded UICC (eUICC) smart-cards que ejecutan una Java Card Virtual Machine (JC VM) sobre un elemento seguro. Porque los perfiles y applets pueden ser provisionados over-the-air (OTA) vía Remote SIM Provisioning (RSP), cualquier fallo de seguridad de memoria dentro del JC VM se convierte instantáneamente en un remote code-execution primitive dentro del componente con más privilegios del dispositivo.

Esta página describe una compromisión completa real del eUICC de Kigen (Infineon SLC37 ESA1M2, ARM SC300) causada por la ausencia de comprobaciones de seguridad de tipos en los bytecodes getfield y putfield. La misma técnica puede reutilizarse contra otros fabricantes que omiten la verificación de byte-code on-card.

Superficie de ataque

  1. Gestión Remota de Aplicaciones (RAM) Los perfiles eSIM pueden incluir applets arbitrarios de Java Card. El provisionamiento se realiza con APDUs estándar que pueden ser tunelizados mediante SMS-PP (Short Message Service Point-to-Point) o HTTPS. Si un atacante posee (o roba) las RAM keys de un perfil, puede INSTALL/LOAD un applet malicioso de forma remota.
  2. Ejecución de byte-code de Java Card Tras la instalación, el applet se ejecuta dentro de la VM. La ausencia de comprobaciones en tiempo de ejecución permite corrupción de memoria.

Cambios en el ecosistema 2024–2025

  • GSMA TS.48 v7.0 (18 Jun 2025) eliminó los conjuntos de claves RAM públicos del Generic Test Profile y bloquea INSTALL salvo que se proporcionen claves aleatorizadas; los perfiles cacheados v≤6 aún exponen claves RAM estáticas y siguen siendo explotables.
  • GSMA AN‑2025‑07 (09 Jul 2025) recomienda la verificación de bytecode on-card; la mayoría de los eUICC todavía omiten la verificación completa, por lo que los bugs de VM siguen siendo accesibles tras la instalación de un applet.
  • Kigen OTA hardening (Jul 2025) bloquea la carga de applets cuando perfiles de prueba legacy TS.48 están activos y añade comprobaciones en tiempo de ejecución, pero los dispositivos sin parchear siguen siendo vulnerables.

The Type-Confusion Primitive

getfield / putfield están pensados para operar sólo sobre referencias a objetos. En el eUICC de Kigen las instrucciones nunca validan si el operando en la pila es una referencia a objeto o a array. Dado que una palabra array.length vive en el mismo offset exacto que el primer campo de instancia de un objeto normal, un atacante puede:

  1. Create a byte-array byte[] buf = new byte[0x100];
  2. Cast it to Object o = (Object)buf;
  3. Use putfield to overwrite any 16-bit value inside an adjacent object (including VTABLE / ptr translation entries).
  4. Use getfield to read arbitrary memory once internal pointers are hijacked.
// 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 proporciona arbitrary read / write en el espacio de direcciones del eUICC – suficiente para volcar la clave privada ECC única del dispositivo que autentica la tarjeta en el ecosistema GSMA.

Flujo de explotación de extremo a extremo

  1. Enumera el firmware – Usa el item no documentado GET DATA DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  1. Instalar applet malicioso OTA – Abusar de las claves públicamente conocidas del TS.48 Generic Test Profile y enviar fragmentos SMS-PP que transportan el archivo CAP (LOAD) seguido de 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 – Cuando se selecciona el applet ejecuta el write-what-where para secuestrar una tabla de punteros y leak memory a través de respuestas APDU normales.
  2. Extraer la clave de certificado GSMA – La clave privada EC se copia en la RAM del applet y se devuelve en chunks.
  3. Suplantar el eUICC – El par de claves robado + certificados permiten al atacante autenticarse ante cualquier servidor RSP como una tarjeta legítima (EID binding may still be required for some operators).
  4. Descargar y modificar perfiles – Los perfiles en texto claro contienen campos altamente sensibles como OPc, AMF, claves OTA e incluso applets adicionales. El atacante puede:
  • Clonar un perfil en un segundo eUICC (secuestro de voz/SMS);
  • Parchear aplicaciones Java Card (p. ej. insertar spyware STK) antes de volver a subir;
  • Extraer secretos del operador para abuso a gran escala.

Demostración de clonación/secuestro

Instalar el mismo perfil en PHONE A y PHONE B provoca que el Mobile Switching Centre enrute el tráfico entrante al dispositivo que se registró más recientemente. Una sesión de intercepción de SMS de Gmail 2FA es suficiente para eludir el MFA de la víctima.

Toolkit automatizado de prueba y exploit

Los investigadores publicaron una herramienta interna con un comando bsc (Basic Security Check) que muestra inmediatamente si una Java Card VM es vulnerable:

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]

Módulos incluidos con el 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)

Mitigaciones

  1. On-card byte-code verification – forzar el seguimiento completo de tipos en control-flow y data-flow en lugar de solo del stack-top.
  2. Hide array header – colocar length fuera de los campos de objeto que se solapan.
  3. Harden RAM keys policy – nunca enviar perfiles con public keys; deshabilitar INSTALL en test profiles (TS.48 v7 elimina RAM keysets).
  4. RSP server side heuristics – rate-limit profile downloads por EID, monitorizar anomalías geográficas, validar la frescura de los certificados.
  5. Keep devices off legacy test profiles – aplicar el OTA de julio de 2025 que bloquea la carga de applets con TS.48 v≤6 o eliminar el test profile de las imágenes de fábrica.

Quick Checklist for Pentesters

  • Consultar GET DATA DF1F – la cadena de firmware vulnerable ECu10.13 indica Kigen.
  • Inspeccionar perfiles cargados: TS.48 test profiles con static RAM keys (v≤6) son explotables directamente; v7 sin RAM keys requieren un nuevo key leak.
  • Comprobar si los RAM keys son conocidos ‑> intentar OTA INSTALL/LOAD.
  • Tras la instalación del applet, brute-force la simple cast primitive (objarrconfusion).
  • Intentar leer los Security Domain private keys – éxito = full compromise.

References

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks