eSIM security

src/SUMMARY.md

@@ -76,6 +76,7 @@
 # 🧙‍♂️ Generic Hacking
 
 - [Brute Force - CheatSheet](generic-hacking/brute-force.md)
+- [Esim Javacard Exploitation](generic-hacking/esim-javacard-exploitation.md)
 - [Exfiltration](generic-hacking/exfiltration.md)
 - [Reverse Shells (Linux, Windows, MSFVenom)](generic-hacking/reverse-shells/README.md)
   - [MSFVenom - CheatSheet](generic-hacking/reverse-shells/msfvenom.md)

src/generic-hacking/esim-javacard-exploitation.md

@@ -0,0 +1,89 @@
+# eSIM / Java Card VM Exploitation
+
+{{#include ../banners/hacktricks-training.md}}
+
+## Overview
+Embedded SIMs (eSIMs) are implemented as **Embedded UICC (eUICC)** smart-cards that run a **Java Card Virtual Machine (JC VM)** on top of a secure element.  
+Because profiles and applets can be provisioned *over-the-air* (OTA) via Remote SIM Provisioning (RSP), any memory-safety flaw inside the JC VM instantly becomes a remote code-execution primitive **inside the most privileged component of the handset**.
+
+This page describes a real-world full compromise of Kigen’s eUICC (Infineon SLC37 ESA1M2, ARM SC300) caused by missing type-safety checks in the `getfield` and `putfield` bytecodes.  The same technique can be re-used against other vendors that omit on-card byte-code verification.
+
+## Attack Surface
+1. **Remote Application Management (RAM)**  
+   eSIM profiles may embed arbitrary Java Card applets.  Provisioning is performed with standard APDUs that can be tunnelled through SMS-PP (Short Message Service Point-to-Point) or HTTPS.  If an attacker owns (or steals) the **RAM keys** for a profile, they can `INSTALL`/`LOAD` a malicious applet remotely.
+2. **Java Card byte-code execution**  
+   After installation, the applet executes inside the VM.  Missing run-time checks allow memory corruption.
+
+## The Type-Confusion Primitive
+`getfield` / `putfield` are supposed to operate only on **object references**.  In Kigen eUICC the instructions never validate whether the operand on the stack is an *object* or an *array* reference.  Because an `array.length` word lives at the exact same offset as the first instance field of a normal object, an attacker can:
+
+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.
+
+```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 ...
+```
+The primitive provides **arbitrary read / write** in the eUICC address space – enough to dump the device-unique ECC private key that authenticates the card to the GSMA ecosystem.
+
+## End-to-End Exploitation Workflow
+1. **Enumerate firmware** – Use undocumented `GET DATA` item `DF1F`:
+   ```
+   80 CA DF 1F 00   // → "ECu10.13" (vulnerable)
+   ```
+2. **Install malicious applet OTA** – Abuse publicly-known keys of the TS.48 Generic Test Profile and push SMS-PP fragments that transport the CAP file (`LOAD`) followed by an `INSTALL`:
+   ```
+   // simplified APDU chain
+   80 E6 02 00 <data>   // LOAD (block n)
+   80 E6 0C 00 <data>   // INSTALL for load
+   ```
+3. **Trigger type-confusion** – When the applet is selected it performs the write-what-where to hijack a pointer table and leak memory through normal APDU responses.
+4. **Extract GSMA certificate key** – Private EC key is copied to the applet’s RAM and returned in chunks.
+5. **Impersonate the eUICC** – The stolen key pair + certificates let the attacker authenticate to *any* RSP server as a legitimate card (EID binding may still be required for some operators).
+6. **Download and modify profiles** – Plaintext profiles contain highly sensitive fields such as `OPc`, `AMF`, OTA keys and even additional applets.  The attacker can:
+   * Clone a profile to a second eUICC (voice/SMS hijack);
+   * Patch Java Card applications (e.g. insert STK spyware) before re-uploading;
+   * Extract operator secrets for large-scale abuse.
+
+## Cloning / Hijacking Demonstration
+Installing the same profile on **PHONE A** and **PHONE B** results in the Mobile Switching Centre routing incoming traffic to whichever device most recently registered.  One session of Gmail 2FA SMS interception is enough to bypass MFA for the victim.
+
+## Automated Test & Exploit Toolkit
+The researchers released an internal tool with a `bsc` (*Basic Security Check*) command that immediately shows whether a Java Card VM is 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]
+```
+Modules shipped with the framework:
+* `introspector` – full VM and memory explorer (~1.7 MB Java)
+* `security-test` – generic verification bypass applet (~150 KB)
+* `exploit`       – 100 % reliable Kigen eUICC compromise (~72 KB)
+
+## Mitigations
+1. **On-card byte-code verification** – enforce full control-flow & data-flow type tracking instead of stack-top only.
+2. **Hide array header** – place `length` outside of overlapping object fields.
+3. **Harden RAM keys policy** – never ship profiles with public keys; disable `INSTALL` in test profiles (addressed in GSMA TS.48 v7).
+4. **RSP server side heuristics** – rate-limit profile downloads per EID, monitor geographic anomalies, validate certificate freshness.
+
+## Quick Checklist for Pentesters
+* Query `GET DATA DF1F` – vulnerable firmware string `ECu10.13` indicates Kigen.
+* Check if RAM keys are known ‑> attempt OTA `INSTALL`/`LOAD`.
+* After applet installation, brute-force simple cast primitive (`objarrconfusion`).
+* Try to read Security Domain private keys – success = full compromise.
+
+## References
+- [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}}