scorpion-security-labs/cve-2020-12124CVE-2020-12124 के लिए एक प्रूफ-ऑफ-कॉन्सेप्ट का कार्यान्वयन
मूल रूप से https://www.klogixsecurity.com/scorpion-labs-blog/anatomy-of-an-iot-exploit-from-hands-on-to-rce
डेविड ई. बेकर द्वारा, 1 जून 2023 को प्रकाशित
यह अध्ययन जून 2020 तक Wavlink Wireless-AC1200 Gigabit राउटर के फर्मवेयर से संबंधित है। यहां चर्चा की गई कमजोरियाँ विक्रेता द्वारा पैच की गई हो भी सकती हैं और नहीं भी, लेकिन यह भेद्यता अनुसंधान का एक मामला है जो इसके निष्कर्ष के बजाय यात्रा को पुरस्कार के रूप में दिखाएगा। लेखक ने यह शोध सार्वजनिक प्रकटीकरण से पहले किया था, लेकिन अन्य शोधकर्ताओं द्वारा स्वतंत्र रूप से खोजे जाने और विक्रेता को रिपोर्ट करने के बाद किया था।
विक्रेता अपने उत्पादों के लिए फर्मवेयर अपनी वेबसाइट के समर्थन अनुभाग में उपलब्ध कराता है; यह IoT फर्मवेयर प्राप्त करने का एक सामान्य तरीका है और इसे डिवाइस मेमोरी से निकालने का एक उपयोगी विकल्प है। फर्मवेयर अनएन्क्रिप्टेड है, इसलिए इसे binwalk के साथ आसानी से निकाला जा सकता है। गतिशील विश्लेषण डिवाइस के एक भौतिक उदाहरण तक पहुंच के साथ किया गया था, और स्थैतिक विश्लेषण Ghidra के माध्यम से किया गया था।
Wavlink Wireless-AC1200 Gigabit राउटर के वेब इंटरफ़ेस में कई कमजोर एंडपॉइंट हैं जो उपयोगकर्ता-प्रदत्त डेटा की अनियंत्रित प्रतिलिपि को एप्लिकेशन स्टैक या सीधे कमांड लाइन पर भेजने की अनुमति देते हैं, जिससे मनमाना कमांड निष्पादन प्राप्त होता है।
डिवाइस के प्रारंभिक स्कैन से पता चलता है कि एकमात्र उजागर संसाधन प्रशासनिक वेब कंसोल था, जो LAN इंटरफ़ेस पर HTTP के माध्यम से TCP पोर्ट 80 पर प्रमाणित उपयोगकर्ताओं के लिए सुलभ था। डिवाइस अधिक सेवाएँ प्रदान कर सकता है, लेकिन ये आउट-ऑफ-द-बॉक्स और डिफ़ॉल्ट रूप से सक्षम नहीं हैं। इस प्रकार, यह जांच केवल वेब इंटरफ़ेस पर केंद्रित है।
उदाहरण डिवाइस का एक nmap स्कैन, जो केवल वेब इंटरफ़ेस को सुनते हुए दिखाता है।
सामान्य परीक्षण — जैसे कि डिवाइस डायग्नोस्टिक पैनलों पर पाए जाने वाले विशिष्ट कमांड इंजेक्शन जो ping या traceroute कमांड के मापदंडों में कमांड इंजेक्शन की अनुमति देते हैं — ने कोई तुरंत दिलचस्प परिणाम नहीं दिया, जो निराशाजनक था।
प्रशासनिक वेब पैनल में प्रमाणीकरण के बाद उपलब्ध प्रबंधन विकल्प। "USB Storage" को दूसरे विकल्प के रूप में देखा जा सकता है।
यहां जांचा गया पहला (अंततः शोषणीय) इंटरफ़ेस "USB storage" पैनल पर पाया गया, जिसे ऊपर स्क्रीनशॉट में दूसरे विकल्प के रूप में देखा जा सकता है। डिवाइस में इसके 802.2 ईथरनेट प्लग के बगल में एक USB पोर्ट है, जो सुझाव देता है कि यह नेटवर्क-अटैच्ड स्टोरेज (NAS) कार्यक्षमता प्रदान कर सकता है।
वास्तविक उदाहरण के पिछले हिस्से की तस्वीर, जो USB उपलब्धता दिखाती है।
भेद्यता अनुसंधान में एक सरल सिद्धांत यह है कि कोड का एक टुकड़ा जितने अधिक घटकों के साथ इंटरैक्ट करता है और उसमें जितने अधिक चलने वाले भाग होते हैं, उतनी ही अधिक संभावना है कि शोषणीय कोड पास में छिपा हो। NAS क्षमताओं की उपस्थिति आशाजनक है क्योंकि यह कोड की उपस्थिति को इंगित करती है जो एक साथ डिवाइस के सॉफ़्टवेयर स्तर, हार्डवेयर स्तर और प्लग-इन परिधीय (USB स्टोरेज स्वयं) के साथ इंटरैक्ट करता है।
USB Storage कंसोल के लिए प्रबंधन इंटरफ़ेस नीचे दिखाया गया है। अकेले "Workgroup" फ़ील्ड की उपस्थिति आशाजनक है, क्योंकि यह सुझाव देगा कि यह WiFi राउटर सर्वर मैसेज ब्लॉक (SMB) पर बातचीत करने का भी प्रयास कर सकता है — एक IoT राउटर के लिए एक बड़ा उपक्रम। मैं उन बार की गिनती नहीं कर सकता जब मैंने उपयोगकर्ता-प्रदत्त इनपुट को सीधे कमांड लाइन पर Unix smbpasswd फ़ंक्शन के तर्क के रूप में भेजते देखा है।
प्रमाणित उपयोगकर्ताओं के लिए उपलब्ध USB स्टोरेज विकल्प।
इन सेटिंग्स में हेरफेर करने के प्रारंभिक प्रयास डिवाइस द्वारा USB ड्राइव का पता न लगाने के कारण विफल रहे, जैसा कि नीचे देखा गया है।
USB Storage विकल्पों में कॉन्फ़िगरेशन परिवर्तन तब तक सहेजे नहीं जाएंगे जब तक कि एक उपयुक्त स्वरूपित ड्राइव को डिवाइस के USB पोर्ट में मैन्युअल रूप से प्लग नहीं किया जाता।
हालांकि, एक बार सही ढंग से स्वरूपित ड्राइव प्लग हो जाने के बाद, डिवाइस ने FTP उपयोगकर्ता नाम और पासवर्ड सेट करने की अनुमति दी। जैसा कि संदेह था, इसने इस उपयोगकर्ता-प्रदत्त इनपुट को कमांड लाइन पर रखा:
'password' फ़ील्ड में एक कमांड इंजेक्शन सीधे डिवाइस के ऑपरेटिंग सिस्टम तक पहली शेल पहुंच प्रदान करता है।
हालांकि दिलचस्प, यह भेद्यता अत्यधिक उत्साहित होने के लिए चुनौतीपूर्ण है: इसके लिए न केवल डिवाइस के प्रशासनिक इंटरफ़ेस तक प्रमाणित पहुंच की आवश्यकता है, बल्कि इसके USB ड्राइव में हेरफेर करने के लिए डिवाइस तक भौतिक पहुंच की भी आवश्यकता है। उपरोक्त शोषण एक शोधकर्ता को व्यक्तिगत ऑपरेटिंग सिस्टम घटकों के साथ बातचीत करने (और उन्हें रिवर्स इंजीनियरिंग उद्देश्यों के लिए निकालने) की अनुमति देता है।
डिवाइस एक व्यस्त बॉक्स-केंद्रित लिनक्स सिस्टम था जिसमें Lighttpd द्वारा संचालित वेब इंटरफ़ेस था। कॉमन गेटवे इंटरफ़ेस (CGI) कार्यक्षमता /etc_ro/lighttpd/www/cgi-bin/ में अलग-अलग बाइनरी द्वारा प्रदान की गई थी, जिसमें CGI URI के लिए वेब अनुरोध इन बाइनरी को सीधे लॉन्च करते थे। Ghidra में nas.cgi पर एक त्वरित नज़र नीचे लाइन 38 पर कमांड इंजेक्शन दिखाती है, जो उपयोगकर्ता-प्रदत्त पासवर्ड को सीधे do_system फ़ंक्शन (जो स्वयं मानक libc सिस्टम कॉल के चारों ओर एक आवरण है) को भेजता है।
उपयोगकर्ता इनपुट को लाइन 38 पर chpasswd.sh स्क्रिप्ट के तर्क के रूप में कमांड लाइन पर रखा जाता है, जिसके परिणामस्वरूप एक कमांड इंजेक्शन और सीधे डिवाइस के ऑपरेटिंग सिस्टम तक शेल पहुंच होती है।
/cgi-bin/ निर्देशिका के माध्यम से देखने से अधिक दिलचस्प शोषण खोजने का कार्य उपयोगकर्ता के लिए उपलब्ध CGI इंटरफ़ेस को सूचीबद्ध करने तक कम हो जाता है, जो नीचे दिखाया गया है:
डिवाइस पर उपलब्ध CGI बाइनरी की एक विस्तृत सूची, जो इस खंड में वर्णित शोषण द्वारा स्थापित शेल से लाइव ली गई है। उपयोगकर्ता इनपुट को लाइन 38 पर chpasswd.sh स्क्रिप्ट के तर्क के रूप में कमांड लाइन पर रखा जाता है, जिसके परिणामस्वरूप एक कमांड इंजेक्शन और सीधे डिवाइस के ऑपरेटिंग सिस्टम तक शेल पहुंच होती है।
प्रारंभिक जांच में कई चीजें सामने आती हैं। ध्यान देने वाली पहली महत्वपूर्ण बात यह है कि CGI बाइनरी अक्सर check_valid_user फ़ंक्शन को कॉल करती हैं। यह विधि देखती है कि क्या अनुरोध करने वाला IP पता फ़ाइल सिस्टम पर एक विशेष अस्थायी फ़ाइल में संग्रहीत है। न्यूनतम परीक्षण से पता चलता है कि किसी क्लाइंट की प्रमाणीकरण स्थिति तब तक सत्यापित नहीं होती जब तक इस विधि का कॉल नहीं किया जाता, इसलिए प्रत्येक CGI बाइनरी में इस फ़ंक्शन के आह्वान से पहले कोड की पूरी सतह बिना प्रमाणीकरण के सुलभ है।
adm.cgi का डीकंपाइलेशन जो check_valid_user विधि दिखाता है। इस कॉल से पहले का सारा कोड अनुरोधकर्ता की प्रमाणीकरण स्थिति को सत्यापित करने से पहले निष्पादित किया जाता है।
एक और दिलचस्प अवलोकन बड़ी संख्या में विधियाँ हैं जो उपयोगकर्ता-प्रदत्त इनपुट को सीधे स्टैक पर कॉपी करती हैं। उदाहरण के लिए, wireless.cgi का डीकंपाइलेशन नीचे लाइन 14 और 15 पर एक वेब अनुरोध के मुख्य भाग से लिए गए NewName पैरामीटर तर्क को दिखाता है, इसके बाद लाइन 34 पर इस उपयोगकर्ता इनपुट का स्टैक पर एक असुरक्षित strcpy होता है:
लाइन 14 और 34 अनुरोध मुख्य भाग से NewName पैरामीटर के सीधे प्रोग्राम स्टैक पर एक असुरक्षित strcpy प्रदर्शित करते हैं। adm.cgi का डीकंपाइलेशन जो check_valid_user विधि दिखाता है। इस कॉल से पहले का सारा कोड क्लाइंट की प्रमाणीकरण स्थिति को सत्यापित करने से पहले निष्पादित किया जाता है।
स्टैक पर उपयोगकर्ता इनपुट की यह प्रतिलिपि अकेले एक मेमोरी भ्रष्टाचार शोषण का सुझाव देती है, जिसे निम्नलिखित कमांड द्वारा सत्यापित किया जा सकता है:
curl –XPOST --data "page=SetName&NewName=\`python3 –c 'print(\\"A\\"\*(512)'\`" http://target-ip/cgi-bin/wireless.cgi
हालांकि आशाजनक, यहां एक रिटर्न-ओरिएंटेड हमला इष्टतम नहीं है। पहले से प्राप्त ऑपरेटिंग सिस्टम तक शेल पहुंच का उपयोग करके, निम्नलिखित कमांड '1' प्रदर्शित करता है, जो दर्शाता है कि एड्रेस स्पेस लेआउट रैंडमाइज़ेशन (ASLR) कमजोर रूप से लागू है, जिससे ROP श्रृंखला के वांछित गैजेट पर उतरने की संभावना 256 में से 1 रह जाती है:
# cat /proc/sys/kernel/randomize\_va\_space
1
इसके अलावा, नीचे दिया गया कमांड दिखाता है कि लिटिल-एंडियन बाइनरी स्टैक-गार्ड बाइट सेट के साथ संकलित की गई हैं, इसलिए एक श्रृंखला में केवल अंतिम गैजेट बाइनरी के भीतर एक पूर्व निर्धारित स्थान पर उतर सकता है। यदि क्रैश के बाद वेब सर्वर को पुनरारंभ करने के लिए एक वॉचडॉग प्रक्रिया मौजूद है, तो बार-बार एक रिटर्न-ओरिएंटेड शोषण फेंकना और अंततः सफलता की उम्मीद करना असंभव नहीं है, लेकिन यह भी संभव है कि कोड में कहीं और बेहतर बग छिपे हों।
xxd /etc\_ro/lighttpd/www/cgi-bin/wireless.cgi | head -n 10
CGI फ़ंक्शन के माध्यम से देखना जारी रखने पर अंततः live_api.cgi की जांच होगी। यह बाइनरी check_valid_user का कोई कॉल नहीं करती है, इसलिए URI /cgi-bin/live_api.cgi के लिए कोई भी वेब अनुरोध इस CGI एप्लिकेशन को बिना प्रमाणीकरण के चलाता है। चित्र 11 में लाइन 9 दिखाती है कि QUERY_STRING पर्यावरण चर, जो (Apache CGI विनिर्देश के अनुसार) प्रश्न चिह्न के तुरंत बाद अनुरोध URI का भाग है और इसलिए उपयोगकर्ता-प्रदत्त है, pcVar1 में संग्रहीत किया जाता है और चित्र 11 की लाइन 19 पर satellite_status विधि को भेजा जाता है।
live_api.cgi का एक डीकंपाइलेशन जो दिखाता है कि उपयोगकर्ता इनपुट URI से लाइन 9 पर लिया गया है और लाइन 19 पर satellite_status को भेजा गया है। adm.cgi का डीकंपाइलेशन जो check_valid_user विधि दिखाता है। इस कॉल से पहले का सारा कोड क्लाइंट की प्रमाणीकरण स्थिति को सत्यापित करने से पहले निष्पादित किया जाता है।
satellite_status विधि का डीकंपाइलेशन, जो चित्र 12 में दिखाया गया है, दर्शाता है कि क्वेरी स्ट्रिंग (अब param_1) को page, id, और ip मापदंडों के लिए पार्स किया गया है। ip पैरामीटर को चित्र 12 की लाइन 38 पर sprintf फ़ंक्शन के माध्यम से एक स्थानीय चर पर कॉपी किया जाता है और, लाइन 39 पर, do_system फ़ंक्शन को पारित किया जाता है। check_user_auth के कॉल की अनुपस्थिति इंगित करती है कि URI में एक अप्रमाणित उपयोगकर्ता से मनमाना क्लाइंट इनपुट सीधे ip URI पैरामीटर में कमांड लाइन पर रखा जाएगा, जिसकी पुष्टि निम्नलिखित से होती है:
satellite_status फ़ंक्शन का एक डीकंपाइलेशन, जो दिखाता है कि क्वेरी स्ट्रिंग (अब param_1) को लाइन 22 और 23 पर ip पैरामीटर के लिए पार्स किया गया है, फिर लाइन 38 और 39 पर do_system के कॉल पर भेजा गया है।
सबूत पुडिंग में है, जो डिवाइस के रिमोट अधिग्रहण को प्रभावित करने के लिए शोषण का उपयोग दिखाता है।
बाजार में नए आए IoT डिवाइस में शोषण खोजना कम लटके फल की तरह लग सकता है, जैसा कि इस पोस्ट की शुरुआत में उल्लेख किया गया था, लेकिन इस जांच का मूल्य इसके गंतव्य के बजाय इसकी यात्रा में था।
प्रमाणीकरण की चोरी और कमांड इंजेक्शन के स्थान की समझ फर्मवेयर के स्थैतिक विश्लेषण के बिना असंभव या असंभव होती। यदि यह ऑनलाइन उपलब्ध नहीं होता, तो उन्हें प्राप्त करने के लिए डिवाइस के ऑपरेटिंग सिस्टम तक गतिशील पहुंच की आवश्यकता होती, जिसके लिए डिवाइस तक गतिशील पहुंच की धुंधली उम्मीदें होतीं। पहुंच का यह स्तर स्वयं डिवाइस तक भौतिक पहुंच और या तो विशेष हार्डवेयर या कोड में संभावित गलतियों के स्थानों के बारे में निर्देशित अनुमान पर निर्भर करता था।
हम आशा करते हैं कि आपको यह यात्रा पसंद आई होगी, और आप और अधिक के लिए वापस आएंगे। हैप्पी हैकिंग!
लेखक:
डेविड बेकर, वरिष्ठ सुरक्षा सलाहकार, परीक्षण, K logix