CVE-2020-0022

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

परिणाम

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

यह एक्सप्लॉइट निम्नलिखित बिंदु तक पूरी तरह से पूर्ण है:

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

अंतर और सुधार

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

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

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

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

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

चेन का दूसरा संस्करण वह है जो fork फिर execv को कॉल करता है। इस चेन के पूरे विवरण यहाँ पाए जा सकते हैं। इस चेन का उपयोग करने पर यह होता है:

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

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

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

• एक JOP चेन लिखना जो dlsym फिर mprotect को कॉल करके कस्टम शेलकोड चलाए
• विभिन्न लक्ष्यों के लिए ऑफ़सेट का डेटाबेस एकत्र और सहेजना
• सापेक्ष सार्वभौमिकता के लिए कई लक्ष्यों पर एक्सप्लॉइट का परीक्षण करना
• रूट विशेषाधिकार प्राप्त करने के लिए 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 फ़ोल्डर में पाई जा सकती है
• लक्ष्य को डीबग करने के लिए इसका उपयोग करें (अनुशंसित नहीं):

# On target
/data/local/tmp/gdbserver 0.0.0.0:1234 --attach $(ps -A | grep -i "com.android.bluetooth" | awk '{print $2}')

# On host
adb forward tcp:1234 tcp:1234
gdb-multiarch -q -x ./gdbinit

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

# On host
adb push ./gdbinit /data/local/tmp/gdbinit

# On target
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}') 
# OR
/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 ऑब्जेक्ट के vtables को संशोधित करता है:

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

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

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