मैं Apple बन सकता हूं, और आप भी

तृतीय-पक्ष भेद्यता पर हस्ताक्षर करने वाले Apple कोड का सार्वजनिक प्रकटीकरण

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

सारांश

• हस्ताक्षर कोड के लिए तृतीय-पक्ष API द्वारा उपयोग किया गया एक चक्कर मिला, जो आपको Apple द्वारा हस्ताक्षरित किसी भी कोड को प्रस्तुत करने की अनुमति देता है।
• सभी प्रसिद्ध खुला स्रोत विक्रेताओं और परियोजनाओं को सूचित किया जाता है (नीचे सूची देखें)। उनके लिए पैच उपलब्ध हैं।
• एक मौका है कि समस्या अन्य तृतीय-पक्ष कार्यक्रमों को प्रभावित करती है जो ऐप्पल के आधिकारिक कोड साइनिंग एपीआई का उपयोग करते हैं।
• डेवलपर्स एपीआई पर हस्ताक्षर करने वाले कोड के उचित उपयोग के लिए जिम्मेदार हैं। परीक्षणों के लिए डेमो हैकिंग टूल (PoC) हैं।
• केवल MacOS और OSX के पुराने संस्करणों पर लागू होता है।

प्रभावित विक्रेताओं

• VirusTotal - CVE-2018-10408
• Google - सांता, मॉलकोडाइनसकैचर - CVE-2018-10405
• फेसबुक - OSQuery - CVE-2018-6336
• उद्देश्य विकास - LittleSnitch - CVE-2018-10470
• एफ-सिक्योर - xFence (लिटिलफ़्लकर) CVE-2018-10403
• उद्देश्य-देखें - WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (और अन्य) - CVE-2018-10404
• येल्प - OSXCollector - CVE-2018-10406
• कार्बन ब्लैक - सीबी प्रतिक्रिया - CVE-2018-10407

कोड साइनिंग का महत्व और यह macOS / iOS पर कैसे काम करता है

कोड हस्ताक्षर एक सुरक्षा निर्माण है जो सार्वजनिक कुंजी बुनियादी ढांचे (PKI) का उपयोग डिजिटल रूप से संकलित कोड या यहां तक ​​कि स्क्रिप्ट पर हस्ताक्षर करने के लिए सुनिश्चित करता है कि यह विश्वसनीय है और कोड प्रामाणिक है। विंडोज पर, आप क्रिप्टोग्राफिक रूप से लगभग कुछ भी साइन इन कर सकते हैं: .NET बायनेरी से लेकर पॉवरशेल स्क्रिप्ट तक। MacOS / iOS पर, कोड साइनिंग मुख्य रूप से मैक-ओ बायनेरिज़ और एप्लिकेशन पैकेजों को संदर्भित करता है, केवल विश्वसनीय कोड को मेमोरी में निष्पादित करने की अनुमति देता है।

एंटीवायरस, सुरक्षा प्रणाली और घटना की प्रतिक्रिया, साथ ही फोरेंसिक उपकरण हस्ताक्षर का विश्लेषण करते हैं ताकि अविश्वासियों के बीच विश्वसनीय कोड की पहचान हो सके। हस्ताक्षर सत्यापन विश्लेषण को गति देता है। विभिन्न उपकरण सुरक्षा उपायों को लागू करने के लिए कोड साइनिंग जानकारी का उपयोग करते हैं: ये श्वेतसूची, एंटीवायरस, घटना की प्रतिक्रिया और खतरे की खोज प्रणाली हैं। लोकप्रिय ओएस में से किसी एक में कोड हस्ताक्षर से समझौता करने का मतलब बुनियादी सुरक्षा निर्माण को कमजोर करना है, जिस पर कई नियमित सूचना सुरक्षा संचालन निर्भर करते हैं।

कोड हस्ताक्षर ( 1 , 2 , 3 , 4 , 5 ) में समस्याएं पहले से ही पाई गई थीं। पिछले कुछ कार्यों के विपरीत, इस भेद्यता के लिए व्यवस्थापक अधिकारों की आवश्यकता नहीं होती है, इसके लिए कोड हस्ताक्षर सत्यापन को बायपास करने के लिए JIT कोड या मेमोरी भ्रष्टाचार की आवश्यकता नहीं होती है। आप सभी की जरूरत है एक सही ढंग से स्वरूपित फैट / यूनिवर्सल फ़ाइल है, और कोड हस्ताक्षर का सत्यापन एक वैध परिणाम दिखाएगा।

भेद्यता विवरण

भेद्यता का सार यह है कि माच-ओ लोडर और कोड साइनिंग एपीआई का उपयोग कोड हस्ताक्षर को गलत तरीके से सत्यापित करने के लिए नहीं किया जाता है। विशेष रूप से तैयार की गई यूनिवर्सल / फैट बाइनरी का उपयोग करके इस अंतर का फायदा उठाया जा सकता है।

