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

eSIM / Java Card VM Exploitation

{{#include ../banners/hacktricks-training.md}}

Overview

Embedded SIMs (eSIMs) को Embedded UICC (eUICC) स्मार्ट-कार्ड के रूप में लागू किया गया है जो एक सुरक्षित तत्व के शीर्ष पर Java Card Virtual Machine (JC VM) चलाते हैं। चूंकि प्रोफाइल और एप्लेट्स को Remote SIM Provisioning (RSP) के माध्यम से over-the-air (OTA) प्रावधानित किया जा सकता है, JC VM के अंदर कोई भी मेमोरी-सुरक्षा दोष तुरंत हैंडसेट के सबसे विशेषाधिकार प्राप्त घटक के अंदर एक दूरस्थ कोड-निष्पादन प्राइमिटिव बन जाता है।

यह पृष्ठ Kigen के eUICC (Infineon SLC37 ESA1M2, ARM SC300) का एक वास्तविक दुनिया का पूर्ण समझौता वर्णित करता है जो getfield और putfield बाइटकोड में प्रकार-सुरक्षा जांच की कमी के कारण हुआ। समान तकनीक का उपयोग अन्य विक्रेताओं के खिलाफ किया जा सकता है जो कार्ड-पर बाइट-कोड सत्यापन को छोड़ देते हैं।

Attack Surface

1. Remote Application Management (RAM) eSIM प्रोफाइल मनमाने Java Card एप्लेट्स को एम्बेड कर सकते हैं। प्रावधान मानक APDUs के साथ किया जाता है जिन्हें SMS-PP (Short Message Service Point-to-Point) या HTTPS के माध्यम से टनल किया जा सकता है। यदि एक हमलावर के पास किसी प्रोफाइल के लिए RAM keys हैं (या उन्हें चुरा लेता है), तो वे एक दुर्भावनापूर्ण एप्लेट को दूरस्थ रूप से INSTALL/LOAD कर सकते हैं।
2. Java Card byte-code execution स्थापना के बाद, एप्लेट VM के अंदर निष्पादित होता है। रन-टाइम जांच की कमी मेमोरी भ्रष्टाचार की अनुमति देती है।

The Type-Confusion Primitive

getfield / putfield को केवल ऑब्जेक्ट संदर्भों पर काम करने के लिए माना गया है। Kigen eUICC में निर्देश कभी यह सत्यापित नहीं करते कि स्टैक पर ऑपरेन्ड एक ऑब्जेक्ट है या एक ऐरे संदर्भ। चूंकि एक array.length शब्द एक सामान्य ऑब्जेक्ट के पहले उदाहरण क्षेत्र के समान ही ऑफसेट पर रहता है, एक हमलावर कर सकता है:

1. एक बाइट-ऐरे बनाएँ byte[] buf = new byte[0x100];
2. इसे Object o = (Object)buf; में कास्ट करें।
3. किसी भी 16-बिट मान को एक निकटवर्ती ऑब्जेक्ट के अंदर ओवरराइट करने के लिए putfield का उपयोग करें (जिसमें VTABLE / ptr अनुवाद प्रविष्टियाँ शामिल हैं)।
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 पते की जगह में - जो GSMA पारिस्थितिकी तंत्र के लिए कार्ड को प्रमाणित करने वाले डिवाइस-विशिष्ट ECC निजी कुंजी को डंप करने के लिए पर्याप्त है।

एंड-टू-एंड एक्सप्लॉइटेशन वर्कफ़्लो

1. फर्मवेयर की गणना करें – प्रलेखित नहीं किए गए GET DATA आइटम DF1F का उपयोग करें:

80 CA DF 1F 00   // → "ECu10.13" (कमजोर)

2. दुष्ट एप्लेट OTA स्थापित करें – TS.48 सामान्य परीक्षण प्रोफ़ाइल की सार्वजनिक रूप से ज्ञात कुंजियों का दुरुपयोग करें और 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 स्पाइवेयर डालें);
• बड़े पैमाने पर दुरुपयोग के लिए ऑपरेटर रहस्यों को निकालें।

क्लोनिंग / हाईजैकिंग प्रदर्शन

फोन A और फोन B पर समान प्रोफ़ाइल स्थापित करने से मोबाइल स्विचिंग सेंटर आने वाले ट्रैफ़िक को उस डिवाइस पर रूट करता है जो हाल ही में पंजीकृत हुआ है। एक सत्र का Gmail 2FA SMS इंटरसेप्शन पीड़ित के लिए MFA को बायपास करने के लिए पर्याप्त है।

स्वचालित परीक्षण और शोषण टूलकिट

शोधकर्ताओं ने एक आंतरिक उपकरण जारी किया जिसमें bsc (बेसिक सिक्योरिटी चेक) कमांड है जो तुरंत दिखाता है कि क्या एक 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]

Modules shipped with the framework:

• introspector – पूर्ण VM और मेमोरी एक्सप्लोरर (~1.7 MB Java)
• security-test – सामान्य सत्यापन बायपास एप्लेट (~150 KB)
• exploit – 100 % विश्वसनीय Kigen eUICC समझौता (~72 KB)

Mitigations

1. On-card byte-code verification – स्टैक-टॉप केवल के बजाय पूर्ण नियंत्रण-प्रवाह और डेटा-प्रवाह प्रकार ट्रैकिंग को लागू करें।
2. Hide array header – length को ओवरलैपिंग ऑब्जेक्ट फ़ील्ड के बाहर रखें।
3. Harden RAM keys policy – कभी भी सार्वजनिक कुंजी के साथ प्रोफाइल न भेजें; परीक्षण प्रोफाइल में INSTALL को अक्षम करें (GSMA TS.48 v7 में संबोधित)।
4. RSP server side heuristics – EID के अनुसार प्रोफाइल डाउनलोड की दर-सीमा, भौगोलिक विसंगतियों की निगरानी करें, प्रमाणपत्र की ताजगी को मान्य करें।

Quick Checklist for Pentesters

• Query GET DATA DF1F – कमजोर फर्मवेयर स्ट्रिंग ECu10.13 Kigen को इंगित करती है।
• जांचें कि RAM कुंजी ज्ञात हैं ‑> OTA INSTALL/LOAD का प्रयास करें।
• एप्लेट स्थापना के बाद, सरल कास्ट प्रिमिटिव (objarrconfusion) का ब्रूट-फोर्स करें।
• सुरक्षा डोमेन निजी कुंजी पढ़ने का प्रयास करें – सफलता = पूर्ण समझौता।

References

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

{{#include ../banners/hacktricks-training.md}}