macOS xpc_connection_get_audit_token Attack

Reading time: 11 minutes

अधिक जानकारी के लिए मूल पोस्ट देखें: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. यह एक सारांश है:

Mach Messages Basic Info

यदि आप नहीं जानते कि Mach Messages क्या हैं, तो इस पृष्ठ की जांच करें:

macOS IPC - Inter Process Communication

इस समय याद रखें कि (यहां से परिभाषा):
Mach संदेश एक mach port के माध्यम से भेजे जाते हैं, जो mach kernel में निर्मित एक एकल रिसीवर, कई प्रेषक संचार चैनल है। कई प्रक्रियाएँ संदेश भेज सकती हैं एक mach port पर, लेकिन किसी भी समय केवल एकल प्रक्रिया ही इसे पढ़ सकती है। फ़ाइल वर्णनकर्ताओं और सॉकेट की तरह, mach ports को kernel द्वारा आवंटित और प्रबंधित किया जाता है और प्रक्रियाएँ केवल एक पूर्णांक देखती हैं, जिसका वे उपयोग कर सकते हैं यह इंगित करने के लिए कि वे अपने किस mach ports का उपयोग करना चाहते हैं।

XPC Connection

यदि आप नहीं जानते कि XPC कनेक्शन कैसे स्थापित किया जाता है, तो जांचें:

macOS XPC

Vuln Summary

आपके लिए जानना दिलचस्प है कि XPC का अमूर्तता एक-से-एक कनेक्शन है, लेकिन यह एक ऐसी तकनीक के शीर्ष पर आधारित है जिसमें कई प्रेषक हो सकते हैं, इसलिए:

• Mach ports एकल रिसीवर, कई प्रेषक हैं।
• एक XPC कनेक्शन का ऑडिट टोकन हाल ही में प्राप्त संदेश से कॉपी किया गया ऑडिट टोकन है।
• एक XPC कनेक्शन का ऑडिट टोकन प्राप्त करना कई सुरक्षा जांचों के लिए महत्वपूर्ण है।

हालांकि पिछली स्थिति आशाजनक लगती है, कुछ परिदृश्य हैं जहां यह समस्याएँ उत्पन्न नहीं करेगा (यहां से):

• ऑडिट टोकन अक्सर एक प्राधिकरण जांच के लिए उपयोग किए जाते हैं यह तय करने के लिए कि कनेक्शन स्वीकार करना है या नहीं। चूंकि यह सेवा पोर्ट पर एक संदेश का उपयोग करके होता है, इसलिए अभी तक कोई कनेक्शन स्थापित नहीं हुआ है। इस पोर्ट पर अधिक संदेश केवल अतिरिक्त कनेक्शन अनुरोधों के रूप में संभाले जाएंगे। इसलिए कनेक्शन स्वीकार करने से पहले कोई भी जांच कमजोर नहीं है (इसका मतलब यह भी है कि -listener:shouldAcceptNewConnection: के भीतर ऑडिट टोकन सुरक्षित है)। इसलिए हम विशिष्ट क्रियाओं की पुष्टि करने वाले XPC कनेक्शनों की तलाश कर रहे हैं।
• XPC इवेंट हैंडलर समकालिक रूप से संभाले जाते हैं। इसका मतलब है कि एक संदेश के लिए इवेंट हैंडलर को अगले के लिए कॉल करने से पहले पूरा किया जाना चाहिए, यहां तक कि समवर्ती डिस्पैच कतारों पर भी। इसलिए एक XPC इवेंट हैंडलर के भीतर ऑडिट टोकन को अन्य सामान्य (गैर-प्रतिक्रिया!) संदेशों द्वारा अधिलेखित नहीं किया जा सकता।

यह दो अलग-अलग तरीकों से शोषण किया जा सकता है:

1. Variant1:

