eSIM / Java Card VM Exploitation

Огляд

Вбудовані SIM-картки (eSIM) реалізовані як Embedded UICC (eUICC) смарт-картки, які працюють на Java Card Virtual Machine (JC VM) поверх захищеного елемента. Оскільки профілі та аплети можуть бути надані по повітрю (OTA) через Remote SIM Provisioning (RSP), будь-яка помилка безпеки пам'яті всередині JC VM миттєво стає примітивом віддаленого виконання коду всередині найпривілейованішого компонента пристрою.

Ця сторінка описує реальний випадок повного компромісу eUICC Kigen (Infineon SLC37 ESA1M2, ARM SC300), викликаного відсутністю перевірок типу в байт-кодах getfield та putfield. Така ж техніка може бути повторно використана проти інших постачальників, які пропускають верифікацію байт-коду на картці.

Поверхня атаки

1. Управління віддаленими додатками (RAM) Профілі eSIM можуть вбудовувати довільні Java Card аплети. Надання здійснюється за допомогою стандартних APDU, які можуть бути тунельовані через SMS-PP (Short Message Service Point-to-Point) або HTTPS. Якщо зловмисник володіє (або викрав) ключами RAM для профілю, він може INSTALL/LOAD шкідливий аплет віддалено.
2. Виконання байт-коду Java Card Після установки аплет виконується всередині VM. Відсутність перевірок під час виконання дозволяє корупцію пам'яті.

Примітив плутанини типів

getfield / putfield повинні працювати лише з посиланнями на об'єкти. У Kigen eUICC інструкції ніколи не перевіряють, чи є операнд на стеку об'єктом чи посиланням на масив. Оскільки слово array.length знаходиться на точно такому ж зсуві, як і перше поле екземпляра звичайного об'єкта, зловмисник може:

1. Створити масив байтів byte[] buf = new byte[0x100];
2. Привести його до Object o = (Object)buf;
3. Використати putfield, щоб перезаписати будь-яке 16-бітне значення всередині сусіднього об'єкта (включаючи VTABLE / записи трансляції вказівників).
4. Використати getfield, щоб прочитати довільну пам'ять після захоплення внутрішніх вказівників.

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

Примітив забезпечує произвольне читання / запис в адресному просторі eUICC – достатньо, щоб скинути унікальний ECC приватний ключ пристрою, який аутентифікує картку в екосистемі GSMA.

Процес експлуатації від початку до кінця

1. Перерахувати прошивку – Використовуйте не задокументований елемент GET DATA DF1F:

80 CA DF 1F 00   // → "ECu10.13" (вразливий)

2. Встановити шкідливий аплет OTA – Зловживайте публічно відомими ключами профілю TS.48 Generic Test Profile і надішліть фрагменти SMS-PP, які транспортують файл CAP (LOAD), за яким слідує INSTALL:

// спрощений ланцюг APDU
80 E6 02 00 <data>   // LOAD (блок n)
80 E6 0C 00 <data>   // INSTALL для завантаження

3. Викликати плутанину типів – Коли аплет вибрано, він виконує запис-що-де, щоб захопити таблицю вказівників і витікати пам'ять через звичайні відповіді APDU.
4. Витягти ключ сертифіката GSMA – Приватний EC ключ копіюється в RAM аплета і повертається частинами.
5. Видати себе за eUICC – Вкрадені ключова пара + сертифікати дозволяють зловмиснику аутентифікуватися на будь-якому RSP сервері як легітимна картка (може знадобитися зв'язування EID для деяких операторів).
6. Завантажити та змінити профілі – Профілі у відкритому тексті містять надзвичайно чутливі поля, такі як OPc, AMF, OTA ключі та навіть додаткові аплети. Зловмисник може:

• Клонувати профіль на другий eUICC (викрадення голосу/SMS);
• Патчити Java Card додатки (наприклад, вставити STK шпигунське ПЗ) перед повторним завантаженням;
• Витягувати секрети оператора для масштабного зловживання.

Демонстрація клонування / викрадення

Встановлення одного й того ж профілю на PHONE A та PHONE B призводить до того, що Мобільний комутаційний центр маршрутизує вхідний трафік на той пристрій, який останнім зареєструвався. Однієї сесії перехоплення SMS 2FA Gmail достатньо, щоб обійти MFA для жертви.

Автоматизований набір тестів та експлуатаційних інструментів

Дослідники випустили внутрішній інструмент з командою bsc (Basic Security Check), яка негайно показує, чи вразлива Java Card VM:

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]

Модулі, що постачаються з фреймворком:

• introspector – повний дослідник VM та пам'яті (~1.7 MB Java)
• security-test – загальний аплет для перевірки обходу (~150 KB)
• exploit – 100 % надійний компроміс Kigen eUICC (~72 KB)

Заходи пом'якшення

1. Перевірка байт-коду на карті – забезпечити повний контроль за потоком та типами даних замість лише верхівки стеку.
2. Сховати заголовок масиву – розмістити length поза перекриваючими полями об'єкта.
3. Посилити політику ключів RAM – ніколи не постачати профілі з публічними ключами; вимкнути INSTALL у тестових профілях (обговорено в GSMA TS.48 v7).
4. Геуристики на стороні сервера RSP – обмежити швидкість завантаження профілів за EID, моніторити географічні аномалії, перевіряти свіжість сертифікатів.

Швидкий контрольний список для пентестерів

• Запит GET DATA DF1F – вразливий рядок прошивки ECu10.13 вказує на Kigen.
• Перевірте, чи відомі ключі RAM ‑> спробуйте OTA INSTALL/LOAD.
• Після встановлення аплета, брутфорс простого примітиву перетворення (objarrconfusion).
• Спробуйте прочитати приватні ключі безпеки домену – успіх = повний компроміс.

Посилання

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