EvilParcel भेद्यता विश्लेषण

परिचय

अप्रैल के मध्य में, हमने Android.InfectionAds.1 ट्रोजन के बारे में समाचार प्रकाशित किया, जिसने एंड्रॉइड ओएस में कई महत्वपूर्ण कमजोरियों का फायदा उठाया। उनमें से एक - CVE-2017-13156 (जिसे जानूस के रूप में भी जाना जाता है) - अपने डिजिटल हस्ताक्षर को नुकसान पहुंचाए बिना एपीके फ़ाइलों को संक्रमित करने के लिए एक दुर्भावनापूर्ण प्रोग्राम की अनुमति देता है।

दूसरा CVE-2017-13315 है। यह ट्रोजन उन्नत विशेषाधिकार देता है, और यह स्वतंत्र रूप से अनुप्रयोगों को स्थापित और अनइंस्टॉल कर सकता है। Android.InfectionAds.1 का एक विस्तृत विश्लेषण हमारे वायरस लाइब्रेरी में उपलब्ध है, यह यहां पाया जा सकता है । हम भेद्यता CVE-2017-13315 पर अधिक विस्तार से ध्यान देंगे और देखें कि यह कैसा है।

CVE-2017-13315 कमजोरियों के समूह से संबंधित है जिसे सामान्य नाम EvilParcel प्राप्त हुआ था। वे एंड्रॉइड ओएस के विभिन्न सिस्टम कक्षाओं में पाए जाते हैं। अनुप्रयोगों और सिस्टम के बीच डेटा का आदान-प्रदान करते समय उत्तरार्द्ध में त्रुटियों के कारण, इस डेटा को बदलना संभव हो जाता है। दुर्भावनापूर्ण प्रोग्राम जो EvilParcel कमजोरियों का फायदा उठाते हैं वे उच्च विशेषाधिकार प्राप्त करते हैं और उनकी सहायता से निम्नलिखित कार्य कर सकते हैं:

• उपयोगकर्ता की पुष्टि के बिना किसी भी अनुमति के साथ एप्लिकेशन इंस्टॉल और अनइंस्टॉल करें;
• जब अन्य कमजोरियों के साथ संयोजन में उपयोग किया जाता है, तो डिवाइस पर इंस्टॉल किए गए प्रोग्रामों को संक्रमित करें और संक्रमित प्रतियों के साथ "स्वच्छ" मूल को बदलें;
• Android डिवाइस के लिए स्क्रीन लॉक कोड रीसेट करें
• Android डिवाइस लॉक स्क्रीन पिन रीसेट करें।

वर्तमान में इस प्रकार की 7 ज्ञात कमजोरियाँ हैं:

• अक्टूबर 2017 में प्रकाशित CVE-2017-0806 (गेटकीपर रिप्स वर्ग में त्रुटि);
• CVE-2017-13286 (अप्रैल 2018 में प्रकाशित, वर्ग आउटपुट त्रुटि में त्रुटि);
• अप्रैल 2018 में प्रकाशित CVE-2017-13287 (VerifyCredentialResponse वर्ग में त्रुटि);
• अप्रैल 2018 में प्रकाशित CVE-2017-13288 (PeriodicAdvertizingReport वर्ग में त्रुटि);
• अप्रैल 2018 में प्रकाशित CVE-2017-13289 (ParcelableRttResults वर्ग में बग);
• सीवीई-2017-13311 (स्पैरसेपिंगटेबल क्लास में बग), मई 2018 में प्रकाशित;
• CVE-2017-13315 (DcParamObject वर्ग में त्रुटि), मई 2018 में प्रकाशित।

सभी ने एंड्रॉइड ओएस संस्करण 5.0 - 8.1 पर चलने वाले उपकरणों को धमकी दी है कि मई 2018 और बाद में सुरक्षा अद्यतन स्थापित नहीं हैं।

EvilParcel कमजोरियों के लिए आवश्यक शर्तें

आइए देखें कि एविलपैरसेल कमजोरियां कैसे उत्पन्न होती हैं। सबसे पहले, हम एंड्रॉइड एप्लिकेशन की कुछ विशेषताओं को देखेंगे। एंड्रॉइड ओएस में, सभी प्रोग्राम एक-दूसरे के साथ, साथ ही ऑपरेटिंग सिस्टम के साथ, प्रकार की वस्तुओं को भेजते हैं और प्राप्त करते हैं। इन ऑब्जेक्ट्स में प्रकार बंडल के ऑब्जेक्ट के अंदर कुंजी-मूल्य वाले जोड़े की एक मनमानी संख्या हो सकती है।

