eSIM / Java Card VM Exploitation

Reading time: 6 minutes

Overview

Wbudowane karty SIM (eSIM) są implementowane jako Embedded UICC (eUICC), które działają na Java Card Virtual Machine (JC VM) na secure elemencie. Ponieważ profile i aplety mogą być dostarczane over-the-air (OTA) za pomocą Remote SIM Provisioning (RSP), każda wada związana z bezpieczeństwem pamięci wewnątrz JC VM natychmiast staje się zdalnym prymitywem wykonania kodu wewnątrz najbardziej uprzywilejowanego komponentu urządzenia.

Ta strona opisuje rzeczywiste pełne kompromitacje eUICC Kigen (Infineon SLC37 ESA1M2, ARM SC300) spowodowane brakiem kontroli bezpieczeństwa typów w bajtkodach getfield i putfield. Ta sama technika może być ponownie użyta przeciwko innym dostawcom, którzy pomijają weryfikację bajtkodu na karcie.

Attack Surface

1. Remote Application Management (RAM) Profile eSIM mogą zawierać dowolne aplety Java Card. Provisioning odbywa się za pomocą standardowych APDU, które mogą być tunelowane przez SMS-PP (Short Message Service Point-to-Point) lub HTTPS. Jeśli atakujący posiada (lub ukradnie) klucze RAM dla profilu, może zdalnie INSTALL/LOAD złośliwy aplet.
2. Wykonanie bajtkodu Java Card Po zainstalowaniu, aplet wykonuje się wewnątrz VM. Brak kontroli w czasie wykonywania pozwala na uszkodzenie pamięci.

The Type-Confusion Primitive

getfield / putfield powinny działać tylko na referencjach obiektów. W eUICC Kigen instrukcje nigdy nie weryfikują, czy operand na stosie jest referencją obiektu czy tablicy. Ponieważ słowo array.length znajduje się w dokładnie tym samym przesunięciu co pierwsze pole instancji normalnego obiektu, atakujący może:

1. Utworzyć tablicę bajtów byte[] buf = new byte[0x100];
2. Rzucić ją na Object o = (Object)buf;
3. Użyć putfield, aby nadpisać dowolną 16-bitową wartość wewnątrz sąsiedniego obiektu (w tym wpisy VTABLE / translacji wskaźników).
4. Użyć getfield, aby odczytać dowolną pamięć, gdy wewnętrzne wskaźniki zostaną przejęte.

// 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 ...

Prymityw zapewnia dowolne odczyty / zapisy w przestrzeni adresowej eUICC – wystarczająco, aby zrzucić unikalny dla urządzenia klucz prywatny ECC, który autoryzuje kartę w ekosystemie GSMA.

Workflow Eksploatacji End-to-End

1. Enumeracja oprogramowania układowego – Użyj nieudokumentowanego elementu GET DATA DF1F:

80 CA DF 1F 00   // → "ECu10.13" (wrażliwy)

2. Instalacja złośliwego apletu OTA – Wykorzystaj publicznie znane klucze profilu testowego TS.48 i przesyłaj fragmenty SMS-PP, które transportują plik CAP (LOAD), a następnie INSTALL:

// uproszczony łańcuch APDU
80 E6 02 00 <data>   // LOAD (blok n)
80 E6 0C 00 <data>   // INSTALL dla załadunku

3. Wywołanie pomyłki typów – Gdy aplet jest wybierany, wykonuje zapis-co-gdzie, aby przejąć tabelę wskaźników i wyciekać pamięć przez normalne odpowiedzi APDU.
4. Ekstrakcja klucza certyfikatu GSMA – Prywatny klucz EC jest kopiowany do RAM apletu i zwracany w kawałkach.
5. Impersonacja eUICC – Sk stolen para kluczy + certyfikaty pozwalają atakującemu autoryzować się na dowolnym serwerze RSP jako legalna karta (powiązanie EID może być nadal wymagane dla niektórych operatorów).
6. Pobieranie i modyfikowanie profili – Profile w postaci jawnej zawierają wysoce wrażliwe pola, takie jak OPc, AMF, klucze OTA, a nawet dodatkowe aplety. Atakujący może:

• Skopiować profil na drugi eUICC (przechwycenie głosu/SMS);
• Zmodyfikować aplikacje Java Card (np. wstawić złośliwe oprogramowanie STK) przed ponownym przesłaniem;
• Ekstrahować sekrety operatora do masowego nadużycia.

Demonstracja Klonowania / Przechwytywania

Instalacja tego samego profilu na TELEFONIE A i TELEFONIE B skutkuje tym, że Centrum Przełączania Mobilnego kieruje przychodzący ruch do urządzenia, które ostatnio się zarejestrowało. Jedna sesja przechwytywania SMS 2FA Gmaila wystarczy, aby obejść MFA dla ofiary.

Zautomatyzowany Zestaw Narzędzi Testowych i Eksploatacyjnych

Badacze wydali wewnętrzne narzędzie z komendą bsc (Basic Security Check), która natychmiast pokazuje, czy maszyna wirtualna Java Card jest wrażliwa:

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]

Moduły dostarczone z frameworkiem:

• introspector – pełny eksplorator VM i pamięci (~1.7 MB Java)
• security-test – ogólny aplet weryfikacji obejścia (~150 KB)
• exploit – 100 % niezawodne kompromitowanie Kigen eUICC (~72 KB)

Mitigacje

1. Weryfikacja kodu bajtowego na karcie – wymuszaj pełne śledzenie przepływu kontrolnego i danych zamiast tylko na szczycie stosu.
2. Ukryj nagłówek tablicy – umieść length poza nakładającymi się polami obiektów.
3. Wzmocnij politykę kluczy RAM – nigdy nie dostarczaj profili z kluczami publicznymi; wyłącz INSTALL w profilach testowych (omówione w GSMA TS.48 v7).
4. Heurystyki po stronie serwera RSP – ogranicz pobieranie profili na EID, monitoruj anomalie geograficzne, weryfikuj świeżość certyfikatu.

Szybka lista kontrolna dla pentesterów

• Zapytaj GET DATA DF1F – podatny ciąg firmware ECu10.13 wskazuje na Kigen.
• Sprawdź, czy klucze RAM są znane ‑> spróbuj OTA INSTALL/LOAD.
• Po zainstalowaniu apletu, przeprowadź brute-force na prostym typie rzutowania (objarrconfusion).
• Spróbuj odczytać prywatne klucze Security Domain – sukces = pełne kompromitowanie.

Odniesienia

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