• शोषण सेवा A और सेवा B से जुड़ता है
• सेवा B सेवा A में एक विशिष्ट कार्यक्षमता को कॉल कर सकता है जिसे उपयोगकर्ता नहीं कर सकता
• सेवा A xpc_connection_get_audit_token को कॉल करता है जबकि नहीं एक कनेक्शन के लिए इवेंट हैंडलर के भीतर एक dispatch_async में।
• इसलिए एक अलग संदेश ऑडिट टोकन को अधिलेखित कर सकता है क्योंकि इसे इवेंट हैंडलर के बाहर असमय भेजा जा रहा है।
• शोषण सेवा B को सेवा A के लिए SEND अधिकार देता है।
• इसलिए svc B वास्तव में सेवा A को संदेश भेज रहा होगा।
• शोषण विशिष्ट क्रिया को कॉल करने की कोशिश करता है। एक RC svc A इस क्रिया के प्राधिकरण की जांच करता है जबकि svc B ने ऑडिट टोकन को अधिलेखित किया (शोषण को विशेष क्रिया को कॉल करने की अनुमति देता है)।

2. 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 के रूप में smd और B के रूप में diagnosticd के साथ हुआ। SMJobBless फ़ंक्शन का उपयोग एक नए विशेष सहायक टूल को स्थापित करने के लिए किया जा सकता है (जैसे रूट)। यदि कोई रूट के रूप में चलने वाली प्रक्रिया smd से संपर्क करती है, तो कोई अन्य जांच नहीं की जाएगी।

इसलिए, सेवा B diagnosticd है क्योंकि यह रूट के रूप में चलती है और एक प्रक्रिया की निगरानी के लिए उपयोग की जा सकती है, इसलिए एक बार निगरानी शुरू होने पर, यह प्रति सेकंड कई संदेश भेजेगी।

हमले को करने के लिए:

1. मानक XPC प्रोटोकॉल का उपयोग करके smd नामक सेवा से कनेक्शन प्रारंभ करें।
2. diagnosticd से एक द्वितीयक कनेक्शन बनाएं। सामान्य प्रक्रिया के विपरीत, दो नए mach ports बनाने और भेजने के बजाय, क्लाइंट पोर्ट भेजने के अधिकार को smd कनेक्शन से जुड़े send right की एक डुप्लिकेट के साथ प्रतिस्थापित किया जाता है।
3. परिणामस्वरूप, XPC संदेश diagnosticd को भेजे जा सकते हैं, लेकिन diagnosticd से प्रतिक्रियाएँ smd को पुनः मार्गित की जाती हैं। smd के लिए, ऐसा प्रतीत होता है कि उपयोगकर्ता और diagnosticd दोनों से संदेश एक ही कनेक्शन से उत्पन्न हो रहे हैं।

4. अगला कदम diagnosticd को एक चुनी हुई प्रक्रिया (संभवतः उपयोगकर्ता की अपनी) की निगरानी शुरू करने के लिए निर्देशित करना है। साथ ही, smd को नियमित 1004 संदेशों की बाढ़ भेजी जाती है। यहाँ उद्देश्य एक उच्च विशेषाधिकार के साथ एक टूल स्थापित करना है।
5. यह क्रिया handle_bless फ़ंक्शन के भीतर एक रेस कंडीशन को ट्रिगर करती है। समय महत्वपूर्ण है: xpc_connection_get_pid फ़ंक्शन कॉल को उपयोगकर्ता की प्रक्रिया का PID लौटाना चाहिए (क्योंकि विशेषाधिकार प्राप्त टूल उपयोगकर्ता के ऐप बंडल में स्थित है)। हालाँकि, xpc_connection_get_audit_token फ़ंक्शन, विशेष रूप से connection_is_authorized उपरूटीन के भीतर, को diagnosticd से संबंधित ऑडिट टोकन का संदर्भ देना चाहिए।

Variant 2: reply forwarding

एक XPC (क्रॉस-प्रोसेस संचार) वातावरण में, हालांकि इवेंट हैंडलर समवर्ती रूप से निष्पादित नहीं होते हैं, प्रतिक्रिया संदेशों को संभालने का एक अनूठा व्यवहार होता है। विशेष रूप से, संदेश भेजने के लिए दो अलग-अलग तरीके हैं जो एक प्रतिक्रिया की अपेक्षा करते हैं:

1. xpc_connection_send_message_with_reply: यहाँ, XPC संदेश को एक निर्दिष्ट कतार पर प्राप्त और संसाधित किया जाता है।
2. xpc_connection_send_message_with_reply_sync: इसके विपरीत, इस विधि में, XPC संदेश को वर्तमान डिस्पैच कतार पर प्राप्त और संसाधित किया जाता है।

यह भेद महत्वपूर्ण है क्योंकि यह प्रतिक्रिया पैकेटों के XPC इवेंट हैंडलर के निष्पादन के साथ समवर्ती रूप से पार्स होने की संभावना की अनुमति देता है। विशेष रूप से, जबकि _xpc_connection_set_creds आंशिक रूप से ऑडिट टोकन के अधिलेखन से बचाने के लिए लॉकिंग लागू करता है, यह पूरे कनेक्शन ऑब्जेक्ट के लिए इस सुरक्षा को नहीं बढ़ाता है। परिणामस्वरूप, यह एक कमजोर स्थिति उत्पन्न करता है जहाँ ऑडिट टोकन को एक पैकेट के पार्सिंग और इसके इवेंट हैंडलर के निष्पादन के बीच के अंतराल के दौरान प्रतिस्थापित किया जा सकता है।

इस कमजोर स्थिति का शोषण करने के लिए, निम्नलिखित सेटअप की आवश्यकता है:

• दो mach सेवाएँ, जिन्हें A और B कहा जाता है, जिनसे दोनों कनेक्शन स्थापित कर सकते हैं।
• सेवा A को एक विशिष्ट क्रिया के लिए एक प्राधिकरण जांच शामिल करनी चाहिए जिसे केवल B कर सकता है (उपयोगकर्ता का ऐप नहीं)।
• सेवा A को एक संदेश भेजना चाहिए जो एक प्रतिक्रिया की अपेक्षा करता है।
• उपयोगकर्ता B को एक संदेश भेज सकता है जिसका वह उत्तर देगा।

शोषण प्रक्रिया में निम्नलिखित चरण शामिल हैं:

1. सेवा A के एक संदेश का इंतजार करें जो एक प्रतिक्रिया की अपेक्षा करता है।
2. A को सीधे प्रतिक्रिया देने के बजाय, प्रतिक्रिया पोर्ट को हाईजैक किया जाता है और सेवा B को एक संदेश भेजने के लिए उपयोग किया जाता है।
3. इसके बाद, एक संदेश जो निषिद्ध क्रिया से संबंधित है, भेजा जाता है, यह अपेक्षा करते हुए कि इसे B से प्रतिक्रिया के साथ समवर्ती रूप से संसाधित किया जाएगा।

नीचे वर्णित हमले के परिदृश्य का एक दृश्य प्रतिनिधित्व है:

 (1) (1) (1) (1) (1) (1).png)

Discovery Problems

• उदाहरणों को खोजने में कठिनाइयाँ: xpc_connection_get_audit_token के उपयोग के उदाहरणों को खोजने में चुनौती थी, दोनों स्थैतिक और गतिशील रूप से।
• पद्धति: Frida का उपयोग xpc_connection_get_audit_token फ़ंक्शन को हुक करने के लिए किया गया, जो इवेंट हैंडलरों से उत्पन्न नहीं होने वाले कॉल को फ़िल्टर करता है। हालाँकि, यह विधि हुक की गई प्रक्रिया तक सीमित थी और सक्रिय उपयोग की आवश्यकता थी।
• विश्लेषण उपकरण: पहुँच योग्य mach सेवाओं की जांच के लिए IDA/Ghidra जैसे उपकरणों का उपयोग किया गया, लेकिन यह प्रक्रिया समय लेने वाली थी, जो 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 में बनी हुई है, जो इसे पहचानने और समझने की कोशिश करने वालों के लिए एक चुनौती प्रस्तुत करती है।