eSIM / Exploração da VM Java Card

Visão Geral

SIMs embutidos (eSIMs) são implementados como UICC Embutido (eUICC) smart-cards que executam uma Máquina Virtual Java Card (JC VM) em cima de um elemento seguro. Como perfis e applets podem ser provisionados over-the-air (OTA) via Provisionamento Remoto de SIM (RSP), qualquer falha de segurança de memória dentro da JC VM se torna instantaneamente um primitivo de execução remota de código dentro do componente mais privilegiado do dispositivo.

Esta página descreve uma comprometimento total no mundo real do eUICC da Kigen (Infineon SLC37 ESA1M2, ARM SC300) causado pela falta de verificações de segurança de tipo nos bytecodes getfield e putfield. A mesma técnica pode ser reutilizada contra outros fornecedores que omitem a verificação de bytecode no cartão.

Superfície de Ataque

1. Gerenciamento Remoto de Aplicações (RAM) Perfis de eSIM podem incorporar applets Java Card arbitrários. O provisionamento é realizado com APDUs padrão que podem ser tuneladas através de SMS-PP (Serviço de Mensagens Curtas Ponto-a-Ponto) ou HTTPS. Se um atacante possui (ou rouba) as chaves RAM para um perfil, ele pode INSTALL/LOAD um applet malicioso remotamente.
2. Execução de bytecode Java Card Após a instalação, o applet é executado dentro da VM. Verificações de tempo de execução ausentes permitem corrupção de memória.

O Primitivo de Confusão de Tipo

getfield / putfield devem operar apenas em referências de objeto. No eUICC da Kigen, as instruções nunca validam se o operando na pilha é uma referência de objeto ou uma referência de array. Como uma palavra array.length reside no exato mesmo deslocamento que o primeiro campo de instância de um objeto normal, um atacante pode:

1. Criar um array de bytes byte[] buf = new byte[0x100];
2. Convertê-lo para Object o = (Object)buf;
3. Usar putfield para sobrescrever qualquer valor de 16 bits dentro de um objeto adjacente (incluindo entradas de tradução VTABLE / ptr).
4. Usar getfield para ler memória arbitrária uma vez que os ponteiros internos sejam 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 primitiva fornece leitura / escrita arbitrária no espaço de endereços eUICC – o suficiente para despejar a chave privada ECC única do dispositivo que autentica o cartão no ecossistema GSMA.

Fluxo de Trabalho de Exploração de Ponta a Ponta

1. Enumerar firmware – Use o item GET DATA não documentado DF1F:

80 CA DF 1F 00   // → "ECu10.13" (vulnerável)

2. Instalar applet malicioso OTA – Abuse chaves publicamente conhecidas do TS.48 Generic Test Profile e envie fragmentos SMS-PP que transportam o arquivo CAP (LOAD) seguido de um INSTALL:

// cadeia APDU simplificada
80 E6 02 00 <data>   // LOAD (bloco n)
80 E6 0C 00 <data>   // INSTALL para load

3. Acionar confusão de tipo – Quando o applet é selecionado, ele realiza a escrita-o-que-onde para sequestrar uma tabela de ponteiros e vazar memória através de respostas APDU normais.
4. Extrair chave do certificado GSMA – A chave EC privada é copiada para a RAM do applet e retornada em partes.
5. Imitar o eUICC – O par de chaves roubadas + certificados permite que o atacante se autentique em qualquer servidor RSP como um cartão legítimo (o vínculo EID ainda pode ser necessário para alguns operadores).
6. Baixar e modificar perfis – Perfis em texto simples contêm campos altamente sensíveis, como OPc, AMF, chaves OTA e até mesmo applets adicionais. O atacante pode:

• Clonar um perfil para um segundo eUICC (sequestro de voz/SMS);
• Patch aplicações Java Card (por exemplo, inserir spyware STK) antes de re-enviar;
• Extrair segredos do operador para abuso em larga escala.

Demonstração de Clonagem / Sequestro

Instalar o mesmo perfil em PHONE A e PHONE B resulta no Centro de Comutação Móvel roteando o tráfego de entrada para qual dispositivo se registrou mais recentemente. Uma sessão de interceptação de SMS 2FA do Gmail é suficiente para contornar a MFA para a vítima.

Conjunto de Ferramentas de Teste e Exploração Automatizado

Os pesquisadores lançaram uma ferramenta interna com um comando bsc (Basic Security Check) que mostra imediatamente se uma VM Java Card é 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 enviados com o framework:

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

Mitigações

1. Verificação de byte-code no cartão – impor rastreamento completo de controle de fluxo e tipo de fluxo de dados em vez de apenas o topo da pilha.
2. Ocultar cabeçalho de array – colocar length fora dos campos de objeto sobrepostos.
3. Endurecer a política de chaves de RAM – nunca enviar perfis com chaves públicas; desativar INSTALL em perfis de teste (abordado no GSMA TS.48 v7).
4. Heurísticas do lado do servidor RSP – limitar a taxa de downloads de perfis por EID, monitorar anomalias geográficas, validar a frescura do certificado.

Lista de Verificação Rápida para Pentesters

• Consultar GET DATA DF1F – string de firmware vulnerável ECu10.13 indica Kigen.
• Verificar se as chaves de RAM são conhecidas ‑> tentar OTA INSTALL/LOAD.
• Após a instalação do applet, forçar a leitura de um tipo primitivo simples (objarrconfusion).
• Tentar ler chaves privadas do Domínio de Segurança – sucesso = comprometimento total.

Referências

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