macOS xpc_connection_get_audit_token Attack
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
For further information check the original post: https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/. This is a summary:
यदि आप नहीं जानते कि Mach Messages क्या हैं, तो इस पृष्ठ को देखना शुरू करें:
इस समय याद रखें कि (यहाँ से परिभाषा): Mach संदेश एक mach पोर्ट के माध्यम से भेजे जाते हैं, जो mach कर्नेल में निर्मित एक एकल रिसीवर, कई प्रेषक संचार चैनल है। कई प्रक्रियाएँ संदेश भेज सकती हैं एक mach पोर्ट पर, लेकिन किसी भी समय केवल एकल प्रक्रिया ही इसे पढ़ सकती है। फ़ाइल वर्णनकर्ताओं और सॉकेट की तरह, mach पोर्ट को कर्नेल द्वारा आवंटित और प्रबंधित किया जाता है और प्रक्रियाएँ केवल एक पूर्णांक देखती हैं, जिसका वे उपयोग कर सकते हैं यह इंगित करने के लिए कि वे अपने किस mach पोर्ट का उपयोग करना चाहते हैं।
यदि आप नहीं जानते कि XPC कनेक्शन कैसे स्थापित किया जाता है, तो देखें:
आपके लिए जानना दिलचस्प है कि 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 से प्रतिक्रिया ऑडिट टोकन को सही समय पर अधिलेखित कर देगी (रेस कंडीशन)।
परिदृश्य:
दो 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 से संबंधित ऑडिट टोकन का संदर्भ देना चाहिए।
एक 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)
Instances को खोजने में कठिनाइयाँ: xpc_connection_get_audit_token के उपयोग के उदाहरणों को खोजने में चुनौती थी, दोनों स्थैतिक और गतिशील रूप से।
पद्धति: Frida का उपयोग xpc_connection_get_audit_token फ़ंक्शन को हुक करने के लिए किया गया, जो इवेंट हैंडलरों से उत्पन्न नहीं होने वाले कॉल को फ़िल्टर करता है। हालाँकि, यह विधि हुक की गई प्रक्रिया तक सीमित थी और सक्रिय उपयोग की आवश्यकता थी।
विश्लेषण उपकरण: IDA/Ghidra जैसे उपकरणों का उपयोग पहुंच योग्य mach सेवाओं की जांच के लिए किया गया, लेकिन यह प्रक्रिया समय लेने वाली थी, जो dyld साझा कैश से संबंधित कॉल के कारण जटिल हो गई।
स्क्रिप्टिंग सीमाएँ: dispatch_async ब्लॉकों से xpc_connection_get_audit_token के लिए कॉल के विश्लेषण के लिए स्क्रिप्टिंग करने के प्रयासों को ब्लॉकों के पार्सिंग और dyld साझा कैश के साथ इंटरैक्शन में जटिलताओं के कारण बाधित किया गया।
रिपोर्ट की गई समस्याएँ: 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 में बनी हुई है, जो इसे पहचानने और समझने की कोशिश करने वालों के लिए एक चुनौती प्रस्तुत करती है।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