एक मोटी / सार्वभौमिक फ़ाइल क्या है?

फैट / यूनिवर्सल एक द्विआधारी प्रारूप है जिसमें कई मच-ओ फाइलें (निष्पादन योग्य फ़ाइल, डाइल्ड या पैकेज) शामिल हैं, जिनमें से प्रत्येक एक विशिष्ट सीपीयू वास्तुकला (उदाहरण के लिए, i386, x86_64 या पीपीसी) के लिए उन्मुख है।

आवश्यक शर्तें

• फैट / यूनिवर्सल फ़ाइल में पहले माच-ओ को Apple द्वारा हस्ताक्षरित किया जाना चाहिए, यह एक i386, x86_64 फ़ाइल या यहां तक ​​कि PPC भी हो सकता है।
• MacOS x86_64 के लिए i386 के तहत एक स्व-हस्ताक्षरित दुर्भावनापूर्ण बाइनरी या एक्सट्रांसस कोड संकलित किया जाना चाहिए।
• Apple बाइनरी के फैट हेडर में CPU_TYPE को एक अमान्य प्रोसेसर प्रकार या प्रकार पर सेट किया जाना चाहिए जो होस्ट चिपसेट के लिए मूल नहीं है।

संबंधित SecRequirementRef और SecCSFlags को पास किए बिना, कोड हस्ताक्षर एपीआई ( SecCodeCheckValidity ) प्रोग्राम इंटरफ़ेस हस्ताक्षर की उत्पत्ति के लिए फैट / यूनिवर्सल फ़ाइल में पहले बाइनरी की जांच करेगा (उदाहरण के लिए, Apple) और हस्ताक्षर की प्रामाणिकता की पुष्टि करें। तब एपीआई टीम पहचानकर्ताओं के अनुपालन और हस्ताक्षर प्रामाणिकता के लिए फैट / यूनिवर्सल फ़ाइल में अन्य सभी बायनेरिज़ की जांच करेगा, लेकिन प्रमाणन प्राधिकरण के विश्वास की जड़ की जांच किए बिना । दुर्भावनापूर्ण कोड या "अहस्ताक्षरित" कोड i386 क्यों होना चाहिए इसका कारण यह है कि कोड साइनिंग एपीआई को मूल सीपीयू आर्किटेक्चर (x86_64) के लिए कोड हस्ताक्षर की जांच करने के लिए डिफ़ॉल्ट रूप से कॉन्फ़िगर किया गया है।

स्व-हस्ताक्षरित कोड परीक्षण को सफलतापूर्वक पास करने के कारणों में से एक है क्योंकि मुख्य Apple बायनेरिज़ में भी TeamIdentifier फ़ील्ड सेट not set । नीचे दिया गया चित्रण स्व-हस्ताक्षरित माच-ओ (ncat.i386) के बगल में Apple (python.x64) द्वारा हस्ताक्षरित मान्य मच-ओ बाइनरी को दर्शाता है। दोनों में `TeamIdentifier = set नहीं` है।



उदाहरण के लिए, मैंने डेवलपर आईडी का उपयोग करके बाइनरी पर हस्ताक्षर किए और लिपो में ऐप्पल बाइनरी को एक फैट / यूनिवर्सल फ़ाइल के साथ संयोजित करने का प्रयास किया। इस प्रकार का कोड हस्ताक्षर विफल रहता है।



मेरा प्रारंभिक PoC ncat (nmap से) है, जिसे मैंने ncat.frankenstein कहा है। यहां, परिणामस्वरूप फैट फ़ाइल में Apple हस्ताक्षरित अजगर x86_64 बाइनरी और ncat i386 स्व-हस्ताक्षरित (एडहॉक) बाइनरी है। एक स्व-हस्ताक्षरित बाइनरी आसानी से codesign -s - target_mach-o_or_fat_binary के साथ बनाई गई है। यहाँ यह कैसा दिखता है:



यदि आप इस फ़ाइल को चलाते हैं, तो अजगर x86_64 शुरू हो जाएगा:



और कोड हस्ताक्षर सत्यापित किया जा रहा है:



मैंने एनसीएटी स्व-हस्ताक्षरित बाइनरी कैसे चलाया?

यह एक अमान्य CPU_Type प्रकार या एक गैर-देशी CPU (उदाहरण के लिए, PPC) सेट करके किया जाता है। फिर माच-ओ लोडर माच-ओ बाइनरी को एक वैध हस्ताक्षर के साथ छोड़ देता है और दुर्भावनापूर्ण निष्पादित करता है (Apple द्वारा हस्ताक्षरित नहीं) कोड:



फिर ncat.frankenstein को निष्पादित किया जाता है, और सत्यापन परिणाम valid होगा:



हमने ncat.frankenstein और चार अन्य उदाहरण प्रकाशित किए ताकि डेवलपर्स अपने उत्पादों में कमजोरियों की जांच कर सकें।

सिफारिशें

कमांड लाइन पर

इस बात पर निर्भर करता है कि आप हस्ताक्षरित कोड को कैसे सत्यापित करते हैं। यदि आप कोडसाइन का उपयोग करते हैं, तो आप शायद निम्नलिखित आदेशों से परिचित हैं:

• codesign –dvvvv - प्रमाणन प्राधिकरण डंप और TeamIdentifier (डेवलपर आईडी)
• codesign –vv - सभी आर्किटेक्चर का सख्त सत्यापन

लेकिन इस प्रकार के दुरुपयोग को सही ढंग से जांचने के लिए, आपको निम्नलिखित आदेशों के साथ एंकर प्रमाणपत्र की आवश्यकता को जोड़ना होगा:

• codesign -vv -R='anchor apple' ./some_application_or_mach-o # Apple द्वारा हस्ताक्षरित कोड के लिए
• codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # Apple और Apple द्वारा हस्ताक्षरित कोड के लिए

किसी अन्य के हस्ताक्षर के साथ कोड की जाँच करते समय इस तरह की कमांड एक त्रुटि दिखाएगी:



आप spctl कमांड का उपयोग कर सकते हैं, लेकिन इसके लिए कमांड के आउटपुट का सावधानीपूर्वक विश्लेषण आवश्यक है। उदाहरण के लिए, एप्पल (/ बिन / एलएस) और सफारी के हस्ताक्षर के साथ माच-ओ बाइनरी निम्नलिखित रिटर्न देता है:



और यहाँ Apple द्वारा हस्ताक्षरित एक आवेदन का परिणाम है:



लाइन पर ध्यान दें "(कोड मान्य है लेकिन ऐप नहीं लगता है)" के लिए / बिन / एलएस, जो परीक्षण पास नहीं करता है। तुलना के लिए, यहाँ Fat / Universal ncat.frankenstein फ़ाइल का परिणाम है:



Ncat.frankenstein Fat / Universal फ़ाइल यह नहीं दिखाती है कि कोड मान्य है। इसलिए, मैं मैन्युअल रूप से ऑफ़लाइन Mach-O बायनेरिज़ की जाँच के लिए spctl की सिफारिश नहीं कर सकता। बस उचित झंडे के साथ कोडसाइन का उपयोग करें।

डेवलपर्स के लिए

आमतौर पर, डेवलपर्स SecStaticCodeCheckValidityWithErrors () या SecStaticCodeCheckValidity () एपीआई का उपयोग करके निम्नलिखित झंडे के साथ जाँच करते हैं: माक-ओ या फैट / यूनिवर्सल बायनेरिज़।

• kSecCSStrictValidate
• KSecCSCheckAllArchitectures

इन झंडों को यह सुनिश्चित करना चाहिए कि माच-ओ या फैट / यूनिवर्सल फ़ाइल में मेमोरी में लोड सभी कोड क्रिप्टोग्राफिक रूप से हस्ताक्षरित हैं। हालांकि, ये एपीआई डिफ़ॉल्ट रूप से उचित सत्यापन प्रदान नहीं करते हैं, इसलिए तीसरे पक्ष के डेवलपर्स को प्रत्येक आर्किटेक्चर को फैट / यूनिवर्सल फ़ाइल में अलग करना होगा और उस पहचान से मेल खाना चाहिए और क्रिप्टोग्राफिक रूप से मजबूत होना चाहिए।

फैट / यूनिवर्सल फ़ाइल में प्रत्येक नेस्टेड आर्किटेक्चर का परीक्षण करने का सबसे अच्छा तरीका है कि पहले SecRequirementCreateWithString को "एंकर सेब" की आवश्यकता के साथ कॉल करें, इसके बाद kSecatDefaultFlags के साथ SecStaticCodeCheckValidity | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | आवश्यकता के संदर्भ में kSecCSEnforceRevocationChecks ; जैसा कि WhatsYourSign के पैचेड सोर्स कोड में दिखाया गया है।

SecRequirmentCreateWithString फ़ंक्शन के लिए "एंकर ऐप्पल" पास करके, यह कॉल कोडसिग्न codesign -vv -R='anchor apple' कमांड के समान काम करता है, जिसे फैट / यूनिवर्सल फ़ाइल में सभी नेस्टेड बायनेरिज़ के लिए एप्पल सॉफ्टवेयर साइनिंग ट्रस्ट चेन की आवश्यकता होती है। इसके अलावा, झंडे पास करने और SecStaticCodeCheckValidity के लिए आवश्यकता के अनुसार, सभी आर्किटेक्चर को इस आवश्यकता के लिए जाँच की जाती है, और निरसन जाँच लागू की जाती है।