आशय प्रेषित करते समय, बंडल वस्तु को पार्सल में लिपटे बाइट सरणी में परिवर्तित (क्रमबद्ध) किया जाता है, और जब धारावाहिक बंडल से कुंजियों और मूल्यों को पढ़ते हैं, तो यह स्वचालित रूप से deserialized होता है।

बंडल में, स्ट्रिंग कुंजी है, और मूल्य लगभग कुछ भी हो सकता है। उदाहरण के लिए, एक आदिम प्रकार, स्ट्रिंग, या कंटेनर जिसमें आदिम प्रकार या तार होते हैं। इसके अतिरिक्त, यह पार्सलेबल प्रकार की वस्तु हो सकती है।

इस प्रकार, बंडल में, आप किसी भी प्रकार के ऑब्जेक्ट को रख सकते हैं जो पार्सलेबल इंटरफ़ेस को लागू करता है। ऐसा करने के लिए, आपको ऑब्जेक्ट को क्रमबद्ध और डिसेरिज़लाइज़ करने के लिए writeToParcel () और createFromParcel () विधियों को लागू करना होगा।

एक अच्छे उदाहरण के रूप में, आइए एक सरल क्रमबद्ध बंडल बनाएं। आइए एक कोड लिखें जो तीन कुंजी-मूल्य वाले जोड़े को बंडल में रखता है और इसे क्रमबद्ध करता है:

बंडल डेमो = नया बंडल ();
डेमो.पुटस्ट्रिंग ("स्ट्रिंग", "हैलो, वर्ल्ड!");
डेमो.पुटइंट ("इंटेगर", 42);
Demo.putByteArray ("बाइटअरे", नई बाइट [] {1, 2, 3, 4, 5, 6, 7, 8});
पार्सल पार्सल = पार्सल.बॉटेन ();
parcel.writeBundle (डेमो);

इस कोड को निष्पादित करने के बाद, हमें निम्नलिखित फॉर्म का एक बंडल मिलता है:



चित्रा 1. एक क्रमबद्ध बंडल वस्तु की संरचना।

आइए बंडल क्रमांकन की निम्नलिखित विशेषताओं पर ध्यान दें:

• सभी कुंजी-मूल्य जोड़े एक के बाद एक लिखे गए हैं;
• प्रत्येक मूल्य से पहले इसके प्रकार का संकेत दिया जाता है (बाइट सरणी के लिए 13, एक पूर्णांक के लिए 1, एक स्ट्रिंग के लिए 0, और इसी तरह);
• चर लंबाई के डेटा से पहले, उनके आकार का संकेत दिया जाता है (स्ट्रिंग के लिए लंबाई, सरणी के लिए बाइट्स की संख्या);
• सभी मान 4 बाइट्स के संरेखण के साथ लिखे गए हैं।

इस तथ्य के कारण कि बंडल में सभी चाबियाँ और मूल्य क्रमिक रूप से लिखे गए हैं, जब एक कुंजी या किसी अनुक्रमित बंडल ऑब्जेक्ट के मूल्य तक पहुंच होती है, तो बाद वाले को पूरी तरह से deserialized किया जाता है, जिसमें इसमें शामिल सभी पार्सलेबल ऑब्जेक्ट्स को इनिशियलाइज़ करना शामिल है।

ऐसा लगता है, क्या समस्या हो सकती है? और यह है कि कुछ सिस्टम क्लासेस में जो Parcelable को कार्यान्वित करते हैं, createFromParcel () और writeToParcel () विधियाँ त्रुटियों का सामना कर सकती हैं। इन वर्गों में, CreateFromParcel () विधि में पढ़ी जाने वाली बाइट्स की संख्या राइटटॉर्परसेल () विधि में लिखी गई बाइट्स की संख्या से भिन्न होगी। यदि आप बंडल के अंदर इस तरह के एक वर्ग की एक वस्तु रखते हैं, तो बंडल के अंदर की वस्तु की सीमा फिर से क्रमांकन के बाद बदल जाएगी। और यह वह जगह है जहां एविलपिलर्ल भेद्यता के शोषण की स्थितियां बनती हैं।

यहां एक समान त्रुटि वाले वर्ग का एक उदाहरण दिया गया है:

