eSIM / Exploração do Java Card VM

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Visão geral

Embedded SIMs (eSIMs) são implementados como smart-cards Embedded UICC (eUICC) que executam uma Java Card Virtual Machine (JC VM) sobre um secure element. Como perfis e applets podem ser provisionados over-the-air (OTA) via Remote SIM Provisioning (RSP), qualquer falha de segurança de memória dentro da JC VM torna-se instantaneamente uma primitiva de execução remota de código dentro do componente com mais privilégios do handset.

Esta página descreve um comprometimento completo do mundo real do eUICC da Kigen (Infineon SLC37 ESA1M2, ARM SC300) causado pela ausência de checagens de segurança de tipo nos bytecodes getfield e putfield. A mesma técnica pode ser reutilizada contra outros vendors que omitem a verificação de byte-code on-card.

Superfície de Ataque

  1. Gerenciamento Remoto de Aplicações (RAM) eSIM profiles podem embutir applets Java Card arbitrários. O provisionamento é realizado com APDUs padrão que podem ser tunelados via SMS-PP (Short Message Service Point-to-Point) ou HTTPS. Se um atacante possuir (ou roubar) as RAM keys de um perfil, ele pode INSTALL/LOAD um applet malicioso remotamente.
  2. Execução de byte-code Java Card Após a instalação, o applet executa dentro da VM. Falta de checagens em tempo de execução permite corrupção de memória.

Mudanças no ecossistema 2024–2025

  • GSMA TS.48 v7.0 (18 Jun 2025) removeu public RAM keysets do Generic Test Profile e bloqueia INSTALL a menos que chaves randomizadas sejam fornecidas; perfis em cache v≤6 ainda expõem RAM keys estáticas e permanecem exploráveis.
  • GSMA AN‑2025‑07 (09 Jul 2025) recomenda verificação de bytecode on-card; a maioria das eUICCs ainda pula a verificação completa, então bugs de memória da VM continuam acessíveis após a instalação do applet.
  • Kigen OTA hardening (Jul 2025) bloqueia o carregamento de applets quando perfis legados TS.48 de teste estão ativos e adiciona checagens em tempo de execução, mas dispositivos não corrigidos permanecem vulneráveis.

A primitiva de Type-Confusion

getfield / putfield deveriam operar apenas sobre object references. Na eUICC da Kigen as instruções nunca validam se o operando na stack é uma referência a object ou a array. Como uma palavra array.length vive exatamente no mesmo offset que o primeiro campo de instância de um objeto normal, um atacante pode:

  1. Criar um byte-array byte[] buf = new byte[0x100];
  2. Fazer cast para Object o = (Object)buf;
  3. Usar putfield para sobrescrever qualquer valor de 16-bit dentro de um objeto adjacente (incluindo entradas de VTABLE / ptr translation).
  4. Usar getfield para ler memória arbitrária assim que ponteiros internos forem sequestrados.
// 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 ...

A primitive fornece arbitrary read / write no espaço de endereçamento do eUICC – suficiente para dump da ECC private key única do dispositivo que autentica o cartão no ecossistema GSMA.

Fluxo de Exploração End-to-End

  1. Enumerate firmware – Use o item não documentado GET DATA DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  1. Install malicious applet OTA – Abusar de chaves publicamente conhecidas do TS.48 Generic Test Profile e enviar fragmentos SMS-PP que transportam o CAP file (LOAD) seguido de um 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 o applet é selecionado ele executa o write-what-where para sequestrar uma tabela de ponteiros e leak memory através de respostas APDU normais.
  2. Extract GSMA certificate key – A Private EC key é copiada para a RAM do applet e retornada em partes.
  3. Impersonate the eUICC – O par de chaves roubado + certificados permite que o atacante autentique-se em any RSP server como um cartão legítimo (EID binding pode ainda ser requerido por alguns operadores).
  4. Download and modify profiles – Perfis em plaintext contêm campos altamente sensíveis como OPc, AMF, OTA keys e até applets adicionais. O atacante pode:
  • Clonar um perfil para um segundo eUICC (voice/SMS hijack);
  • Patch Java Card applications (e.g. insert STK spyware) antes de re-upload;
  • Extrair operator secrets para abuso em larga escala.

Cloning / Hijacking Demonstration

Instalar o mesmo perfil em PHONE A e PHONE B faz com que o Mobile Switching Centre roteie o tráfego de entrada para o dispositivo que se registrou mais recentemente. Uma sessão de interceptação de Gmail 2FA SMS é suficiente para contornar o MFA da vítima.

Automated Test & Exploit Toolkit

Os pesquisadores liberaram uma ferramenta interna com um comando bsc (Basic Security Check) que mostra imediatamente se uma Java Card VM é vulnerável:

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 incluídos com o framework:

  • introspector – explorador completo de VM e memória (~1.7 MB Java)
  • security-test – applet genérico de bypass de verificação (~150 KB)
  • exploit – comprometimento 100% confiável do Kigen eUICC (~72 KB)

Mitigações

  1. Verificação de byte-code no cartão – impor rastreamento completo de tipos para control-flow & data-flow em vez de apenas stack-top.
  2. Ocultar cabeçalho do array – colocar length fora de campos de objetos que se sobrepõem.
  3. Endurecer política de chaves em RAM – nunca enviar perfis com chaves públicas; desabilitar INSTALL em perfis de teste (TS.48 v7 remove RAM keysets).
  4. Heurísticas do servidor RSP – limitar taxa de downloads de perfis por EID, monitorar anomalias geográficas, validar a recência dos certificados.
  5. Manter dispositivos fora de perfis de teste legados – aplicar o OTA de julho de 2025 que bloqueia o carregamento de applets com TS.48 v≤6 ou remover o perfil de teste das imagens de fábrica.

Checklist rápido para Pentesters

  • Consultar GET DATA DF1F – string de firmware vulnerável ECu10.13 indica Kigen.
  • Inspecionar perfis carregados: perfis de teste TS.48 com chaves RAM estáticas (v≤6) são diretamente exploráveis; v7 sem chaves RAM requer um novo leak de chave.
  • Verificar se chaves RAM são conhecidas ‑> tentar OTA INSTALL/LOAD.
  • Após instalação do applet, brute-force primitive de cast simples (objarrconfusion).
  • Tentar ler chaves privadas do Security Domain – sucesso = comprometimento total.

References

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks