macOS xpc_connection_get_audit_token Attack
For further information check the original post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. This is a summary:
Mach Messages Basic Info
यदि आप नहीं जानते कि Mach Messages क्या हैं, तो इस पृष्ठ की जांच करें:
macOS IPC - Inter Process Communicationइस समय याद रखें कि (यहाँ से परिभाषा): Mach संदेश एक mach पोर्ट के माध्यम से भेजे जाते हैं, जो mach कर्नेल में निर्मित एक एकल रिसीवर, कई प्रेषक संचार चैनल है। कई प्रक्रियाएँ संदेश भेज सकती हैं एक mach पोर्ट पर, लेकिन किसी भी समय केवल एकल प्रक्रिया ही इसे पढ़ सकती है। फ़ाइल वर्णनकर्ताओं और सॉकेट की तरह, mach पोर्ट कर्नेल द्वारा आवंटित और प्रबंधित होते हैं और प्रक्रियाएँ केवल एक पूर्णांक देखती हैं, जिसका वे उपयोग करके कर्नेल को यह संकेत दे सकते हैं कि वे अपने किस mach पोर्ट का उपयोग करना चाहते हैं।
XPC Connection
यदि आप नहीं जानते कि XPC कनेक्शन कैसे स्थापित किया जाता है, तो जांचें:
macOS XPCVuln Summary
आपके लिए जानना दिलचस्प है कि XPC का अमूर्तता एक-से-एक कनेक्शन है, लेकिन यह एक ऐसी तकनीक के शीर्ष पर आधारित है जिसमें कई प्रेषक हो सकते हैं, इसलिए:
Mach पोर्ट एकल रिसीवर, कई प्रेषक हैं।
एक XPC कनेक्शन का ऑडिट टोकन हाल ही में प्राप्त संदेश से कॉपी किया गया ऑडिट टोकन है।
एक XPC कनेक्शन का ऑडिट टोकन प्राप्त करना कई सुरक्षा जांचों के लिए महत्वपूर्ण है।
हालांकि पिछली स्थिति आशाजनक लगती है, कुछ परिदृश्य हैं जहाँ यह समस्याएँ उत्पन्न नहीं करेगा (यहाँ से):
ऑडिट टोकन अक्सर एक प्राधिकरण जांच के लिए उपयोग किए जाते हैं यह तय करने के लिए कि कनेक्शन स्वीकार करना है या नहीं। चूंकि यह सेवा पोर्ट पर एक संदेश का उपयोग करके होता है, इसलिए अभी तक कोई कनेक्शन स्थापित नहीं हुआ है। इस पोर्ट पर अधिक संदेश केवल अतिरिक्त कनेक्शन अनुरोधों के रूप में संभाले जाएंगे। इसलिए कनेक्शन स्वीकार करने से पहले कोई भी जांचें कमजोर नहीं हैं (इसका मतलब यह भी है कि
-listener:shouldAcceptNewConnection:के भीतर ऑडिट टोकन सुरक्षित है)। इसलिए हम विशिष्ट क्रियाओं की पुष्टि करने वाले XPC कनेक्शनों की तलाश कर रहे हैं।XPC इवेंट हैंडलर समकालिक रूप से संभाले जाते हैं। इसका मतलब है कि एक संदेश के लिए इवेंट हैंडलर को अगले के लिए कॉल करने से पहले पूरा होना चाहिए, यहां तक कि समवर्ती डिस्पैच कतारों पर भी। इसलिए एक XPC इवेंट हैंडलर के भीतर ऑडिट टोकन को अन्य सामान्य (गैर-प्रतिक्रिया!) संदेशों द्वारा अधिलेखित नहीं किया जा सकता है।
यह दो अलग-अलग तरीकों से शोषण किया जा सकता है:
Variant1:
शोषण सेवा A और सेवा B से जुड़ता है
सेवा B सेवा A में एक विशिष्ट कार्यक्षमता को कॉल कर सकती है जिसे उपयोगकर्ता नहीं कर सकता
सेवा A
xpc_connection_get_audit_tokenको कॉल करती है जबकि नहीं एक कनेक्शन के लिए इवेंट हैंडलर के भीतर एकdispatch_asyncमें।इसलिए एक अलग संदेश ऑडिट टोकन को अधिलेखित कर सकता है क्योंकि इसे इवेंट हैंडलर के बाहर असिंक्रोनस रूप से भेजा जा रहा है।
शोषण सेवा B को सेवा A के लिए SEND अधिकार देता है।
इसलिए svc B वास्तव में सेवा A को संदेश भेजेगा।
शोषण विशिष्ट क्रिया को कॉल करने की कोशिश करता है। एक RC svc A इस क्रिया के प्राधिकरण की जांच करता है जबकि svc B ने ऑडिट टोकन को अधिलेखित किया (शोषण को विशेष क्रिया को कॉल करने की अनुमति देता है)।
Variant 2:
सेवा B सेवा A में एक विशिष्ट कार्यक्षमता को कॉल कर सकती है जिसे उपयोगकर्ता नहीं कर सकता
शोषण सेवा A से जुड़ता है जो शोषण को एक संदेश भेजता है जो एक प्रतिक्रिया की अपेक्षा करता है एक विशिष्ट प्रतिक्रिया पोर्ट में।
शोषण सेवा B को एक संदेश भेजता है जो उस प्रतिक्रिया पोर्ट को पास करता है।
जब सेवा B प्रतिक्रिया देती है, यह सेवा A को संदेश भेजती है, जबकि शोषण सेवा A को एक अलग संदेश भेजता है जो एक विशिष्ट कार्यक्षमता को प्राप्त करने की कोशिश कर रहा है और उम्मीद कर रहा है कि सेवा B से प्रतिक्रिया ऑडिट टोकन को सही समय पर अधिलेखित करेगी (रेस कंडीशन)।
Variant 1: calling xpc_connection_get_audit_token outside of an event handler
परिदृश्य:
दो mach सेवाएँ
AऔरBजिनसे हम दोनों कनेक्ट कर सकते हैं (सैंडबॉक्स प्रोफ़ाइल और कनेक्शन स्वीकार करने से पहले प्राधिकरण जांच के आधार पर)।A को एक प्राधिकरण जांच होनी चाहिए एक विशिष्ट क्रिया के लिए जिसे
Bपास कर सकता है (लेकिन हमारा ऐप नहीं)।उदाहरण के लिए, यदि B के पास कुछ अधिकार हैं या यह रूट के रूप में चल रहा है, तो यह उसे A से एक विशेष क्रिया करने के लिए कहने की अनुमति दे सकता है।
इस प्राधिकरण जांच के लिए,
Aअसिंक्रोनस रूप से ऑडिट टोकन प्राप्त करता है, उदाहरण के लिएdispatch_asyncसेxpc_connection_get_audit_tokenको कॉल करके।
इस मामले में एक हमलावर एक रेस कंडीशन को ट्रिगर कर सकता है जिससे एक शोषण होता है जो A से एक क्रिया करने के लिए कहता है कई बार जबकि B A को संदेश भेजता है। जब RC सफल होता है, तो B का ऑडिट टोकन मेमोरी में कॉपी किया जाएगा जबकि हमारे शोषण का अनुरोध A द्वारा संभाला जा रहा है, जिससे इसे विशेष क्रिया तक पहुँचने की अनुमति मिलती है जिसे केवल B अनुरोध कर सकता था।
यह A के रूप में smd और B के रूप में diagnosticd के साथ हुआ। फ़ंक्शन SMJobBless को एक नया विशेष सहायक टूल स्थापित करने के लिए (जैसे रूट के रूप में) उपयोग किया जा सकता है। यदि कोई रूट के रूप में चलने वाली प्रक्रिया smd से संपर्क करती है, तो कोई अन्य जांच नहीं की जाएगी।
इसलिए, सेवा B diagnosticd है क्योंकि यह रूट के रूप में चलती है और एक प्रक्रिया की निगरानी के लिए उपयोग की जा सकती है, इसलिए एक बार निगरानी शुरू होने पर, यह प्रति सेकंड कई संदेश भेजेगी।
हमले को करने के लिए:
मानक XPC प्रोटोकॉल का उपयोग करके
smdनामक सेवा से एक कनेक्शन प्रारंभ करें।diagnosticdसे एक द्वितीयक कनेक्शन बनाएं। सामान्य प्रक्रिया के विपरीत, दो नए mach पोर्ट बनाने और भेजने के बजाय, क्लाइंट पोर्ट भेजने का अधिकारsmdकनेक्शन से जुड़े send right की एक डुप्लिकेट के साथ प्रतिस्थापित किया जाता है।परिणामस्वरूप, XPC संदेश
diagnosticdको भेजे जा सकते हैं, लेकिनdiagnosticdसे प्रतिक्रियाएँsmdपर पुनः मार्गित की जाती हैं।smdके लिए, ऐसा प्रतीत होता है कि उपयोगकर्ता औरdiagnosticdदोनों से संदेश एक ही कनेक्शन से उत्पन्न हो रहे हैं।
अगला कदम
diagnosticdको एक चुनी हुई प्रक्रिया (संभवतः उपयोगकर्ता की अपनी) की निगरानी शुरू करने के लिए निर्देशित करना है। साथ ही,smdको नियमित 1004 संदेशों की बाढ़ भेजी जाती है। यहाँ उद्देश्य एक उच्च विशेषाधिकार के साथ एक टूल स्थापित करना है।यह क्रिया
handle_blessफ़ंक्शन के भीतर एक रेस कंडीशन को ट्रिगर करती है। समय महत्वपूर्ण है:xpc_connection_get_pidफ़ंक्शन कॉल को उपयोगकर्ता की प्रक्रिया का PID लौटाना चाहिए (क्योंकि विशेषाधिकार प्राप्त टूल उपयोगकर्ता के ऐप बंडल में स्थित है)। हालाँकि,xpc_connection_get_audit_tokenफ़ंक्शन, विशेष रूप सेconnection_is_authorizedउपरूटीन के भीतर, कोdiagnosticdके ऑडिट टोकन का संदर्भ देना चाहिए।
Variant 2: reply forwarding
एक XPC (क्रॉस-प्रोसेस संचार) वातावरण में, हालांकि इवेंट हैंडलर समवर्ती रूप से निष्पादित नहीं होते हैं, प्रतिक्रिया संदेशों को संभालने का एक अनूठा व्यवहार होता है। विशेष रूप से, संदेश भेजने के लिए दो अलग-अलग तरीके हैं जो एक प्रतिक्रिया की अपेक्षा करते हैं:
xpc_connection_send_message_with_reply: यहाँ, XPC संदेश को एक निर्दिष्ट कतार पर प्राप्त और संसाधित किया जाता है।xpc_connection_send_message_with_reply_sync: इसके विपरीत, इस विधि में, XPC संदेश को वर्तमान डिस्पैच कतार पर प्राप्त और संसाधित किया जाता है।
यह भेद महत्वपूर्ण है क्योंकि यह प्रतिक्रिया पैकेटों के XPC इवेंट हैंडलर के निष्पादन के साथ समवर्ती रूप से पार्स होने की संभावना की अनुमति देता है। विशेष रूप से, जबकि _xpc_connection_set_creds आंशिक रूप से ऑडिट टोकन के अधिलेखन से बचाने के लिए लॉकिंग लागू करता है, यह पूरे कनेक्शन ऑब्जेक्ट के लिए इस सुरक्षा को बढ़ाता नहीं है। परिणामस्वरूप, यह एक कमजोर स्थिति उत्पन्न करता है जहाँ ऑडिट टोकन को एक पैकेट के पार्सिंग और इसके इवेंट हैंडलर के निष्पादन के बीच के अंतराल के दौरान प्रतिस्थापित किया जा सकता है।
इस कमजोर स्थिति का शोषण करने के लिए, निम्नलिखित सेटअप की आवश्यकता है:
दो mach सेवाएँ, जिन्हें
AऔरBकहा जाता है, जिनसे कनेक्शन स्थापित किया जा सकता है।सेवा
Aको एक विशिष्ट क्रिया के लिए एक प्राधिकरण जांच शामिल करनी चाहिए जिसे केवलBकर सकता है (उपयोगकर्ता का एप्लिकेशन नहीं कर सकता)।सेवा
Aको एक संदेश भेजना चाहिए जो एक प्रतिक्रिया की अपेक्षा करता है।उपयोगकर्ता
Bको एक संदेश भेज सकता है जिसका वह उत्तर देगा।
शोषण प्रक्रिया में निम्नलिखित चरण शामिल हैं:
सेवा
Aके एक संदेश का इंतज़ार करें जो एक प्रतिक्रिया की अपेक्षा करता है।Aको सीधे उत्तर देने के बजाय, प्रतिक्रिया पोर्ट को हाईजैक किया जाता है और सेवाBको एक संदेश भेजने के लिए उपयोग किया जाता है।इसके बाद, एक संदेश जो निषिद्ध क्रिया से संबंधित है, भेजा जाता है, यह अपेक्षा करते हुए कि इसे
Bसे प्रतिक्रिया के साथ समवर्ती रूप से संसाधित किया जाएगा।
नीचे वर्णित हमले के परिदृश्य का एक दृश्य प्रतिनिधित्व है:
 (1) (1) (1) (1) (1) (1).png)
Discovery Problems
Instances को खोजने में कठिनाइयाँ:
xpc_connection_get_audit_tokenके उपयोग के उदाहरणों को खोजने में चुनौती थी, दोनों स्थैतिक और गतिशील रूप से।पद्धति: Frida का उपयोग
xpc_connection_get_audit_tokenफ़ंक्शन को हुक करने के लिए किया गया, जो इवेंट हैंडलरों से उत्पन्न नहीं होने वाले कॉल को फ़िल्टर करता है। हालाँकि, यह विधि हुक की गई प्रक्रिया तक सीमित थी और सक्रिय उपयोग की आवश्यकता थी।विश्लेषण उपकरण: IDA/Ghidra जैसे उपकरणों का उपयोग पहुंच योग्य mach सेवाओं की जांच के लिए किया गया, लेकिन यह प्रक्रिया समय लेने वाली थी, जो dyld साझा कैश से संबंधित कॉल के कारण जटिल थी।
स्क्रिप्टिंग सीमाएँ:
dispatch_asyncब्लॉकों सेxpc_connection_get_audit_tokenके लिए कॉल के विश्लेषण के लिए स्क्रिप्टिंग करने के प्रयासों को ब्लॉकों के पार्सिंग और dyld साझा कैश के साथ इंटरैक्शन में जटिलताओं के कारण बाधित किया गया।
The fix
रिपोर्ट की गई समस्याएँ: Apple को
smdके भीतर पाए गए सामान्य और विशिष्ट मुद्दों का विवरण देने वाली एक रिपोर्ट प्रस्तुत की गई।Apple की प्रतिक्रिया: Apple ने
smdमें समस्या को संबोधित किया,xpc_connection_get_audit_tokenकोxpc_dictionary_get_audit_tokenसे प्रतिस्थापित किया।फिक्स की प्रकृति:
xpc_dictionary_get_audit_tokenफ़ंक्शन को सुरक्षित माना जाता है क्योंकि यह प्राप्त XPC संदेश से जुड़े mach संदेश से सीधे ऑडिट टोकन को प्राप्त करता है। हालाँकि, यह सार्वजनिक API का हिस्सा नहीं है, जैसेxpc_connection_get_audit_token।व्यापक फिक्स की अनुपस्थिति: यह स्पष्ट नहीं है कि Apple ने कनेक्शन के सहेजे गए ऑडिट टोकन के साथ मेल न खाने वाले संदेशों को अस्वीकार करने जैसे अधिक व्यापक फिक्स को लागू क्यों नहीं किया। कुछ परिदृश्यों (जैसे,
setuidका उपयोग) में वैध ऑडिट टोकन परिवर्तनों की संभावना एक कारक हो सकती है।वर्तमान स्थिति: यह समस्या iOS 17 और macOS 14 में बनी हुई है, जो इसे पहचानने और समझने की कोशिश करने वालों के लिए एक चुनौती प्रस्तुत करती है।
Last updated