class Demo implements Parcelable { byte[] data; public Demo() { this.data = new byte[0]; } protected Demo(Parcel in) { int length = in.readInt(); data = new byte[length]; if (length > 0) { in.readByteArray(data); } } public static final Creator<Demo> CREATOR = new Creator<Demo>() { @Override public Demo createFromParcel(Parcel in) { return new Demo(in); } }; @Override public void writeToParcel(Parcel parcel, int i) { parcel.writeInt(data.length); parcel.writeByteArray(data); } } 

यदि डेटा सरणी का आकार 0 है, तो createFromParcel () में एक ऑब्जेक्ट बनाते समय एक int (4 बाइट्स) पढ़ा जाएगा, और दो int (8 बाइट्स) writeToParcel () में लिखे जाएंगे। पहला इंट राइट लिखने के लिए एक स्पष्ट कॉल में लिखा जाएगा। दूसरा इंट लिखा जाएगा जब राइटबायरे () को कहा जाता है, क्योंकि इसकी लंबाई हमेशा पार्सल से पहले सरणी के लिए लिखी जाती है (चित्र 1 देखें)।

डेटा सरणी का आकार 0 होने पर स्थितियाँ दुर्लभ हैं। लेकिन जब ऐसा होता है, तब भी कार्यक्रम तब भी काम करना जारी रखता है जब एक समय में केवल एक ही वस्तु धारावाहिक रूप में प्रसारित होती है (हमारे उदाहरण में, डेमो ऑब्जेक्ट)। इसलिए, ऐसी त्रुटियां, एक नियम के रूप में, किसी का ध्यान नहीं जाता है।

अब एक डेमो ऑब्जेक्ट को बंडल में शून्य सरणी लंबाई के साथ रखने का प्रयास करते हैं:


चित्रा 2. बंडल में एक शून्य सरणी लंबाई के साथ एक डेमो ऑब्जेक्ट जोड़ने का परिणाम है।

हम वस्तु को क्रमबद्ध करते हैं:


चित्र 3. क्रमांकन के बाद बंडल वस्तु।

आइए इसे निष्क्रिय करने का प्रयास करें:


चित्रा 4. बंडल ऑब्जेक्ट को डिसेररलाइज़ करने के बाद।

परिणाम क्या है? एक पार्सल स्निपेट पर विचार करें:


चित्रा 5. बंडल के deserialization के बाद पार्सल संरचना।

आंकड़े 4 और 5 से, हम देखते हैं कि डीरिएरलाइजेशन के दौरान, एक इंट को पहले लिखे गए दो के बजाय क्रिएटफ्रॉमसेल विधि में पढ़ा गया था। इसलिए, बंडल से बाद के सभी मान सही से नहीं पढ़े गए थे। 0x60 पते पर मान 0x60 अगली कुंजी की लंबाई के रूप में पढ़ा गया था। और 0x64 पते पर 0x1 का मान एक कुंजी के रूप में पढ़ा गया था। इस स्थिति में, 0x68 पर मान 0x31 मान मान के प्रकार के रूप में पढ़ा गया था। पार्सल में कोई मान नहीं है जिसका प्रकार 0x31 है, इसलिए readFromParcel () ने ईमानदारी से एक त्रुटि (अपवाद) की सूचना दी।

यह व्यवहार में कैसे इस्तेमाल किया जा सकता है और एक भेद्यता बन सकता है? चलो देखते हैं! पार्सेबल सिस्टम क्लासेस में ऊपर वर्णित त्रुटि आपको बंडल के निर्माण की अनुमति देती है, जो पहले और दोहराया विवरण के दौरान भिन्न हो सकती है। इसे प्रदर्शित करने के लिए, पिछले उदाहरण को संशोधित करें:

 Parcel data = Parcel.obtain(); data.writeInt(3); // 3 entries data.writeString("vuln_class"); data.writeInt(4); // value is Parcelable data.writeString("com.drweb.testbundlemismatch.Demo"); data.writeInt(0); // data.length data.writeInt(1); // key length -> key value data.writeInt(6); // key value -> value is long data.writeInt(0xD); // value is bytearray -> low(long) data.writeInt(-1); // bytearray length dummy -> high(long) int startPos = data.dataPosition(); data.writeString("hidden"); // bytearray data -> hidden key data.writeInt(0); // value is string data.writeString("Hi there"); // hidden value int endPos = data.dataPosition(); int triggerLen = endPos - startPos; data.setDataPosition(startPos - 4); data.writeInt(triggerLen); // overwrite dummy value with the real value data.setDataPosition(endPos); data.writeString("A padding"); data.writeInt(0); // value is string data.writeString("to match pair count"); int length = data.dataSize(); Parcel bndl = Parcel.obtain(); bndl.writeInt(length); bndl.writeInt(0x4C444E42); // bundle magic bndl.appendFrom(data, 0, length); bndl.setDataPosition(0); 

