CVE-2020-6514

एक्सप्लॉइट

एक्सप्लॉइट लिखते समय, मैंने मूल रूप से WebRTC के सोर्स को बदलकर और उसे पुनः संकलित करके लक्षित डिवाइस को भेजे जाने वाले SCTP पैकेट्स को बदल दिया था। यह क्लोज्ड-सोर्स अनुप्रयोगों पर हमला करने के लिए व्यावहारिक नहीं था, इसलिए अंततः मैंने हमला करने वाले डिवाइस के बाइनरी को हुक करने के लिए Frida का उपयोग करना शुरू कर दिया। Frida की हुकिंग कार्यक्षमता किसी विशिष्ट नेटिव फ़ंक्शन को कॉल किए जाने से पहले और बाद में कोड निष्पादित करने की अनुमति देती है, जिससे मेरा एक्सप्लॉइट बाहर जाने वाले SCTP पैकेट्स को बदलने के साथ-साथ आने वाले पैकेट्स का निरीक्षण भी कर सका। कार्यात्मक रूप से, यह हमला करने वाले क्लाइंट के सोर्स को बदलने के बराबर है, लेकिन परिवर्तन कंपाइल-टाइम पर सोर्स में करने के बजाय, Frida द्वारा रन-टाइम पर गतिशील रूप से किए जाते हैं। एक्सप्लॉइट का सोर्स यहाँ उपलब्ध है।

हमला करने वाले डिवाइस को सात फ़ंक्शन हुक करने की आवश्यकता होती है, जो इस प्रकार हैं।

usrsctp_conninput // आने वाले SCTP को प्राप्त करता है DtlsTransport::SendPacket // बाहर जाने वाले SCTP को भेजता है cricket::SctpTransport::SctpTransport // SCTP ट्रांसपोर्ट तैयार होने का पता लगाता है calculate_crc32c // SCTP पैकेट्स के लिए चेकसम की गणना करता है sctp_hmac // गुप्त कुंजी का अनुमान लगाने के लिए HMAC निष्पादित करता है sctp_hmac_m // SCTP पैकेट पर हस्ताक्षर करता है SrtpTransport::ProtectRtp // हीप नॉइज़ को कम करने के लिए RTP को दबाता है

इन फ़ंक्शनों को प्रतीकों (symbols) के रूप में, या बाइनरी में ऑफ़सेट के रूप में हुक किया जा सकता है।

एक्सप्लॉइट को काम करने के लिए लक्षित डिवाइस के बाइनरी से तीन एड्रेस ऑफ़सेट की भी आवश्यकता होती है। इनमें से दो हैं: system फ़ंक्शन और malloc फ़ंक्शन के बीच का ऑफ़सेट, तथा पिछली पोस्ट में वर्णित गैजेट और malloc फ़ंक्शन के बीच का ऑफ़सेट। ये ऑफ़सेट libc में होते हैं, जो एक Android सिस्टम लाइब्रेरी है, इसलिए इन्हें लक्षित डिवाइस के Android संस्करण के आधार पर निर्धारित करने की आवश्यकता होती है। cricket::SctpTransport vtable के स्थान से ग्लोबल ऑफ़सेट टेबल में malloc के स्थान तक का ऑफ़सेट भी आवश्यक है। इसे उस बाइनरी से निर्धारित किया जाना चाहिए जो हमला किए जा रहे अनुप्रयोग में WebRTC को शामिल करती है।

ध्यान दें कि दिए गए एक्सप्लॉइट स्क्रिप्ट्स की एक गंभीर सीमा है: हर बार मेमोरी पढ़ने पर, यह केवल तभी काम करता है जब पॉइंटर का बिट 31 सेट हो। इसके कारणों को Part 2 में समझाया गया है। एक्सप्लॉइट स्क्रिप्ट में FWD_TSN चंक्स का उपयोग करके इसे ठीक करने और किसी भी पॉइंटर को पढ़ने का एक उदाहरण है, लेकिन यह हर रीड के लिए लागू नहीं किया गया है। परीक्षण प्रयोजनों के लिए, मैंने डिवाइस को तब तक रीसेट किया जब तक कि WebRTC लाइब्रेरी अनुकूल स्थान पर मैप नहीं हो गई।

Android अनुप्रयोग

लोकप्रिय Android अनुप्रयोगों की एक सूची, जो WebRTC को एकीकृत करते हैं, Google Play पर APK फ़ाइलों में usrsctp के एक विशिष्ट स्ट्रिंग को खोजकर निर्धारित की गई थी। लगभग 200 अनुप्रयोग, जिनके पाँच मिलियन से अधिक उपयोगकर्ता हैं, WebRTC का उपयोग करते प्रतीत हुए। मैंने इन अनुप्रयोगों का मूल्यांकन यह निर्धारित करने के लिए किया कि क्या वे एक्सप्लॉइट में मौजूद कमजोरियों से प्रभावित हो सकते हैं, और इसका प्रभाव क्या होगा।

यह पता चला कि अनुप्रयोगों द्वारा WebRTC का उपयोग करने के तरीके काफी विविध हैं, लेकिन उन्हें चार मुख्य श्रेणियों में विभाजित किया जा सकता है।

Projection: किसी मोबाइल अनुप्रयोग की स्क्रीन और नियंत्रण को बेहतर उपयोगिता के लिए उपयोगकर्ता की सहमति से डेस्कटॉप ब्राउज़र में प्रोजेक्ट किया जाता है Streaming: ऑडियो और वीडियो सामग्री एक उपयोगकर्ता से कई उपयोगकर्ताओं को भेजी जाती है। आमतौर पर एक मध्यस्थ सर्वर होता है, इसलिए भेजने वाले को संभवतः हजारों पीयर्स को प्रबंधित करने की आवश्यकता नहीं होती है, और सामग्री बाद में देखने के लिए रिकॉर्ड की जाती है Browsers: सभी प्रमुख ब्राउज़रों में JavaScript WebRTC API को लागू करने के लिए WebRTC शामिल है Conferencing: दो या अधिक उपयोगकर्ता वास्तविक समय में ऑडियो या वीडियो के माध्यम से संवाद करते हैं

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

Streaming भी काफी कम जोखिम वाला है। हालाँकि यह संभव है कि कुछ अनुप्रयोग कम दर्शकों वाली स्ट्रीम के लिए पीयर-टू-पीयर कनेक्शन का उपयोग करते हैं, वे आमतौर पर एक मध्यस्थ सर्वर का उपयोग करते हैं जो भेजने वाले पीयर से WebRTC कनेक्शन समाप्त करता है और प्राप्त करने वाले पीयर्स के साथ नए कनेक्शन शुरू करता है। इसका मतलब है कि हमलावर आमतौर पर सीधे किसी पीयर को विकृत (malformed) पैकेट नहीं भेज सकता। यहाँ तक कि पीयर-टू-पीयर स्ट्रीमिंग वाली व्यवस्था में भी, लक्ष्य को स्ट्रीम देखने के लिए उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है, और अक्सर यह सीमित करने का कोई तरीका नहीं होता है कि स्ट्रीम तक कौन पहुँच सकता है। इस कारण से, WebRTC का उपयोग करने वाले स्ट्रीमिंग अनुप्रयोग संभवतः लक्षित हमलों के लिए उपयोगी नहीं हैं। बेशक, यह संभव है कि ये कमजोरियाँ स्ट्रीमिंग सेवाओं द्वारा उपयोग किए जाने वाले सर्वरों को प्रभावित करें, लेकिन इस शोध में इसकी जाँच नहीं की गई।

Browsers लगभग निश्चित रूप से WebRTC के अधिकांश बग्स के प्रति संवेदनशील हैं, क्योंकि वे इसके कॉन्फ़िगरेशन पर काफी हद तक नियंत्रण की अनुमति देते हैं। ब्राउज़र में ऐसे बग का शोषण करने के लिए, हमलावर को एक ऐसा होस्ट स्थापित करना होगा जो पीयर-टू-पीयर कनेक्शन में दूसरे पीयर की तरह कार्य करे, और लक्ष्य को एक ऐसे वेबपेज पर जाने के लिए राजी करना होगा जो उस होस्ट को कॉल शुरू करता है। इस स्थिति में, कमजोरी का प्रभाव JavaScript में अन्य मेमोरी करप्शन कमजोरियों के समान होगा।

Conferencing WebRTC का सबसे उच्च जोखिम वाला उपयोग है, लेकिन किसी कमजोरी का वास्तविक प्रभाव काफी हद तक इस बात पर निर्भर करता है कि किसी अनुप्रयोग के उपयोगकर्ता एक-दूसरे से कैसे संपर्क करते हैं। सबसे उच्च जोखिम वाला डिज़ाइन वह अनुप्रयोग है जहाँ कोई भी उपयोगकर्ता किसी पहचानकर्ता (identifier) के आधार पर किसी अन्य उपयोगकर्ता से संपर्क कर सकता है। कुछ अनुप्रयोगों में कॉल करने से पहले यह आवश्यक होता है कि कॉल प्राप्त करने वाले ने कॉल करने वाले के साथ किसी विशिष्ट तरीके से इंटरैक्ट किया हो, जिससे किसी लक्ष्य से संपर्क करना कठिन हो जाता है और आम तौर पर जोखिम कम हो जाता है। कुछ अनुप्रयोगों में कॉल शुरू करने के लिए उपयोगकर्ताओं को कोड दर्ज करना या लिंक पर जाना आवश्यक होता है, जिसका समान प्रभाव होता है। ऐसे अनुप्रयोगों का एक बड़ा समूह भी है जहाँ किसी विशिष्ट उपयोगकर्ता को कॉल करना कठिन या असंभव है, उदाहरण के लिए चैट रूलेट अनुप्रयोग, और ऐसे अनुप्रयोग जिनमें ऐसी सुविधाएँ हैं जो उपयोगकर्ता को ग्राहक सहायता को कॉल शुरू करने की अनुमति देती हैं।

इस शोध के लिए, मैंने उन conferencing अनुप्रयोगों पर ध्यान केंद्रित किया जो उपयोगकर्ताओं को विशिष्ट अन्य उपयोगकर्ताओं से संपर्क करने की अनुमति देते हैं। इससे मेरी 200 अनुप्रयोगों की सूची घटकर 14 अनुप्रयोगों की रह गई, जो इस प्रकार हैं।