ईविल पार्सल भेद्यता विश्लेषण

परिचय

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

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

• उपयोगकर्ताओं से पुष्टि के बिना किसी भी अनुमति के साथ एप्लिकेशन इंस्टॉल करना और निकालना;
• डिवाइस पर स्थापित सॉफ्टवेयर को संक्रमित करना और अन्य कमजोरियों के साथ उपयोग किए जाने पर संक्रमित प्रतियों के साथ स्वच्छ मूल को बदलना;
• 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 वर्ग में त्रुटि);
• मई 2018 में प्रकाशित CVE-2017-13311 (SparseMappingTable वर्ग में त्रुटि);
• CVE-2017-13315 (DcParamObject वर्ग में त्रुटि), मई 2018 में प्रकाशित।

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

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

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

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

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

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

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


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

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

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

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

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

आइए एक वर्ग का एक उदाहरण देखें जिसमें यह त्रुटि है:

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

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

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


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

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


चित्र 3. क्रमांकन के बाद बंडल ऑब्जेक्ट

आइए अब इसे डिसेर्बलाइज़ करने की कोशिश करें:


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

हमें क्या मिलता है? आइए नजर डालते हैं पार्सल के टुकड़े पर:


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

आंकड़े ४ और ५ में, हम देखते हैं कि दो इंट के बजाय, एक इंट को डिसेंट्रलाइजेशन के दौरान createFromParcel मेथड में पढ़ा गया। इसलिए, बंडल से सभी बाद के मान गलत तरीके से पढ़े गए थे। 0x60 पर 0x0 मान अगली कुंजी की लंबाई के रूप में पढ़ा गया था। 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. एक कमजोर वर्ग के साथ एक बंडल के deserialization के बाद

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


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

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


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

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

शोषण ईविलपर्सेल

Android.InfectionAds.1 ने उपकरण स्वामियों से सॉफ़्टवेयर को स्वतंत्र रूप से स्थापित करने और निकालने के लिए CVE-2017-13315 का शोषण किया। लेकिन कैसे?

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


चित्रा 10. त्रुटि 7699048 का संचालन

ऑपरेटिंग सिस्टम में नए खातों को जोड़ने के लिए डिज़ाइन किया गया एक शोषणकारी अनुप्रयोग अकाउंटेंटेंट सेवा को लागू करने के लिए इस भेद्यता का उपयोग कर सकता है। त्रुटि 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 के दौरान दिखाई देता है।
जैसा कि हम पहले से ही जानते हैं, EvilParcel कमजोरियाँ वास्तव में इस कार्य को कर सकती हैं।

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

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