यह कोड एक अनुक्रमिक बंडल बनाता है जिसमें एक कमजोर वर्ग होता है। आइए इस कोड को निष्पादित करने के परिणाम को देखें:


चित्रा 6. एक कमजोर वर्ग के साथ एक बंडल बनाना।

पहले deserialization के बाद, इस बंडल में निम्नलिखित कुंजियाँ होंगी:


चित्रा 7. एक कमजोर वर्ग के साथ एक बंडल को डिसर्विलाइज़ करने का परिणाम।

अब फिर से परिणामी बंडल को क्रमबद्ध करें, फिर इसे फिर से रंग दें और कुंजियों की सूची देखें:


चित्रा 8. पुन: क्रमांकन और एक कमजोर वर्ग के साथ एक बंडल के deserialization के परिणाम।

हम क्या देखते हैं? छिपी हुई कुंजी (स्ट्रिंग मान "हाय वहाँ!") बंडल में दिखाई दी, जो पहले नहीं थी। ऐसा क्यों हुआ, यह समझने के लिए इस बंडल के पार्सल स्निपेट पर विचार करें:


चित्रा 9. बंडल के पार्सल संरचना दो क्रमिक-डिसेरिएलाइज़ेशन चक्रों के बाद कमजोर वर्ग के साथ।

यहाँ EvilParcel कमजोरियों का सार अधिक स्पष्ट हो जाता है। एक विशेष रूप से गठित बंडल बनाना संभव है जिसमें एक कमजोर वर्ग होगा। इस वर्ग की सीमाओं को बदलने से आपको इस बंडल में कोई भी वस्तु रखने की अनुमति मिलेगी - उदाहरण के लिए, इंटेंट, जो दूसरे डिसेरिएलाइजेशन के बाद ही बंडल में दिखाई देगा। यह ऑपरेटिंग सिस्टम के सुरक्षा तंत्र से आशय को छिपाना संभव बना देगा।

संचालन ईविलपर्सेल

Android.InfectionAds.1 ने CVE-2017-13315 का उपयोग करके संक्रमित डिवाइस के मालिक के हस्तक्षेप के बिना अपने दम पर प्रोग्राम इंस्टॉल और अनइंस्टॉल किया। लेकिन यह कैसे हो रहा है?

2013 में, त्रुटि 7699048 की भी खोज की गई, जिसे लॉन्च एनीवेयर कहीं भी कहा जाता है। इसने तीसरे पक्ष के आवेदन को अधिक विशेषाधिकार प्राप्त उपयोगकर्ता प्रणाली की ओर से मनमानी गतिविधियों को चलाने की अनुमति दी। नीचे दिए गए आरेख में इसकी क्रिया का तंत्र दिखाया गया है:


चित्रा 10. त्रुटि की योजना 7699048।

इस भेद्यता के साथ, एक शोषण एप्लिकेशन AccountAuthenticator सेवा को लागू कर सकता है, जिसे ऑपरेटिंग सिस्टम में नए खाते जोड़ने के लिए डिज़ाइन किया गया है। बग 7699048 के लिए धन्यवाद, शोषण स्थापित करने, अनइंस्टॉल करने, अनुप्रयोगों को बदलने, पिन या पैटर्न लॉक को रीसेट करने और अन्य अप्रिय चीजें करने के लिए गतिविधि चलाने में सक्षम है।

