______ ____ _____  _____ _           _ 
 |  ____/ __ \_   _|/ ____| |         | |
 | |__ | |  | || | | (___ | |_ ___  __| |
 |  __|| |  | || |  \___ \| __/ _ \/ _` |
 | |   | |__| || |_ ____) | ||  __/ (_| |
 |_|    \____/_____|_____/ \__\___|\__,_|

FOISted: एक MikroTik रिमोट जेलब्रेक

विवरण

FOISted, MikroTik के RouterOS में दो पोस्ट-ऑथेंटिकेशन कमजोरियों के लिए एक एक्सप्लॉइट है। इसका उपयोग 6.34 (2016) से 6.49.6 (नवीनतम v6 रिलीज़) चलाने वाले RouterOS को रिमोट रूप से जेलब्रेक करने के लिए किया जा सकता है।

इस रिपॉजिटरी में x86 चलाने वाले उपकरणों के लिए एक एक्सप्लॉइट स्क्रिप्ट शामिल है। यह कमजोरी अन्य डिवाइस संस्करणों में भी मौजूद है; ropchain लिखना पाठक के लिए एक अभ्यास के रूप में छोड़ दिया गया है :)

कुछ और जानकारी के लिए, RouterOS इंटर्नल्स पर हमारा ब्लॉग पोस्ट देखें: https://margin.re/blog/pulling-mikrotik-into-the-limelight.aspx

उपयोग

ऑटोमैजिक:

$ python3 exploit.py -H <router_ip> -u <username> -p <password>

फिर बाद में:

$ nc <router_ip> 1337

एक्सप्लॉइट स्क्रिप्ट RouterOS संस्करण का पता लगाएगी और सही ropchain स्वचालित रूप से तैनात करेगी। नोट: वर्तमान में केवल x86 RouterOS समर्थित है।

अगर किसी कारण से आपका संस्करण पहचाना नहीं जाता है, तो आप इसे स्पष्ट रूप से इसके साथ पास कर सकते हैं:

-v <version> # e.g. 6.49.6

यदि आप इसे 6.49.6 (सार्वजनिक रिलीज़ के समय नवीनतम) से नए RouterOS संस्करणों पर चला रहे हैं, तो आपका RouterOS संस्करण गैजेट डेटाबेस (./db) में नहीं हो सकता है। इसके बजाय आप /nova/bin/www का पथ पास कर सकते हैं और एक्सप्लॉइट स्क्रिप्ट ropchain के लिए सही गैजेट खोजने का प्रयास करेगी:

-f /path/to/nova/bin/www

यह कैसे काम करता है?

FOISted रिमोट कोड निष्पादन को सक्षम करने के लिए RouterOS v6 में दो कमजोरियों का लाभ उठाता है। इस अनुभाग में हम RouterOS IPC के बारे में कुछ पृष्ठभूमि ज्ञान पर चर्चा करते हैं और दोनों कमजोरियों पर विचार करते हैं।

नोट: यह अनुभाग मुख्य रूप से हमारे पूर्ण ब्लॉग पोस्ट का संक्षिप्त संस्करण है। अधिक विवरण के लिए उसे ज़रूर देखें!

RouterOS IPC

MikroTik के RouterOS के अंदर, प्रोग्राम एक कस्टम IPC प्रोटोकॉल का उपयोग करके एक-दूसरे के साथ संचार करते हैं।

वास्तविक डेटा पैकेट Nova Messages (nv::message आंतरिक रूप से) होते हैं। ये छद्म-JSON प्रारूप (6.38 से पहले) और एक सीरियलाइज़्ड बाइनरी प्रारूप में मौजूद होते हैं:

प्रत्येक प्रक्रिया का RouterOS सिस्टम के अंदर एक निश्चित पता होता है; उदाहरण के लिए /nova/bin/user पता 13 पर है और /nova/bin/www पता 70 पर है। इसके अतिरिक्त, प्रत्येक प्रोग्राम हैंडलर पंजीकृत कर सकता है जो उप-नेमस्पेस में कुछ विशिष्ट कार्यक्षमता लागू करते हैं। उदाहरण के लिए, /nova/bin/user के पास पता 4 पर एक हैंडलर है जो "login" एंडपॉइंट के रूप में कार्य करता है और अन्य सेवाओं के लिए प्रमाणीकरण करता है:

IPC संचार RouterOS संचालन का एक महत्वपूर्ण हिस्सा है। इसका उपयोग निम्न के लिए किया जाता है:

• प्रमाणीकरण करने के लिए
• कॉन्फ़िगरेशन पैरामीटर अपडेट/प्राप्त करने के लिए
• प्रक्रिया स्थिति के बारे में लगातार अपडेट भेजने के लिए (जैसे नेटवर्क आँकड़े)
• उपयोगकर्ता पहुँच प्रबंधन लागू करने के लिए
• किसी क्लाइंट के डिस्कनेक्ट होने पर प्रक्रियाओं को सूचित करने के लिए
• ... और भी बहुत कुछ

अपने रिवर्स इंजीनियरिंग प्रयासों के दौरान, हमने एक आंतरिक मैसेज ट्रेसर टूल लिखा जो हमें राउटर के संचालन के दौरान आदान-प्रदान किए गए सभी संदेशों को देखने की अनुमति देता है।

निम्नलिखित डेमो में, आप वेब इंटरफ़ेस के माध्यम से पेजिनेट करते समय आदान-प्रदान किए गए सभी संदेशों को देख सकते हैं: https://youtu.be/Em1hVWnbzQ4

watch

बग 1: FoisHandler

RouterOS वेब इंटरफ़ेस /nova/bin/www बाइनरी द्वारा लागू किया जाता है। हालाँकि, विशिष्ट पृष्ठों को अलग "Servlet" लाइब्रेरीज़ द्वारा संभाला जा सकता है जो अलग साझा लाइब्रेरीज़ में कार्यक्षमता लागू करती हैं।

उदाहरण के लिए, jsproxy.p सर्वलेट /jsproxy के अनुरोधों को संभालता है और winbox.p सर्वलेट /winbox के अनुरोधों को संभालता है, आदि...

ये सर्वलेट लाइब्रेरीज़ हैं जिन्हें आवश्यकता पड़ने पर पहली बार /nova/bin/www में लोड किया जाता है। उदाहरण के लिए, जब हम पहली बार /jsproxy लोड करते हैं, तो jsproxy.p लाइब्रेरी मेमोरी स्पेस में लोड हो जाएगी।

इस लाइब्रेरी लोडिंग प्रक्रिया के दौरान, हमने मैसेज ट्रेसर में कुछ दिलचस्प ट्रैफ़िक देखा:

विशेष रूप से, हमें एक संदेश मिला जो www बाइनरी से www के हैंडलर #2 को भेजा जा रहा था। यह पहले से ही संदिग्ध है क्योंकि RouterOS IPC का उद्देश्य अंतर-प्रक्रिया संचार है, न कि उसी प्रक्रिया के अंदर संचार...

इसके अलावा, हमने देखा कि दो तर्क वर्चुअल पॉइंटर्स (32-bit x86) प्रतीत होते थे, जिसने हमारी रुचि बढ़ाई क्योंकि यह बहुत असामान्य था।

/nova/bin/www के हैंडलर #2 के अंदर वास्तविक फ़ंक्शनों का निरीक्षण करने पर, हमें FoisHandler::cmdUnknown नामक एक फ़ंक्शन मिलता है जो इस प्रकार के संदेश प्राप्त होने पर चलता है।

आश्चर्यजनक रूप से, यह फ़ंक्शन संदेश से पैरामीटर 0x11 निकालता है और अन्य दो मापदंडों को तर्क के रूप में उपयोग करके इसे एक फ़ंक्शन के रूप में कॉल करता है!

तो स्पष्ट रूप से, यदि हम एक नियंत्रित संदेश भेज सकते हैं जो इस हैंडलर से टकराता है, तो हम किसी भी फ़ंक्शन को कॉल कर सकते हैं। और वहाँ से, ropchain में पिवट करना और कुछ अधिक परिष्कृत करना काफी आसान है।

IPC संदेश भेजना

RouterOS के उपयोगकर्ता के रूप में आंतरिक IPC संदेश भेजने के कई तरीके हैं। वास्तव में, सभी बाहरी क्लाइंट प्रमाणीकरण के बाद आपको मनमाने संदेश भेजने की अनुमति देते हैं:

• Winbox (8291 पर एक्सेस किया जाता है) -- winbox.exe क्लाइंट द्वारा उपयोग किया जाता है
• MAC Telnet -- जब राउटर के पास कोई IP पता नहीं होता है तो कनेक्ट करने के लिए उपयोग किया जाता है
• WebFig -- फ्रंट-एंड वेब इंटरफ़ेस द्वारा उपयोग किया जाता है

ये इंटरफ़ेस प्रारंभिक प्रमाणीकरण हैंडशेक करने के तरीके में भिन्न होते हैं, लेकिन एक बार प्रमाणीकृत होने के बाद, उपयोगकर्ता को आंतरिक सिस्टम में मनमाने Nova Messages को प्रॉक्सी करने में सक्षम बनाते हैं। Winbox और MAC Telnet क्रिप्टोग्राफ़िक प्रोटोकॉल के रिवर्स-इंजीनियरिंग के लिए हमारा ब्लॉग पोस्ट और रिपॉजिटरी देखें!

इस एक्सप्लॉइट कार्यान्वयन में, हम संचार के लिए अपने प्राथमिक तंत्र के रूप में WebFig एंडपॉइंट का उपयोग करते हैं। हमारे रिवर्स-इंजीनियर्ड क्लाइंट कार्यान्वयन के लिए webfig.py देखें।

हालाँकि, जब हम अपने कमजोर FoisHandler एंडपॉइंट को कॉल करने का प्रयास करते हैं तो एक समस्या उत्पन्न होती है:

RouterOS में प्रत्येक हैंडलर एक "policy" बिटमास्क परिभाषित कर सकता है जो निर्दिष्ट करता है कि कौन से उपयोगकर्ता इसे कॉल कर सकते हैं। यह पता चलता है कि FoisHandler की policy 0x80000000 है जो केवल आंतरिक पहुँच को इंगित करती है (अर्थात अन्य सिस्टम प्रक्रियाओं से उत्पन्न संदेश)।

एक व्यवस्थापक उपयोगकर्ता के रूप में, GUI के साथ हम अधिकतम अनुमति बिटमास्क केवल 0x7fffe सेट कर सकते हैं, जो पर्याप्त नहीं है।

बग 2: विशेषाधिकार वृद्धि

यह हमें हमारे दूसरे बग पर लाता है: admin से "super-admin" तक विशेषाधिकार वृद्धि।

जबकि GUI हमें केवल 0x7fffe का अनुमति बिटमास्क सेट करने देता है, आंतरिक रूप से यह वास्तव में केवल एक IPC संदेश भेजता है जिसमें एक फ़ील्ड बिटमास्क मान रखती है:

इसलिए हम अनुमति बिटमास्क मान 0xffffffff पर सेट करके अपना स्वयं का संदेश बना सकते हैं!

एक बार ऐसा करने के बाद, हमारे पास सिस्टम में किसी भी एंडपॉइंट तक पहुँचने के लिए अप्रतिबंधित पहुँच होती है!

एक्सप्लॉइट कार्यान्वयन

हमारा एक्सप्लॉइट FTP के माध्यम से सिस्टम पर दो फ़ाइलें अपलोड करके शुरू होता है:

• stage2: पोर्ट 1337 पर सुनने वाला एक रिवर्स शेल स्पॉनर युक्त
• busybox: हमें एक उचित शेल वातावरण प्रदान करता है

हमारा एक्सप्लॉइट फिर विशेषाधिकार वृद्धि करता है ताकि हम FoisHandler एंडपॉइंट तक पहुँच सकें।

अंत में हम संदेश में एम्बेडेड ropchain पर पिवट करने के लिए एक क्राफ्टेड संदेश भेजते हैं। ropchain uClibc में chmod और execve का पता गणना करता है और निम्न कार्य करता है:

• chmod 0777 stage2
• execve stage2

एक बार stage2 चल रहा है, तो आप पोर्ट 1337 से कनेक्ट कर सकते हैं और एक शेल प्राप्त कर सकते हैं!

अक्सर पूछे जाने वाले प्रश्न

क्या लोग इसका उपयोग मेरे राउटर को हैक करने के लिए कर सकते हैं?

नहीं, इन दोनों कमजोरियों का शोषण करने के लिए व्यवस्थापक क्रेडेंशियल्स की आवश्यकता होती है।

यह किन संस्करणों पर काम करता है?

कमजोरियाँ कम से कम 6.27 (सबसे पुराना सॉफ़्टवेयर जिसे हम डाउनलोड कर सकते थे) से लेकर सबसे हालिया v6: 6.49.6 तक मौजूद हैं। वेब इंटरफ़ेस को RouterOS v7 में फिर से तैयार किया गया था और कमजोर हैंडलर को पूरी तरह से हटा दिया गया था। हमारा POC x86 के लिए लिखा गया है।

एक्सप्लॉइट स्क्रिप्ट 6.34 से 6.49.6 तक हर RouterOS संस्करण के खिलाफ काम करती है (परीक्षण किया गया!)।