दिखाना

Apple के codesign टूल और -R फ्लैग का उपयोग करने की आवश्यकता है।



LittleSnitch - डिस्क पर फैट / यूनिवर्सल फ़ाइल की जाँच करना काम नहीं करता है, लेकिन LittleSnitch मेमोरी में प्रक्रिया की सही जाँच करता है।





LittleFlocker - F-Secure ने LittleFlocker को खरीदा है, और अब इसे xFence कहा जाता है।



एफ-सुरक्षित xFence (पूर्व में LittleFlocker)



उद्देश्य-उपकरण देखें

TaskExplorer





WhatsYourSign



फेसबुक OSquery एक मान्य उदाहरण के रूप में मैलवेयर के नमूने और / बिन / एलएस का परिणाम है।



Google सांता जारी - Fileinfo से पता चलता है कि ncat.frankenstein श्वेतसूची में है:



इनकार ncat (अहस्ताक्षरित) निष्पादन और ncat.frankenstein निष्पादन अनुमति:



पिछले उदाहरण से सांता.लॉग लॉग दिखाने की घटनाओं:



कार्बन ब्लैक रेस्पॉन्स



VirusTotal - पैच को स्थापित करने से पहले VirusTotal में bash_ppc_adhoc उदाहरण:

प्रकटीकरण दिनांक

02/22/2018: तृतीय-पक्ष सुरक्षा प्रणालियों को दरकिनार करने के लिए Apple को एक रिपोर्ट और PoC भेजा गया।

03/01/2018: Apple ने जवाब दिया कि तीसरे पक्ष के डेवलपर्स को kSecCSCheckAllArchitectures और kSecCSStrictValidate का उपयोग SecStaticCodeCheckValidity API के साथ करना चाहिए, और डेवलपर दस्तावेज़ तदनुसार अपडेट किए जाएंगे।

03/06/2018: झंडे को दरकिनार करने और कड़ाई से जांच करने के लिए Apple को एक रिपोर्ट और PoC भेजा गया।

03/16/2018: Apple को भेजी गई अतिरिक्त जानकारी।

03/20/2018: Apple ने कहा कि उसने इसे एक सुरक्षा मुद्दे के रूप में नहीं देखा जिसे सीधे संबोधित किया जाना चाहिए।

03/29/2018: Apple ने कहा कि दस्तावेज़ीकरण को अद्यतन किया जा सकता है, लेकिन "[...] तृतीय-पक्ष डेवलपर्स को यह सत्यापित करने के लिए अतिरिक्त कार्य करना चाहिए कि सार्वभौमिक बाइनरी में सभी पहचान समान हैं यदि वे एक सार्थक परिणाम प्रस्तुत करना चाहते हैं।"

04/02/2018: पहले CERT / CC से संपर्क करें और बाद में भेद्यता के दायरे और प्रभाव को स्पष्ट करने के लिए सहयोग करें।

04/09/2018: भेद्यता से प्रभावित सभी प्रसिद्ध तृतीय-पक्ष डेवलपर्स CERT / CC के समन्वय में अधिसूचित हैं।

04/18/2018: CERT / CC के साथ अंतिम संपर्क, जिसमें अनुशंसा की जाती है कि किसी ब्लॉग पर सार्वजनिक रूप से जानकारी का खुलासा करने वाले अन्य तृतीय-पक्ष डेवलपर्स को सूचित करने के लिए सबसे अच्छा है जो Apple के कोड साइनिंग API का निजी तौर पर उपयोग करते हैं।

06/05/2018: प्रकाशन से पहले डेवलपर्स के साथ अंतिम संपर्क।

06/12/2018: जानकारी का खुलासा।

निष्कर्ष में

इस मुद्दे को हल करने में उनकी कड़ी मेहनत और व्यावसायिकता के लिए सभी तीसरे पक्ष के डेवलपर्स के लिए धन्यवाद। कोड पर हस्ताक्षर करने वाली कमजोरियां विशेष रूप से उन कंपनियों के लिए हानिकारक हैं, खासकर उन कंपनियों के लिए जो ऑपरेटिंग सिस्टम में डिफ़ॉल्ट से बेहतर सुरक्षा प्रदान करने की कोशिश कर रही हैं।

---

जीएमओ GlobalSign रूस कार्रवाई के लिए हबर सब्सक्राइबर्स


आप GlobalSign प्रबंधक से फोन पर संपर्क करके अतिरिक्त जानकारी प्राप्त कर सकते हैं: +7 (499) 678 2210, या प्रोमो कोड CS002HBFR का संकेत देते हुए वेबसाइट पर फ़ॉर्म भरें।