tezeb/accflyAccfly कैमरा सुरक्षा भेद्यताओं का खुलासा: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785।
2020 की शुरुआत में, अपने पिछले कार्यस्थल पर, मुझे एक आंतरिक pwn2own शैली के इवेंट में भाग लेने का अवसर मिला। कई लक्ष्य उपलब्ध थे, लेकिन मुझे सबसे अधिक Accfly वायरलेस सुरक्षा कैमरे में रुचि थी। दुर्भाग्य से मैं वास्तविक इवेंट के लिए अपना शोध पूरा नहीं कर सका, लेकिन चूंकि इस डिवाइस पर कोई अन्य प्रयास नहीं हुए थे, इसलिए मैंने इसे जारी रखा।
शोध का मुख्य ध्यान उन कमजोरियों पर था जो रिमोट कोड निष्पादन (RCE) का कारण बन सकती हैं। इस प्रकार की कमजोरी एक हमलावर को डिवाइस पर पूर्ण नियंत्रण लेने की अनुमति देती है और वीडियो कैमरे के मामले में मालिक की गोपनीयता से पूर्ण समझौता हो सकता है। दुर्भाग्य से डिवाइस फर्मवेयर ऐसी समस्याओं से भरा पाया गया।
पहले, डिवाइस कोई प्रमाणीकरण प्रदान नहीं करता है। परिणामस्वरूप, एक हमलावर जो इससे कनेक्ट करने में सक्षम है, स्वतंत्र रूप से इसे एक्सेस और पुनः कॉन्फ़िगर कर सकता है। सबसे सरल रूप में, डिवाइस को लगातार पुनः आरंभ करना संभव है, जिससे यह वैध उपयोगकर्ता के लिए पूरी तरह से अनुपयोगी हो जाता है। इस हमले का दायरा थोड़ा सीमित है क्योंकि डिवाइस WiFi नेटवर्क के भीतर उपयोग के लिए डिज़ाइन किया गया है, आमतौर पर NAT के पीछे, इस प्रकार इंटरनेट से सीधे पहुंच योग्य नहीं है। हालाँकि, डिवाइस और उसके मालिक के स्मार्टफोन ऐप के बीच एन्क्रिप्शन की कमी, संचार के लिए प्रॉक्सी के रूप में विक्रेता के सर्वर के उपयोग के साथ, MitM या DNS हेरफेर हमलों का अवसर पैदा करती है, जो WiFi NAT प्रतिबंध को तोड़ सकते हैं।
इसके अलावा, एप्लिकेशन संचार के लिए स्वामित्व वाले बाइनरी प्रोटोकॉल का उपयोग करता है। इसे C और C++ के मिश्रण में लागू किया गया है और यह असुरक्षित स्ट्रिंग हैंडलिंग फ़ंक्शनों से भरा पाया गया है। मुख्य निष्पादनयोग्य में भारी मात्रा में अप्रयुक्त कोड होता है, जो बताता है कि यह अन्य डिवाइसों पर पुनः उपयोग किया जाता है। यह रखरखाव को कठिन बनाता है और हमले की सतह को बढ़ाता है। एप्लिकेशन किसी भी आधुनिक सुरक्षा तंत्र को सक्षम नहीं करता है, जो इसे कई सामान्य शोषण तकनीकों से बचाएगा। इसके अलावा, यह उपयोगकर्ता अनुमतियों को भी सीमित नहीं करता है, जो उपलब्ध उच्चतम विशेषाधिकारों के साथ root के रूप में चलता है।
इस शोध के परिणामस्वरूप, निम्नलिखित चार कमजोरियाँ दर्ज की गई हैं।
CNetClientManage::ServerIP_Proto_Set में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लोCNetClientTalk::OprMsg में बिना प्रमाणीकरण के हीप आधारित बफर ओवरफ्लोCNetClientGuard::SubOprMsg में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लो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++ में बनाया गया है और इसमें बहुत सारा कोड है, जो इस डिवाइस पर अप्रयुक्त है। यह इंगित करता है कि वही सॉफ्टवेयर विभिन्न डिवाइसों पर भी उपयोग किया जाता है।
भले ही यह समस्या सबसे अंत में पाई गई, यह अधिकांश अन्य कमजोरियों के वास्तविक शोषण के लिए महत्वपूर्ण है, क्योंकि वे असुरक्षित C-भाषा स्ट्रिंग फ़ंक्शनों के उपयोग से उत्पन्न होती हैं। जबकि समान परिदृश्यों में सफल कोड निष्पादन के लिए कई तकनीकें मौजूद हैं, एप्लिकेशन इस तरह से बनाया गया है कि वे अधिकतर बेकार हैं। मुख्य समस्या यह है कि Alloca का कोड और डेटा स्थिर रूप से निम्न पतों ( < 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
}
लीक आंतरिक पॉइंटर्स (CFtpDownload*, CNetClientConnect*) में से एक के एप्लिकेशन द्वारा भर जाने के बाद हो सकता है। इसके अलावा, उपयोगकर्ता नाम और पासवर्ड को नए बनाए गए ऑब्जेक्ट में (एक बार और, लेकिन इस बार सुरक्षित रूप से) कॉपी किया जाता है, इससे पहले कि उसका पॉइंटर लीक होने योग्य स्थान में संग्रहीत किया जाए, इस प्रकार लीक केवल filename के साथ हो सकता है। परिणामस्वरूप, फ़ाइल नाम बहुत लंबा होना चाहिए, लेकिन strcpy के क्रम और समाप्ति-व्यवहार के कारण, पर्याप्त लंबा फ़ाइल नाम और भी लंबे उपयोगकर्ता नाम और पासवर्ड का परिणाम देगा जो प्रभाव में threadRunning को अधिलेखित कर देगा और थ्रेड बिल्कुल भी शुरू नहीं करेगा।
यदि यह कोड सिंगल-थ्रेडेड होता, तो बहुत कुछ नहीं किया जा सकता था। लेकिन जैसे ही नया FtpDownload थ्रेड स्पॉन होता है और DownloadFile फ़ंक्शन चलाता है, यह एक दिलचस्प अवसर प्रस्तुत करता है क्योंकि यह CNetClientFtpUpgrade ऑब्जेक्ट को आने वाले पैकेटों को संभालने वाले थ्रेड के साथ साझा करता है। इसमें न केवल कई IO ऑपरेशन हैं जिन्हें बाहरी रूप से नियंत्रित किया जा सकता है (DNS अनुरोध, FTP कनेक्शन प्रोसेसिंग), बल्कि यह FTP से 10 बार तक कनेक्ट करने का प्रयास भी करता है (यह DownloadFile के कॉलर में किया जाता है)। यह FtpDownload थ्रेड के निष्पादन को नियंत्रित करने की अनुमति देता है (इसे IO ऑपरेशनों पर ब्लॉक करके), इस प्रकार संदेश हैंडलिंग थ्रेड को अन्य अनुरोधों को संसाधित करने के लिए समय देता है।
संक्षेप में, केवल कई अद्यतन अनुरोध भेजकर, पहले से चल रहे FtpDownload थ्रेड द्वारा उपयोग किए जाने वाले filename (और अन्य पैरामीटर) को बदलना और लीक हुए हीप पते को प्राप्त करना संभव है। एक बोनस के रूप में, FtpSize फ़ंक्शन (हरे रंग में चिह्नित), लीक हुए पते द्वारा संदर्भित ऑब्जेक्ट के अंदर बफर का उपयोग filename को स्वयं संग्रहीत करने के लिए करता है, जो पहले चरण के शेलकोड के तुच्छ इंजेक्शन की अनुमति देता है। यहाँ एकमात्र सीमा लंबाई और NULL-बाइट्स की कमी है, strcpy के उपयोग के कारण। एक नमूना PoC प्रदान किया गया है जो केवल डिवाइस से एक हीप पता लीक करता है।
फ़ंक्शन CNetClientManage::ServerIP_Proto_Set में बिना प्रमाणीकरण के स्टैक आधारित BO
आने वाले ट्रैफिक हैंडलिंग पर प्रमाणीकरण की पूर्ण कमी ने मुझे पैकेट हैंडलरों की खोज करने के लिए प्रेरित किया। दिलचस्प फ़ंक्शनों में से एक ServerIP_Proto_Set है। ऐसा लगता है कि इसका उपयोग DNS रिज़ॉल्यूशन के लिए एक स्थिर ओवरराइट बनाने के लिए किया जाता है। मुझे इस तरह से ट्रैफिक को पुनर्निर्देशित करने का कोई तरीका नहीं मिला, लेकिन यहाँ एक और बफर ओवरफ्लो है (नारंगी रंग में चिह्नित)।
वह डेटा, जो सीधे पैकेट से पढ़ा जाता है, sprintf फ़ंक्शन के अंदर उपयोग किया जाता है। इस मामले में यह माना जाता है कि पैकेट का डेटा 16 बाइट्स के बफर में फिट हो जाएगा, लेकिन सादे %s प्रारूप का उपयोग जितने चाहें उतने बाइट्स लिखने की अनुमति देता है, बशर्ते उनमें NULL न हो।
यह कमजोरी काफी सीमित है। हालाँकि स्टैक पर बहुत सारा डेटा लिखना संभव है, इसलिए NOP-sledge का उपयोग काम कर सकता है, NULL-बाइट्स लिखना संभव नहीं है। यहां तक कि एक एकल NULL-बाइट लिखने का प्रयास भी विफल हो जाएगा, क्योंकि sprintf फ़ंक्शन प्रारूप इसके पहले \n रखता है। एक और बाधा, एक CMutex ऑब्जेक्ट है जो बफर के बाद संग्रहीत होता है। ओवरफ्लो के किसी भी प्रयास को इस म्यूटेक्स को सही मान से भरना होगा (या कम से कम एक जो CGuard डिस्ट्रक्टर को संतुष्ट करेगा - लाल रंग में चिह्नित)। यह समस्याग्रस्त है, क्योंकि डिस्ट्रक्टर पारित चर को दो बार डीरेफरेंस करता है और फिर pthread_mutex_unlock कॉल में इसके मान का उपयोग करता है। कुछ परीक्षण के बाद मैंने पाया कि NULLs से भरा बफर pthread_mutex_unlock से सही ढंग से लौटने के लिए पर्याप्त है, लेकिन फिर भी इसे एक उचित मेमोरी पते में डीरेफरेंस करने की आवश्यकता थी।
यह लीक बचाव के लिए आता है। हमला थोड़ा जटिल है, क्योंकि हमें एक हीप पते की आवश्यकता है जिसमें कोई NULL-बाइट्स न हों। सौभाग्य से खोज आसान हो जाती है, क्योंकि डिवाइस हमें दूरस्थ बिना प्रमाणीकरण के पुनः आरंभ करने की क्षमता प्रदान करता है। हर बार एक अलग हीप पता स्थान आवंटन प्रदान करता है। इसलिए डिवाइस को रीसेट करना और तब तक एक पता लीक करना संभव है जब तक कि एक उपयुक्त न मिल जाए। सुविधाजनक रूप से यह शेलकोड के एक छोटे पहले चरण को संग्रहीत करने की भी अनुमति देता है। चूंकि हमें म्यूटेक्स समस्या को दूर करने की आवश्यकता है (पॉइंटर के पॉइंटर की आवश्यकता है), हम एक और पता लीक करते हैं, इस बार पहले लीक किए गए पते को फ़ाइल नाम के रूप में पास करते हैं। निम्नलिखित आरेख अपेक्षित मेमोरी लेआउट दिखाता है:
यदि सब कुछ योजना के अनुसार होता है, तो दूसरे पते को म्यूटेक्स के रूप में और पहले को रिटर्न पते के रूप में पास करना संभव है। हालाँकि, PoC द्वारा किए गए अनुसार केवल एप्लिकेशन को क्रैश करने के लिए यह आवश्यक नहीं है।
फ़ंक्शन CNetClientTalk::OprMsg में बिना प्रमाणीकरण के हीप आधारित BO
डिवाइस को द्वि-दिशात्मक आवाज संचार की अनुमति देनी चाहिए। आने वाले पैकेटों के लिए एक और हैंडलर, ऑडियो प्राप्त करने और चलाने के लिए जिम्मेदार प्रतीत होता है। audio_pkt_hdr नेटवर्क पैकेट निम्नलिखित संरचना द्वारा वर्णित है:
struct audio_pkt_hdr {
struct pktHeader field_0x0;
int field_0x14
int field_0x18
int field_0x1c
char audioBuff[0x140];
}
pktHeader संरचना के क्षेत्रों में से एक पैकेट की लंबाई है (जैसा कि नेटवर्क पर स्थानांतरित किया गया है)। इस क्षेत्र को प्रेषक द्वारा स्वतंत्र रूप से सेट किया जा सकता है। कमजोर हिस्सा आने वाले पैकेट में प्रदान किए गए अविश्वसनीय लंबाई मान का उपयोग करके सीधे आने वाले पैकेट से डेटा की प्रतिलिपि बनाना है।
जैसा कि देखा जा सकता है, CNetClientTalk ऑब्जेक्ट निम्नलिखित कंस्ट्रक्टर के साथ बनाया गया है:
इसलिए memcpy के उपरोक्त कॉल के परिणामस्वरूप हीप पर बफर ओवरफ्लो होता है। दुर्भाग्य से इस समस्या का वास्तविक शोषण काफी कठिन है। भले ही हीप को बार-बार अधिलेखित करना संभव है, मुझे यह नियंत्रित करने का कोई तरीका नहीं मिला कि ओवरफ्लो हो रहे बफर के बाद हीप पर कौन सा डेटा संग्रहीत किया जाएगा। चूंकि एप्लिकेशन में 50 से अधिक सक्रिय थ्रेड हैं, उनमें से कुछ ऑडियो और वीडियो प्रोसेसिंग के लिए जिम्मेदार हैं, यह लगातार मेमोरी (डी)आवंटित कर रहा है। इसके परिणामस्वरूप हीप डेटा लगातार बदलता रहता है, इस प्रकार यह अनुमान लगाना कठिन हो जाता है कि बफर के बाद क्या संग्रहीत है और इसे सही ढंग से अधिलेखित करना मुश्किल हो जाता है।
फ़ंक्शन CNetClientGuard::SubOprMsg में बिना प्रमाणीकरण के स्टैक आधारित BO
यहाँ आने वाले पैकेटों का एक और हैंडलर आता है। इस बार नेटवर्क पैकेट की निम्नलिखित संरचना है (सामान्य पैकेट हेडर छोड़ा गया है):
struct pkt_hdr_sub_cliGuard {
dword deviceId;
dword userId;
dword magic;
dword subCmd;
dword field_0x10;
dword field_0x14;
dword field_0x18;
dword field_0x1c;
dword guard_icommand;
dword moreThenRandomStackValue;
dword itemCnt;
char array_of_0x18[24];
};
फिर से दिलचस्प हिस्सा अंतिम सरणी है (क्योंकि हम इस पैकेट को जितना चाहें उतना बढ़ा सकते हैं), जिसमें 24 आकार की कुछ आंतरिक संरचना होती है। कमजोरी इस धारणा से उत्पन्न होती है कि प्राप्त itemCnt 6 से अधिक नहीं होगा, क्योंकि प्रतिलिपि गंतव्य बफर का आकार 144 (=24*6) है, जो निम्नलिखित सूची में दिखाई देता है (नारंगी हाइलाइट):
इस बार प्रतिलिपि memcpy (हरे हाइलाइट) का उपयोग करके की जाती है, इसलिए अनुमत वर्णों पर कोई सीमा नहीं है। प्रतिलिपि एक while लूप (नीले रंग में चिह्नित) द्वारा, चंक्स में की जाती है। यह ध्यान देने योग्य है कि काउंटर cnt_v0 लूप के अंदर घट रहा है, इसलिए चंक्स उल्टे क्रम में कॉपी किए जाते हैं। कमजोर बफर buf के बाद आने वाले चरों को शामिल करते हुए, ओवरफ्लो में 256 बाइट्स, फिर 4 रजिस्टर ($s0-$s3) और $ra होने चाहिए। चूंकि हमें मेमोरी लेआउट की जानकारी नहीं है, PoC कोड एक ROP तकनीक का उपयोग करता है। एक एकल गैजेट का उपयोग किया जाता है, जो डिवाइस की अंतर्निहित ध्वनियों में से एक बजाता है (और क्रैश करता है)।
फ़ंक्शन CFtpProtocol::FtpLogin में बिना प्रमाणीकरण के स्टैक आधारित बफर ओवरफ्लो
मेरे विश्लेषण की प्रारंभिक दिशाओं में से एक अद्यतन प्रक्रिया की खोज करना था। जैसा कि मैंने पाया, डिवाइस में एक FTP अद्यतन कार्यक्षमता है, जिसे अद्यतन अनुरोध भेजकर शुरू किया जा सकता है और इसके परिणामस्वरूप बाहरी FTP साइट से फर्मवेयर डाउनलोड होता है। अन्य कमजोरियों की तरह, डिवाइस अद्यतन का अनुरोध करने से पहले प्रमाणित करने की कोई आवश्यकता नहीं है। FTP कार्यक्षमता के गहन विश्लेषण से CFtpProtocol::FtpLogin फ़ंक्शन में एक स्टैक आधारित बफर ओवरफ्लो का पता चला। जैसा कि हम नीचे दिए गए डीकंपाइल सूची में देख सकते हैं, फ़ंक्शन 256 आकार की एक char सरणी को FtpPwd फ़ंक्शन में पास करता है।
FtpPwd का उपयोग FTP सर्वर से वर्तमान कार्यशील निर्देशिका प्राप्त करने के लिए किया जाता है। यह अपने आंतरिक बफर को प्रतिक्रिया के 1500 बाइट्स तक लोड करता है और फिर उन्हें प्रदान किए गए बफर में कॉपी करता है। कॉलों के इस अनुक्रम के परिणामस्वरूप 1242 बाइट्स का ओवरफ्लो होता है। इस मामले में अनुमत वर्ण बहुत सीमित हैं, क्योंकि " (डबल-कोट) के उपयोग से इनपुट स्ट्रिंग छोटी हो जाएगी (C-स्ट्रिंग में char खोजने के लिए strchr का उपयोग किया जाता है) और बफर ओवरफ्लो नहीं होगा। सौभाग्य से केवल एक पता वितरित करना आवश्यक है, जिस पर कोड निष्पादन पुनर्निर्देशित किया जाएगा।
इस कमजोरी का शोषण करने के लिए या तो DNS को नियंत्रित करना या FTP सर्वर के कनेक्शन को पुनर्निर्देशित (या MitM) करना आवश्यक है। एप्लिकेशन में कोई आधुनिक सुरक्षा उपाय नहीं हैं, इसलिए स्टैक से सीधे कोड निष्पादित करना संभव है। पते के लीक के बिना, सबसे अच्छा जो किया जा सकता था वह या तो स्टैक स्थान का अनुमान लगाना या एक एकल फ़ंक्शन के लिए निष्पादन का पुनर्निर्देशन था, जो फिर एप्लिकेशन को क्रैश कर देगा। मेरे पहले प्रयास बस यही थे, अंतर्निहित ध्वनियों में से एक बजाना, जो PoC के रूप में प्रदान किया गया है। लीक का उपयोग करके, डिवाइस पर पूर्ण नियंत्रण प्राप्त करना संभव है।