Google ने खाता प्रबंधक की मनमानी गतिविधि के शुभारंभ पर रोक लगाकर यह अंतर तय किया है। अब खाता प्रबंधक केवल उसी एप्लिकेशन से आने वाली गतिविधियों को शुरू करने की अनुमति देता है। ऐसा करने के लिए, यह उस प्रोग्राम के डिजिटल हस्ताक्षर की जांच करता है और तुलना करता है, जिसने उस गतिविधि के शुरू होने की शुरुआत की, जिसमें लॉन्च की गई गतिविधि स्थित है। यह इस तरह दिखता है:

 if (result != null && (intent = result.getParcelable(AccountManager.KEY_INTENT)) != null) { /* * The Authenticator API allows third party authenticators to * supply arbitrary intents to other apps that they can run, * this can be very bad when those apps are in the system like * the System Settings. */ int authenticatorUid = Binder.getCallingUid(); long bid = Binder.clearCallingIdentity(); try { PackageManager pm = mContext.getPackageManager(); ResolveInfo resolveInfo = pm.resolveActivityAsUser(intent, 0, mAccounts.userId); int targetUid = resolveInfo.activityInfo.applicationInfo.uid; if (PackageManager.SIGNATURE_MATCH != pm.checkSignatures(authenticatorUid, targetUid)) { throw new SecurityException( "Activity to be started with KEY_INTENT must " + "share Authenticator's signatures"); } } finally { Binder.restoreCallingIdentity(bid); } } 

ऐसा लगता है कि समस्या हल हो गई है, लेकिन यहां सब कुछ इतना आसान नहीं है। यह पता चला है कि इस फिक्स को प्रसिद्ध भेद्यता EvilParcel CVE-2017-13315 का उपयोग करके दरकिनार किया जा सकता है! जैसा कि हम पहले से जानते हैं, लॉन्च एनीवेयर को ठीक करने के बाद, सिस्टम एप्लिकेशन के डिजिटल हस्ताक्षर की जांच करता है। यदि यह जाँच सफल हो जाती है, तो बंडल IAccountManagerResponse.onResult () में पास हो जाता है। उसी समय, onResult () को IPC तंत्र के माध्यम से कहा जाता है, इसलिए बंडल को फिर से अनुक्रमित किया जाता है। OnResult () कार्यान्वयन में, निम्न होता है:

 /** Handles the responses from the AccountManager */ private class Response extends IAccountManagerResponse.Stub { public void onResult(Bundle bundle) { Intent intent = bundle.getParcelable(KEY_INTENT); if (intent != null && mActivity != null) { // since the user provided an Activity we will silently start intents // that we see mActivity.startActivity(intent); // leave the Future running to wait for the real response to this request } //<.....> } //<.....> } 

इसके बाद, बंडल को आशय कुंजी को निकाला जाता है और गतिविधि को बिना जांच के लॉन्च किया जाता है। नतीजतन, सिस्टम अधिकारों के साथ एक मनमानी गतिविधि शुरू करने के लिए, बंडल को इस तरह से बनाने के लिए पर्याप्त है कि इरादे का क्षेत्र पहले deserialization के दौरान छिपा हुआ है, और तब दिखाई देता है जब deserialization दोहराया जाता है। और, जैसा कि हमने पहले ही देखा है, यह ठीक यही कार्य है जिसे एविलपैरल कमजोरियां पूरी करती हैं।

फिलहाल, इस प्रकार की सभी ज्ञात कमजोरियों को स्वयं कमजोर चंचल वर्गों में फिक्स द्वारा तय किया जाता है। हालाँकि, भविष्य में कमजोर वर्गों के पुन: प्रकट होने से इंकार नहीं किया जा सकता है। बंडल के कार्यान्वयन और नए खातों को जोड़ने के लिए तंत्र अभी भी पहले जैसे ही हैं। जब आप खोजते हैं (या नए) कमजोर पार्सल योग्य वर्गों को खोजते हैं तो भी वे आपको ठीक उसी तरह का शोषण करने की अनुमति देते हैं। इसके अलावा, इन वर्गों का कार्यान्वयन अभी भी मैन्युअल रूप से किया जाता है, और प्रोग्रामर को क्रमबद्ध पार्सलेबल ऑब्जेक्ट की निरंतर लंबाई पर नजर रखनी होगी। और यह सभी परिणामों के साथ एक मानवीय कारक है। हालांकि, हम आशा करते हैं कि इस तरह की त्रुटियां यथासंभव कम होंगी, और EvilParcel की कमजोरियां Android उपकरणों के उपयोगकर्ताओं को परेशान नहीं करेंगी।

आप हमारे Dr.Web Security Space एंटीवायरस का उपयोग करके EvilParcel कमजोरियों के लिए अपने मोबाइल डिवाइस की जांच कर सकते हैं। अंतर्निहित "सुरक्षा लेखा परीक्षक" पहचान की गई समस्याओं पर रिपोर्ट करेगा और उन्हें हल करने के लिए सिफारिशें देगा।