CVE-2020-0022

अद्भुत ब्लॉग पोस्ट और कोड के लिए Insinuator को बहुत-बहुत धन्यवाद!

परिणाम

insinuator पोस्ट में बताए गए सभी चरण पूरे कर लिए गए हैं, और कुछ और भी। ये सभी चरण README.md फ़ाइल में डालने के लिए बहुत अधिक हैं, इसलिए ऊपर उल्लिखित Insinuator की पोस्ट देखने में संकोच न करें।

एक्सप्लॉइट पूरी तरह से उस बिंदु तक पूरा हो चुका है जहाँ:

1. हमलावर-नियंत्रित पर्याप्त बड़े मेमोरी क्षेत्र का पता लीक हो जाता है
2. प्रोग्राम काउंटर को एक कस्टम पते पर इंगित करने के लिए संशोधित किया जाता है
3. विफलता की संभावना को काफी कम करने के लिए स्वचालित रूप से पुनः प्रयास किए जाते हैं
4. कोड को डिस्कनेक्शन समय और मेमोरी खोज गति के संदर्भ में अनुकूलित किया जाता है, इस हद तक कि और अधिक अनुकूलन एक्सप्लॉइट की स्थिरता से समझौता करता है

अंतर और सुधार

यह एक्सप्लॉइट Insinuator के कार्यान्वयन से निम्नलिखित तरीकों से भिन्न है:

1. यह पायथन के बजाय C में लिखा गया है (क्योंकि मुझे C पसंद है)
2. यह मॉड्यूलर तरीके से लिखा गया है, जहाँ प्रत्येक मॉड्यूल एक विशिष्ट कार्य के लिए जिम्मेदार है
3. इसका परीक्षण Android 9 (PQ3A.190801.002, सुरक्षा पैच स्तर 2019-08-01) चलाने वाले Pixel 3 XL पर किया गया था, क्योंकि मेरे पास यही उपलब्ध था
4. यह libicuuc.so के बजाय libandroid_runtime.so में पतों को लीक करता है, क्योंकि इस फ़ोन/लक्ष्य पर यह बेहतर काम करता था
5. इसमें दो उदाहरण JOP श्रृंखलाएँ कार्यान्वित हैं, एक जो सीधे execv को कॉल करती है और एक जो fork के बाद execv को कॉल करती है
6. इसके साथ कस्टम Ghidra स्क्रिप्ट है जो libandroid_runtime.so फ़ाइल को संसाधित करती है और फ़ंक्शंस और गैजेट्स के ऑफसेट निकालती है (एक्सप्लॉइट को अन्य लक्ष्यों पर पोर्ट करना आसान बनाने के लिए)

डेमो/स्क्रीनशॉट

यह एक वीडियो डेमो है जो PC को एक कस्टम पते पर इंगित करने के लिए एक्सप्लॉइट को संशोधित करता दिखाता है:

श्रृंखला का पहला पुनरावृत्ति वह है जिसे jop_experiment में देखा जा सकता है। यह श्रृंखला fork को कॉल किए बिना सीधे execv को कॉल करती है। यह commit ca28fdf में पाया जा सकता है। इस श्रृंखला का उपयोग करने पर यह होता है:

श्रृंखला का दूसरा पुनरावृत्ति वह है जो fork के बाद execv को कॉल करता है। इस श्रृंखला का पूरा विवरण यहाँ पाया जा सकता है। इस श्रृंखला का उपयोग करने पर यह होता है:

शुक्र है, Pixel 3 XL में ऐसी सुरक्षाएँ हैं जो ब्लूटूथ प्रक्रिया को fork और/या execv कॉल करने से रोकती हैं। ज्ञान-साझाकरण या दिखावे के संदर्भ में, मेरा काम यहाँ पूरा हो गया है। यदि मैं इससे अधिक उन्नत कुछ लिखता और साझा करता हूँ, तो यह ब्लैक-हैट हैकर्स के लिए बहुत उपयोगी हो सकता है।

एक्सप्लॉइट का निष्कर्ष

मैं इस एक्सप्लॉइट को पूर्ण मानता हूँ। भविष्य में सुधार हो सकते हैं:

• कस्टम शेलकोड चलाने के लिए dlsym और फिर mprotect को कॉल करने वाली JOP श्रृंखला लिखना
• विभिन्न लक्ष्यों के लिए ऑफसेट का डेटाबेस एकत्र करना और सहेजना
• सापेक्ष सार्वभौमिकता के लिए कई लक्ष्यों पर एक्सप्लॉइट का परीक्षण करना
• रूट विशेषाधिकार प्राप्त करने के लिए OS-स्तरीय एक्सप्लॉइट के साथ एक्सप्लॉइट को चेन करना (जैसे मेरा पिछला CVE-2019-2215 एक्सप्लॉइट)
• और भी बहुत कुछ...

ये सभी चीज़ें इस प्रोजेक्ट को एक मजेदार ज्ञान-साझाकरण प्रोजेक्ट से एक ब्लैक-हैट एक्सप्लॉइट में बदल देती हैं जिसे हथियार बनाया जा सकता है, इसलिए मेरी यात्रा यहीं समाप्त होती है, अभी के लिए... यदि आपके कोई प्रश्न हैं, तो संपर्क करने में संकोच न करें।

उपयोग

एक्सप्लॉइट चलाने के लिए, बस चलाएँ:

make build run ARGS="00:00:00:00:00:00" 

जहाँ 00:00:00:00:00:00 लक्ष्य/पीड़ित डिवाइस का MAC पता है। make clean के अलावा, शेष बिल्ड लक्ष्य केवल तभी सहायक होते हैं यदि आप एक्सप्लॉइट को संशोधित, सुधार या पुनः कार्यान्वित करने का प्रयास कर रहे हैं, इसलिए उनका गहराई से उल्लेख करने की आवश्यकता नहीं है।

डिबगिंग

• एंड्रॉइड gdbserver बाइनरी NDK फ़ोल्डर में पाई जा सकती है
• लक्ष्य को डिबग करने के लिए इसका उपयोग करें (अनुशंसित नहीं):

# लक्ष्य पर
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# होस्ट पर
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

• सीधे फ़ोन पर termux के gdb के माध्यम से (अनुशंसित):

# होस्ट पर
adb push ./gdbinit /data/local/tmp/gdbinit

# लक्ष्य पर
su
/data/data/com.termux/files/usr/bin/gdb -q -x /data/local/tmp/gdbinit -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 
# या
/data/data/com.termux/files/usr/bin/gdb -q -p $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}') 

यदि ब्लूटूथ सेवा काम करना बंद कर दे तो आप हमलावर मशीन पर इसे पुनरारंभ कर सकते हैं:

sudo systemctl restart bluetooth.service

नोट्स

यह खंड उन कुछ घटनाओं की व्याख्या करता है जो इस एक्सप्लॉइट के विकास के दौरान देखी गईं:

• रिमोट लक्ष्य पर टाइमआउट को रोकने के लिए SSP (HCI सॉकेट fd बनाते समय) बंद कर दिया जाता है:

• हम हीप क्लीनर पैकेट छिड़क रहे हैं ताकि get_message_loop के माध्यम से उपयोग किए जाने वाले base::MessageLoop ऑब्जेक्ट के vtable को संशोधित करने वाले अनपेक्षित ओवरफ़्लो के कारण लक्ष्य के क्रैश होने की संभावना कम हो सके:

• इसे insinuator पोस्ट में अच्छी तरह से समझाया नहीं गया था। हम 32-बाइट malloc चंक्स को लक्षित करके एक पैकेट का पता लीक कर रहे हैं, जिसमें partial_packets unordered_map में प्रत्येक आइटम के लिए एक लिंक्ड-लिस्ट आइटम शामिल है। यह map_experiment का उपयोग करके पता लगाया गया था map_experiment वास्तविक प्रोग्राम में जो लीक होता है उससे मेल नहीं खाता, इसलिए मैंने insinuator के पैटर्न का पालन किया और दूसरा पैटर्न उपयोग किया (जिसे मैंने प्रयोग द्वारा भी पाया)।

• क्रैश और PC ओवरराइट क्रोम सिग्नल ऑब्जेक्ट को सफलतापूर्वक क्रैश करता है

• JOP श्रृंखला को jop_experiment का उपयोग करके सिम्युलेट किया गया है। पूरी (पहली, केवल-execv) JOP श्रृंखला को JOP_PLAN.md में समझाया गया है