eSIM / Java Card VM Exploitation

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Przegląd

Embedded SIMs (eSIMs) są zaimplementowane jako Embedded UICC (eUICC) smart-karty, które uruchamiają Java Card Virtual Machine (JC VM) nad secure element. Ponieważ profile i applet’y mogą być dostarczane over-the-air (OTA) przez Remote SIM Provisioning (RSP), każda wada związana z bezpieczeństwem pamięci w JC VM natychmiast staje się prymitywem zdalnego wykonania kodu wewnątrz najbardziej uprzywilejowanego komponentu urządzenia.

Ta strona opisuje rzeczywiste całkowite przejęcie eUICC Kigen (Infineon SLC37 ESA1M2, ARM SC300) spowodowane brakiem kontroli typu w bajtkodach getfield i putfield. Ta sama technika może być użyta przeciwko innym dostawcom, którzy pomijają weryfikację byte-code na karcie.

Powierzchnia ataku

  1. Remote Application Management (RAM) eSIM profile mogą osadzać dowolne applet’y Java Card. Provisioning wykonywany jest za pomocą standardowych APDUs, które można tunelować przez SMS-PP (Short Message Service Point-to-Point) lub HTTPS. Jeśli atakujący posiada (lub wykraść) RAM keys dla profilu, może zdalnie wykonać INSTALL/LOAD złośliwego appletu.
  2. Java Card byte-code execution Po instalacji applet wykonuje się wewnątrz VM. Brakujące kontrole w czasie wykonywania umożliwiają korupcję pamięci.

Zmiany w ekosystemie 2024–2025

  • GSMA TS.48 v7.0 (18 Jun 2025) usunął publiczne zestawy kluczy RAM z Generic Test Profile i blokuje INSTALL, chyba że dostarczone są zrandomizowane klucze; zbuforowane profile v≤6 wciąż ujawniają statyczne RAM keys i pozostają podatne.
  • GSMA AN‑2025‑07 (09 Jul 2025) rekomenduje on-card bytecode verification; większość eUICC wciąż pomija pełną weryfikację, więc błędy w VM pozostają osiągalne po instalacji appletu.
  • Kigen OTA hardening (Jul 2025) blokuje ładowanie appletów, gdy aktywne są legacy TS.48 test profiles i dodaje runtime checks, ale niezałatane urządzenia pozostają podatne.

The Type-Confusion Primitive

getfield / putfield powinny operować tylko na object references. W eUICC Kigen instrukcje nigdy nie weryfikują, czy operand na stosie jest referencją object czy array. Ponieważ słowo array.length znajduje się dokładnie pod tym samym offsetem co pierwsze pole instancji normalnego obiektu, atakujący może:

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

Prymityw zapewnia arbitrary read / write w przestrzeni adresowej eUICC – wystarczająco, by zrzucić unikatowy dla urządzenia prywatny klucz ECC, który uwierzytelnia kartę w ekosystemie GSMA.

End-to-End Exploitation Workflow

  1. Enumeracja firmware’u – Użyj nieudokumentowanego elementu GET DATA DF1F:
80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
  1. Zainstaluj złośliwy applet OTA – Wykorzystaj publicznie znane klucze TS.48 Generic Test Profile i wyślij fragmenty SMS-PP transportujące plik CAP (LOAD) a następnie INSTALL:
// simplified APDU chain
80 E6 02 00 <data>   // LOAD (block n)
80 E6 0C 00 <data>   // INSTALL for load
  1. Wywołaj type-confusion – Po wybraniu appletu wykonuje write-what-where, aby przejąć tabelę wskaźników i leak pamięci przez normalne odpowiedzi APDU.
  2. Wyodrębnij klucz certyfikatu GSMA – Prywatny klucz EC jest kopiowany do RAM appletu i zwracany w fragmentach.
  3. Podszyj się pod eUICC – Ukradziona para kluczy i certyfikaty pozwalają atakującemu uwierzytelnić się do dowolnego RSP servera jako legalna karta (dla niektórych operatorów może być nadal wymagane powiązanie EID).
  4. Pobierz i modyfikuj profile – Profile w postaci plaintext zawierają wysoce wrażliwe pola takie jak OPc, AMF, OTA keys i nawet dodatkowe applety. Atakujący może:
  • Sklonować profil na drugi eUICC (przejęcie połączeń/SMS);
  • Załatać aplikacje Java Card (np. wstawić STK spyware) przed ponownym przesłaniem;
  • Wyodrębnić sekrety operatora w celu nadużyć na dużą skalę.

Cloning / Hijacking Demonstration

Zainstalowanie tego samego profilu na PHONE A i PHONE B powoduje, że Mobile Switching Centre kieruje ruch przychodzący do urządzenia, które zarejestrowało się ostatnio. Jedna sesja przechwycenia Gmail 2FA SMS wystarczy, by obejść MFA ofiary.

Automated Test & Exploit Toolkit

Badacze opublikowali wewnętrzne narzędzie z komendą bsc (Basic Security Check), która natychmiast pokazuje, czy Java Card VM jest podatna:

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 dostarczane z frameworkiem:

  • introspector – full VM and memory explorer (~1.7 MB Java)
  • security-test – generic verification bypass applet (~150 KB)
  • exploit – 100% niezawodne przejęcie Kigen eUICC (~72 KB)

Środki zaradcze

  1. Weryfikacja byte-code na karcie – wymusić pełne śledzenie typów dla przepływu sterowania i przepływu danych zamiast tylko topu stosu.
  2. Ukryć nagłówek tablicy – umieścić length poza nakładającymi się polami obiektów.
  3. Zaostrzyć politykę kluczy RAM – nigdy nie wysyłać profili z kluczami publicznymi; wyłączyć INSTALL w profilach testowych (TS.48 v7 usuwa RAM keysets).
  4. Heurystyki po stronie serwera RSP – ograniczyć tempo pobrań profili na EID, monitorować anomalie geograficzne, weryfikować aktualność certyfikatów.
  5. Trzymać urządzenia z dala od starych profili testowych – zastosować OTA z lipca 2025, które blokuje ładowanie apletów z TS.48 v≤6 lub usunąć profil testowy z obrazów fabrycznych.

Szybka lista kontrolna dla Pentesters

  • Sprawdź GET DATA DF1F – podatny ciąg firmware ECu10.13 wskazuje na Kigen.
  • Przeanalizuj załadowane profile: profile testowe TS.48 ze statycznymi RAM keys (v≤6) są bezpośrednio wykorzystywalne; v7 bez RAM keys wymaga new key leak.
  • Sprawdź, czy RAM keys są znane ‑> spróbuj OTA INSTALL/LOAD.
  • Po instalacji apletu, brute-force prosty cast primitive (objarrconfusion).
  • Spróbuj odczytać prywatne klucze Security Domain – sukces = pełne przejęcie.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks