आपका "सुरक्षा" कैमरा कितना सुरक्षित है?

कार्यकारी सारांश

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

शोध का मुख्य ध्यान उन कमजोरियों पर था जो रिमोट कोड निष्पादन (RCE) का कारण बन सकती हैं। इस प्रकार की कमजोरी एक हमलावर को डिवाइस पर पूर्ण नियंत्रण लेने की अनुमति देती है और वीडियो कैमरे के मामले में मालिक की गोपनीयता से पूर्ण समझौता हो सकता है। दुर्भाग्य से डिवाइस फर्मवेयर ऐसी समस्याओं से भरा पाया गया।

पहले, डिवाइस कोई प्रमाणीकरण प्रदान नहीं करता है। परिणामस्वरूप, एक हमलावर जो इससे कनेक्ट करने में सक्षम है, स्वतंत्र रूप से इसे एक्सेस और पुनः कॉन्फ़िगर कर सकता है। सबसे सरल रूप में, डिवाइस को लगातार पुनः आरंभ करना संभव है, जिससे यह वैध उपयोगकर्ता के लिए पूरी तरह से अनुपयोगी हो जाता है। इस हमले का दायरा थोड़ा सीमित है क्योंकि डिवाइस WiFi नेटवर्क के भीतर उपयोग के लिए डिज़ाइन किया गया है, आमतौर पर NAT के पीछे, इस प्रकार इंटरनेट से सीधे पहुंच योग्य नहीं है। हालाँकि, डिवाइस और उसके मालिक के स्मार्टफोन ऐप के बीच एन्क्रिप्शन की कमी, संचार के लिए प्रॉक्सी के रूप में विक्रेता के सर्वर के उपयोग के साथ, MitM या DNS हेरफेर हमलों का अवसर पैदा करती है, जो WiFi NAT प्रतिबंध को तोड़ सकते हैं।

इसके अलावा, एप्लिकेशन संचार के लिए स्वामित्व वाले बाइनरी प्रोटोकॉल का उपयोग करता है। इसे C और C++ के मिश्रण में लागू किया गया है और यह असुरक्षित स्ट्रिंग हैंडलिंग फ़ंक्शनों से भरा पाया गया है। मुख्य निष्पादनयोग्य में भारी मात्रा में अप्रयुक्त कोड होता है, जो बताता है कि यह अन्य डिवाइसों पर पुनः उपयोग किया जाता है। यह रखरखाव को कठिन बनाता है और हमले की सतह को बढ़ाता है। एप्लिकेशन किसी भी आधुनिक सुरक्षा तंत्र को सक्षम नहीं करता है, जो इसे कई सामान्य शोषण तकनीकों से बचाएगा। इसके अलावा, यह उपयोगकर्ता अनुमतियों को भी सीमित नहीं करता है, जो उपलब्ध उच्चतम विशेषाधिकारों के साथ root के रूप में चलता है।

इस शोध के परिणामस्वरूप, निम्नलिखित चार कमजोरियाँ दर्ज की गई हैं।

• CVE-2020-25782 - आने वाले संदेश हैंडलिंग पर फ़ंक्शन CNetClientManage::ServerIP_Proto_Set में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लो
• CVE-2020-25783 - आने वाले संदेश हैंडलिंग पर फ़ंक्शन CNetClientTalk::OprMsg में बिना प्रमाणीकरण के हीप आधारित बफर ओवरफ्लो
• CVE-2020-25784 - आने वाले संदेश हैंडलिंग पर फ़ंक्शन CNetClientGuard::SubOprMsg में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लो
• CVE-2020-25785 - अद्यतन प्रक्रिया के दौरान फ़ंक्शन CFtpProtocol::FtpLogin में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लो

उनमें से तीन के लिए RCE शोषण विकसित किए गए थे, जो एक हमलावर को डिवाइस पर पूर्ण नियंत्रण प्राप्त करने की अनुमति देते हैं। हालाँकि, कमजोरियों की रिपोर्टिंग के प्रयासों के प्रति विक्रेता की प्रतिक्रिया की कमी के कारण, इस रिपॉजिटरी में केवल सीमित PoC शोषण हैं, जो केवल एप्लिकेशन को क्रैश करते हैं।

समस्याएँ सॉफ्टवेयर संस्करण V3.10.73 में पाई गईं और सॉफ्टवेयर संस्करण V4.15.77 में सत्यापित की गईं, जो इस प्रकाशन के समय (26 जनवरी 2021) उपलब्ध नवीनतम संस्करण है।

किसी भी प्रश्न के मामले में, मुझसे ईमेल (git commit देखें) या Github issues के माध्यम से संपर्क करने में संकोच न करें। यदि आपके पास एक IoT डिवाइस है जिसे आपको लगता है कि हैक करना दिलचस्प हो सकता है, Security Researcher की तलाश में हैं या बस नमस्ते कहना चाहते हैं, तो मुझे आपसे सुनकर खुशी होगी। आप मुझे एक कॉफी खरीद सकते हैं!

परिचय

लक्ष्य डिवाइस एक वीडियो कैमरा डिवाइस है, जिसे साथ में दिए गए मोबाइल ऐप से नियंत्रित किया जाता है। मेरा विश्लेषण कैमरे के नेटवर्क ट्रैफिक से शुरू हुआ और कैमरे के फर्मवेयर तक जारी रहा। सभी संचार के लिए कस्टम बाइनरी प्रोटोकॉल का उपयोग किया जाता है। कमांड या तो सीधे मोबाइल डिवाइस पर भेजे जाते हैं जब वे एक ही नेटवर्क में होते हैं या डिवाइस निर्माता के सर्वर से गुजरते हैं। कैमरा सॉफ्टवेयर स्वयं कई पोर्ट TCP (23456,34567) और UDP (34568, 34569) पर सुनता है। नेटवर्क ट्रैफिक के लिए न तो एन्क्रिप्शन है और न ही प्रमाणीकरण, जो MitM हमलों या नेटवर्क पर कैमरा उजागर होने पर सीधे एक्सेस की अनुमति देता है। ऐसा प्रतीत होता है कि बिना प्रमाणीकरण के भी वीडियो स्ट्रीम तक पहुंच संभव है, लेकिन मैंने इसे आजमाने के लिए स्वामित्व वाले प्रोटोकॉल का पर्याप्त रिवर्स इंजीनियरिंग नहीं किया है।

संक्षिप्त संचार अवलोकन के बाद, अगला कदम डिवाइस फर्मवेयर तक पहुंच प्राप्त करने का प्रयास करना था। मेरा पहला प्रयास डिवाइस अद्यतन प्रक्रिया को हाइजैक करके सीधे इसे डाउनलोड करना था, लेकिन नेटवर्क ट्रैफिक में ऐसा कुछ नहीं हुआ। यदि एक सहकर्मी से बहुत आवश्यक मदद न मिली होती, जिसने फ्लैश मेमोरी से फर्मवेयर निकाला, तो मैं इस चरण पर फंसा रहता, जिसने मुझे इस शोध को जारी रखने की अनुमति दी।

फर्मवेयर MIPS लिटिल-एंडियन CPU पर Linux चलता पाया गया। ठीक एक दिलचस्प प्रक्रिया है, जिसे Alloca कहा जाता है, जो वीडियो कैप्चर के लिए जिम्मेदार है और सभी नेटवर्क संचार भी संभालती है। एप्लिकेशन C++ में बनाया गया है और इसमें बहुत सारा कोड है, जो इस डिवाइस पर अप्रयुक्त है। यह इंगित करता है कि वही सॉफ्टवेयर विभिन्न डिवाइसों पर भी उपयोग किया जाता है।

The Leak

भले ही यह समस्या सबसे अंत में पाई गई, यह अधिकांश अन्य कमजोरियों के वास्तविक शोषण के लिए महत्वपूर्ण है, क्योंकि वे असुरक्षित C-भाषा स्ट्रिंग फ़ंक्शनों के उपयोग से उत्पन्न होती हैं। जबकि समान परिदृश्यों में सफल कोड निष्पादन के लिए कई तकनीकें मौजूद हैं, एप्लिकेशन इस तरह से बनाया गया है कि वे अधिकतर बेकार हैं। मुख्य समस्या यह है कि Alloca का कोड और डेटा स्थिर रूप से निम्न पतों ( <&nbsp;0x01000000) पर आवंटित होते हैं। इस प्रकार मौजूदा कोड के पुन: उपयोग के प्रयास (जैसे ROP और इसी तरह) उपयोगी नहीं हैं क्योंकि उन्हें प्रोग्राम की मेमोरी में पते लिखने की क्षमता की आवश्यकता होती है। चूंकि C-भाषा स्ट्रिंग्स समाप्ति वर्ण के रूप में \x00 का उपयोग करती हैं, और स्ट्रिंग फ़ंक्शन ऐसे पहले बाइट पर प्रोसेसिंग समाप्त करते हैं, इसलिए एक से अधिक NULL-बाइट का उपयोग संभव नहीं है। इसके अलावा, स्टैक स्थान यादृच्छिक है और एप्लिकेशन भारी रूप से मल्टी-थ्रेडेड है जो अन्य तकनीकों को बहुत कम विश्वसनीय बनाता है।

यह कमजोरी कई थ्रेड्स के बीच डेटा साझा करने और strcpy के असुरक्षित उपयोग का परिणाम है। जबकि मैंने इस विशेष समस्या का लंबे समय तक विश्लेषण किया है, मैंने इस प्रकाशन से कुछ सप्ताह पहले तक इसे डेटा लीक वेक्टर के रूप में उपयोग करने का अवसर नहीं देखा। दिलचस्प बात यह है कि C++ ऑब्जेक्ट के हीप पते को लीक करने के लिए धन्यवाद, यह कमजोरी रिमोट कोड निष्पादन की भी अनुमति देती है। हालाँकि, यह हमला इस रिपोर्ट में शामिल नहीं है।

Alloca एप्लिकेशन FTP पर स्वयं को अद्यतन कर सकता है। यह ऑपरेशन एक सर्वर द्वारा अनुरोध किया जा सकता है, जो आवश्यक उपयोगकर्ता नाम, पासवर्ड और फ़ाइल नाम भी प्रदान करता है। अद्यतन आरंभ करने वाला फ़ंक्शन यहाँ दिखाया गया है:

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

struct ftp_upgrade_pkt {
	struct pktHeader;
	char username[16];
	char password[16];
	char filename[128];
}

जबकि ftpUpgrade ऑब्जेक्ट कुछ इस तरह दिखता है:

struct CNetClientFtpUpgrade {
	// ... something here
	char filename[128];
	char unknown[6];
	char username[16];
	char password[16];
	CFtpDownlad *;
	CNetClientConnect*;
	int something[5];
	bool threadRunning;
	// ... and more
}