metaredteam/rtx-cve-2023-45779Android APEX key reuse vulnerability के लिए प्रूफ-ऑफ-कॉन्सेप्ट कोड
यह रिपॉजिटरी AS IS प्रदान की गई है ताकि एक मेटा रेड टीम X भेद्यता प्रकटीकरण के साथ हो। यह कोई आधिकारिक मेटा प्रोजेक्ट नहीं है और इसका समर्थन एक आधिकारिक प्रोजेक्ट की तरह नहीं किया जाएगा।
स्क्रिप्ट्स और आर्टिफैक्ट्स का एक सेट जो Android उपकरणों का पता लगाने और उनका शोषण करने का प्रदर्शन करता है जो AOSP से टेस्ट कुंजियों के साथ हस्ताक्षरित APEXes शिप करते हैं। समस्या के पूर्ण विवरण के लिए हमारी ब्लॉग पोस्ट "Missing signs: how several brands forgot to secure a key piece of Android" देखें।
apex-checker/: ज्ञात परीक्षण कुंजियों के डाइजेस्ट को सहेजने और उन कुंजियों से हस्ताक्षर के लिए APEXes की जांच करने के लिए Bash स्क्रिप्ट्स का एक सेट।apex-forger/: AOSP के apexer और deapexer उपकरणों के चारों ओर हल्के रैपर जो APEX को अनपैक, संशोधित और पुनः पैक करना आसान बनाते हैं। APEXes के लिए apktool की तरह।vndk-libt/: एक लाइब्रेरी के लिए स्रोत कोड जिसे हमने एक संवेदनशील APEX में जोड़ा ताकि साबित किया जा सके कि हम कोड निष्पादन प्राप्त कर सकते हैं। यह केवल प्रत्येक प्रक्रिया की कमांड लाइन को प्रिंट करता है जो इसे logcat में लोड करता है।m apexer deapexer apksigner चलाएँ।envsetup.sh (यहाँ वाला, AOSP वाला नहीं) को अपडेट करें ताकि $AOSP और $ANDROID_HOST_OUT उपयुक्त स्थानों की ओर इंगित करें।adb shell getprop ro.build.version.sdk और adb shell getprop ro.vndk.version चलाएँ।adb pull /system/apex/com.android.vndk.current.apex vndk.apex। यदि नहीं, तो adb pull /system_ext/apex/com.android.vndk.v<NN>.apex vndk.apex, जहाँ <NN> ro.vndk.version है।apex-checker/check.sh vndk.apex के साथ जाँच करें कि APEX संवेदनशील है या नहीं। यदि आउटपुट "OI" से शुरू नहीं होता है (जो दर्शाता है कि दोनों बाहरी और आंतरिक हस्ताक्षर परीक्षण कुंजियों से हैं), तो यह PoC का उपयोग नहीं किया जा सकता (हालांकि यह गारंटी नहीं देता कि उपकरण सुरक्षित है, क्योंकि अन्य APEXes अभी भी संवेदनशील हो सकते हैं)।apex-checker/apk-keys.txt और apex-checker/avb-keys.txt में हैश निम्नलिखित APEXes के लिए बाहरी और आंतरिक परीक्षण कुंजियों के अनुरूप हैं। ध्यान दें कि उन दो सूचियों के -goog वेरिएंट भी हैं, जो हमारी प्रारंभिक रिपोर्ट के बाद Google द्वारा बनाए गए थे। वे सूचियाँ आम तौर पर अधिक पूर्ण हैं, लेकिन हम ठीक से नहीं जानते कि उनमें कौन सी कुंजियाँ हैं।
apex-forger/unpack.sh vndk.apex vndk के साथ APEX को अनपैक करें।libt.so को लोड करने के लिए libutils.so को पैच करने का प्रयास करें: git apply --directory=vndk vndk-libt/libutils-v31.patch। यदि यह काम नहीं करता है (जैसे अलग VNDK संस्करण), तो vndk/payload/lib64/libutils.so के उपयुक्त DT_NEEDED में libc.so को libt.so में मैन्युअल रूप से बदलने के लिए हेक्स एडिटर का उपयोग करें।vndk-libt/ के अंदर ndk-build चलाकर libt.so बनाएँ। vndk-libt/libs/arm64-v8a/libt.so को vndk/payload/lib64/libt.so पर कॉपी करें।apex_build_info.bp से canned_fs_config निकालें। इसे आसानी से करने का कोई उपकरण नहीं है: सबसे निकटतम protoc --decode_raw <vndk/apex_build_info.bp है और उसके बाद मैन्युअल रूप से फ़ील्ड #3 को अनएस्केप करना। canned_fs_config को vndk/ में रखें।canned_fs_config में अन्य सभी की तरह /lib64/libt.so के लिए एक पंक्ति जोड़ें।apex-forger/repack.sh vndk com.android.vndk.v<NN>.{pem,pubkey,pk8,x509.pem} के साथ APEX को पुनः पैक करें।adb install vndk/forged.apex चलाएँ।adb reboot && adb logcat -s RTXPoC:D चलाएँ।RTXPoC लॉग संदेश देखें, प्रत्येक उस प्रक्रिया से जिसमें हम कोड निष्पादित कर सकते हैं।