mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
89 lines
6.7 KiB
Markdown
89 lines
6.7 KiB
Markdown
# eSIM / Explotación de Java Card VM
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
## Visión general
|
||
Las SIMs embebidas (eSIMs) se implementan como **Embedded UICC (eUICC)** tarjetas inteligentes que ejecutan una **Java Card Virtual Machine (JC VM)** sobre un elemento seguro.
|
||
Debido a que los perfiles y applets pueden ser provisionados *over-the-air* (OTA) a través de Remote SIM Provisioning (RSP), cualquier falla de seguridad de memoria dentro de la JC VM se convierte instantáneamente en un primitivo de ejecución remota de código **dentro del componente más privilegiado del dispositivo**.
|
||
|
||
Esta página describe un compromiso total en el mundo real del eUICC de Kigen (Infineon SLC37 ESA1M2, ARM SC300) causado por la falta de verificaciones de seguridad de tipo en los bytecodes `getfield` y `putfield`. La misma técnica puede ser reutilizada contra otros proveedores que omiten la verificación de bytecode en la tarjeta.
|
||
|
||
## Superficie de ataque
|
||
1. **Gestión de Aplicaciones Remotas (RAM)**
|
||
Los perfiles de eSIM pueden incrustar applets de Java Card arbitrarios. El aprovisionamiento se realiza con APDUs estándar que pueden ser tunelizadas a través de SMS-PP (Short Message Service Point-to-Point) o HTTPS. Si un atacante posee (o roba) las **claves RAM** para un perfil, puede `INSTALL`/`LOAD` un applet malicioso de forma remota.
|
||
2. **Ejecución de bytecode de Java Card**
|
||
Después de la instalación, el applet se ejecuta dentro de la VM. Las verificaciones de tiempo de ejecución faltantes permiten la corrupción de memoria.
|
||
|
||
## El primitivo de confusión de tipo
|
||
`getfield` / `putfield` se supone que solo operan en **referencias de objeto**. En el eUICC de Kigen, las instrucciones nunca validan si el operando en la pila es una *referencia de objeto* o una *referencia de array*. Debido a que una palabra `array.length` vive en el mismo desplazamiento que el primer campo de instancia de un objeto normal, un atacante puede:
|
||
|
||
1. Crear un array de bytes `byte[] buf = new byte[0x100];`
|
||
2. Convertirlo a `Object o = (Object)buf;`
|
||
3. Usar `putfield` para sobrescribir *cualquier* valor de 16 bits dentro de un objeto adyacente (incluyendo entradas de traducción de VTABLE / ptr).
|
||
4. Usar `getfield` para leer *memoria arbitraria* una vez que los punteros internos han sido secuestrados.
|
||
```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 ...
|
||
```
|
||
El primitivo proporciona **lectura / escritura arbitraria** en el espacio de direcciones eUICC, suficiente para volcar la clave privada ECC única del dispositivo que autentica la tarjeta en el ecosistema GSMA.
|
||
|
||
## Flujo de Trabajo de Explotación de Extremo a Extremo
|
||
1. **Enumerar firmware** – Usar el ítem `GET DATA` no documentado `DF1F`:
|
||
```
|
||
80 CA DF 1F 00 // → "ECu10.13" (vulnerable)
|
||
```
|
||
2. **Instalar applet malicioso OTA** – Abusar de las claves públicamente conocidas del Perfil de Prueba Genérico TS.48 y enviar fragmentos SMS-PP que transportan el archivo CAP (`LOAD`) seguido de un `INSTALL`:
|
||
```
|
||
// cadena APDU simplificada
|
||
80 E6 02 00 <data> // LOAD (bloque n)
|
||
80 E6 0C 00 <data> // INSTALL para carga
|
||
```
|
||
3. **Desencadenar confusión de tipo** – Cuando se selecciona el applet, realiza la escritura-qué-dónde para secuestrar una tabla de punteros y filtrar memoria a través de respuestas APDU normales.
|
||
4. **Extraer clave del certificado GSMA** – La clave EC privada se copia a la RAM del applet y se devuelve en fragmentos.
|
||
5. **Suplantar el eUICC** – El par de claves robadas + certificados permiten al atacante autenticarse en *cualquier* servidor RSP como una tarjeta legítima (el enlace EID aún puede ser requerido para algunos operadores).
|
||
6. **Descargar y modificar perfiles** – Los perfiles en texto plano contienen campos altamente sensibles como `OPc`, `AMF`, claves OTA e incluso applets adicionales. El atacante puede:
|
||
* Clonar un perfil a un segundo eUICC (secuestro de voz/SMS);
|
||
* Parchear aplicaciones de Java Card (por ejemplo, insertar spyware STK) antes de volver a cargar;
|
||
* Extraer secretos del operador para abuso a gran escala.
|
||
|
||
## Demostración de Clonación / Secuestro
|
||
Instalar el mismo perfil en **TELÉFONO A** y **TELÉFONO B** resulta en que el Centro de Conmutación Móvil enrute el tráfico entrante al dispositivo que se registró más recientemente. Una sesión de interceptación de SMS de 2FA de Gmail es suficiente para eludir la MFA para la víctima.
|
||
|
||
## Kit de Herramientas de Prueba y Explotación Automatizado
|
||
Los investigadores lanzaron una herramienta interna con un comando `bsc` (*Basic Security Check*) que muestra inmediatamente si una VM de Java Card 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 enviados con el marco:
|
||
* `introspector` – explorador completo de VM y memoria (~1.7 MB Java)
|
||
* `security-test` – applet de verificación genérica de bypass (~150 KB)
|
||
* `exploit` – compromiso Kigen eUICC 100 % fiable (~72 KB)
|
||
|
||
## Mitigaciones
|
||
1. **Verificación de byte-code en la tarjeta** – hacer cumplir el seguimiento completo del flujo de control y del flujo de datos en lugar de solo el de la parte superior de la pila.
|
||
2. **Ocultar encabezado de array** – colocar `length` fuera de los campos de objeto superpuestos.
|
||
3. **Endurecer la política de claves RAM** – nunca enviar perfiles con claves públicas; deshabilitar `INSTALL` en perfiles de prueba (abordado en GSMA TS.48 v7).
|
||
4. **Heurísticas del lado del servidor RSP** – limitar la tasa de descargas de perfiles por EID, monitorear anomalías geográficas, validar la frescura del certificado.
|
||
|
||
## Lista de Verificación Rápida para Pentesters
|
||
* Consultar `GET DATA DF1F` – la cadena de firmware vulnerable `ECu10.13` indica Kigen.
|
||
* Verificar si las claves RAM son conocidas ‑> intentar OTA `INSTALL`/`LOAD`.
|
||
* Después de la instalación del applet, forzar el acceso a un tipo primitivo simple (`objarrconfusion`).
|
||
* Intentar leer las claves privadas del Dominio de Seguridad – éxito = compromiso total.
|
||
|
||
## Referencias
|
||
- [Security Explorations – eSIM security](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 Specification 3.1](https://docs.oracle.com/en/java/javacard/3.1/jc-vm-spec/F12650_05.pdf)
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|