RootPipeTester

विषय-सूची

1. RootPipe Tester क्या है?
2. मुझे RootPipe Tester का उपयोग क्यों करना चाहिए?
3. मैं RootPipe Tester का उपयोग कैसे करूँ?
4. PANIC!!! मेरा सिस्टम असुरक्षित है? क्या हम सब मर जाएँगे?
   1. OS X 10.10 (Yosemite)
   2. OS X 10.9 (Mavericks)
   3. OS X 10.8 (Mountain Lion)
   4. OS X 10.7 (Lion), Mac OS X 10.6 (Snow Leopard), Mac OS X 10.5 (Leopard), Mac OS X 10.4 (Tiger)
   5. Mac OS X 10.3 (Panther)
   6. Mac OS X 10.2 (Jaguar)
   7. Mac OS X 10.1 (Puma), Mac OS X 10.0 (Cheetah)
5. RootPipe के बारे में
   1. RootPipe कैसे काम करता है?
   2. क्या यह एक बैकडोर है?

1. RootPipe Tester क्या है?

RootPipe Tester एक छोटा एप्लिकेशन है जो आपके Mac (Mac OS X 10.2.8 या उच्चतर, PowerPC और Intel दोनों) पर चलता है और विशेषाधिकार वृद्धि उत्पन्न करने के लिए RootPipe (CVE-2015-1130) और Phoenix (CVE-2015-3673) दोनों एक्सप्लॉइट्स का उपयोग करने का प्रयास करता है।

2. मुझे RootPipe Tester का उपयोग क्यों करना चाहिए?

क्या आप केवल असुरक्षित Mac OS संस्करणों की सूची नहीं बना सकते?

आपका Mac असुरक्षित है या नहीं यह आपके द्वारा चलाए जा रहे Mac OS X के संस्करण पर निर्भर करता है, लेकिन इसकी सफलता आपके द्वारा निर्धारित प्राथमिकताओं पर भी निर्भर करती है।
RootPipe Tester के साथ मैंने आपके लिए एक-क्लिक समाधान बनाया है ताकि आप बिना व्यापक परीक्षण और प्रयास किए यह सत्यापित कर सकें कि आप असुरक्षित हैं या नहीं।

3. मैं RootPipe Tester का उपयोग कैसे करूँ?

इस रिपॉजिटरी के releases पेज से डिस्क इमेज डाउनलोड करें या यदि आप चाहें तो इसे स्वयं कंपाइल करें।
डिस्क इमेज को माउंट करें और उसमें मौजूद एप्लिकेशन चलाएँ (डिस्क इमेज से RootPipe Tester चलाना सुरक्षित है)।
"Start Test" पर क्लिक करें और परीक्षण को चलने दें (आप विंडो शीर्षक में "Running…" देखकर जान सकते हैं कि यह समाप्त हुआ है या नहीं)।

सटीक परिणाम पाने के लिए मैं सुझाव देता हूँ कि अपने Mac को पुनः आरंभ करें और "नए लॉगिन" पर परीक्षण फिर से चलाएँ।

यदि कम से कम एक परीक्षण रन में असुरक्षित सिस्टम पाया गया है, तो आप PANIC अनुभाग देख सकते हैं।

4. PANIC!!! मेरा सिस्टम असुरक्षित है? क्या हम सब मर जाएँगे?

नहीं! शांत रहें और अपने सिस्टम संस्करण के अनुरूप मार्गदर्शिका पढ़ें।

नोट: उपयोगकर्ता प्राधिकरण में असुरक्षित न होने का अर्थ है कि सिस्टम या तो पहुँच प्रदान नहीं करेगा या एक प्राधिकरण संवाद पॉप-अप करेगा जो आपको एक Administrator उपयोगकर्ता के रूप में प्रमाणित करने के लिए संकेत देता है।
कुछ हद तक यह भी एक विशेषाधिकार वृद्धि है, क्योंकि admin समूह के पास root के समान अधिकार नहीं होते हैं, लेकिन sudo के डिफ़ॉल्ट कॉन्फ़िगरेशन में, "admin" समूह का प्रत्येक उपयोगकर्ता अपना पासवर्ड दर्ज करके root प्राप्त कर सकता है, इसलिए यही प्रभाव केवल sudo चलाकर भी प्राप्त किया जा सकता है।

4.1. OS X 10.10 (Yosemite)

जितनी जल्दी हो सके 10.10.3 में अपग्रेड करें ताकि यह सुनिश्चित हो कि सिस्टम writeconfig बाइनरी पर entitlements को सही ढंग से लागू करता है। (कम से कम Apple तो यही कहता है)

यदि किसी कारण से आप 10.10.3 में अपग्रेड नहीं कर सकते हैं, तो OS X 10.9 Mavericks का अनुभाग देखें।

4.2. OS X 10.9 (Mavericks)

Mavericks एक शोषणकर्ता को nil प्राधिकरण के साथ आगे बढ़ने देता है, इसलिए आप Mac OS X के पुराने संस्करणों की तुलना में बहुत अधिक कठिन स्थिति में हैं।

आप can_I_suid पर एक नज़र डालना चाह सकते हैं।

परीक्षण परिणाम:

nil प्राधिकरण:

असुरक्षित

उपयोगकर्ता प्राधिकरण:

• Administrator खाता: केवल तभी असुरक्षित जब “प्रत्येक System Preferences फलक को अनलॉक करने के लिए पासवर्ड आवश्यक करें” चेक न किया गया हो।
• मानक उपयोगकर्ता खाता: असुरक्षित नहीं

4.3. OS X 10.8 (Mountain Lion)

आपको सुरक्षा प्रेफरेंस फलक में "प्रत्येक System Preferences फलक को अनलॉक करने के लिए पासवर्ड आवश्यक करें" को सक्षम करना चाहिए।

परीक्षण परिणाम:

nil प्राधिकरण:

असुरक्षित नहीं

उपयोगकर्ता प्राधिकरण:

• Administrator खाता: केवल तभी असुरक्षित जब “प्रत्येक System Preferences फलक को अनलॉक करने के लिए पासवर्ड आवश्यक करें” चेक न किया गया हो।
• मानक उपयोगकर्ता खाता: असुरक्षित नहीं

4.4. OS X 10.7 (Lion), Mac OS X 10.6 (Snow Leopard), Mac OS X 10.5 (Leopard), Mac OS X 10.4 (Tiger)

बधाई हो! आपके पास Mac OS X के सबसे सुरक्षित संस्करणों में से एक है (कम से कम जहाँ तक RootPipe का संबंध है)।

इन प्रणालियों पर, सुरक्षा प्रेफरेंस फलक में "प्रत्येक System Preferences फलक को अनलॉक करने के लिए पासवर्ड आवश्यक करें" (Tiger में "प्रत्येक सुरक्षित system preference को अनलॉक करने के लिए पासवर्ड आवश्यक करें") सही ढंग से काम कर रहा है और वास्तव में सक्षम होना चाहिए!

नोट: यदि "पासवर्ड आवश्यक करें" चेकबॉक्स अनचेक है, तो सिस्टम प्रत्येक लॉगिन पर सुरक्षित प्रेफरेंस फलकों को अनलॉक कर देगा। यदि आप एक Administrator खाते का उपयोग कर रहे हैं, तो यह आपके सिस्टम को तब तक असुरक्षित बना देगा जब तक आप प्रत्येक लॉगिन के बाद System Preferences में लॉक को मैन्युअल रूप से बंद नहीं करते।

परीक्षण परिणाम:

nil प्राधिकरण:

असुरक्षित नहीं

उपयोगकर्ता प्राधिकरण:

• Administrator खाता: केवल तभी असुरक्षित जब दोनों "पासवर्ड आवश्यक करें" अनचेक हो और सुरक्षित प्रेफरेंस फलक अनलॉक हों।
  ध्यान दें: यदि "पासवर्ड आवश्यक करें" अनचेक है, तो सिस्टम प्रत्येक लॉगिन पर सुरक्षित प्रेफरेंस फलकों को अनलॉक कर देगा।
• मानक उपयोगकर्ता खाता: असुरक्षित नहीं

4.5. Mac OS X 10.3 (Panther)

बाद की प्रणालियों के विपरीत, Panther में, सुरक्षा प्रेफरेंस फलक में "प्रत्येक सुरक्षित system preference को अनलॉक करने के लिए पासवर्ड आवश्यक करें" चेकबॉक्स का प्रभाव इस एक्सप्लॉइट को पूरी तरह से रोकने का नहीं होता है। फिर भी मैं इसे चेक करने की सलाह देता हूँ।
अपने सिस्टम को सुरक्षित करने के लिए मैं दृढ़ता से सलाह देता हूँ कि केवल मानक उपयोगकर्ता खाते का उपयोग करें और System Preferences में प्राथमिकताएँ बदलने के बाद हमेशा मैन्युअल रूप से "लॉक बंद करें"।
केवल System Preferences को बंद करने से प्राधिकरण सही ढंग से अमान्य नहीं होगा और यह एक्सप्लॉइट तब तक काम करेगा जब तक आप लॉग आउट नहीं करते, भले ही System Preferences GUI एक मानक उपयोगकर्ता के रूप में बंद लॉक दिखाता है।

परीक्षण परिणाम:

nil प्राधिकरण:

असुरक्षित नहीं

उपयोगकर्ता प्राधिकरण:

• Administrator खाता: असुरक्षित यदि सुरक्षित प्रेफरेंस फलक अनलॉक हैं या लॉगिन के बाद मैन्युअल रूप से लॉक नहीं किए गए हैं (यदि आवश्यक हो तो खोलकर और System Preferences में लॉक बंद करके)।
• मानक उपयोगकर्ता खाता: असुरक्षित यदि सुरक्षित प्रेफरेंस फलक अनलॉक हैं।

4.6. Mac OS X 10.2 (Jaguar)

बाद की प्रणालियों के विपरीत, Jaguar "प्रत्येक सुरक्षित system preference को अनलॉक करने के लिए पासवर्ड आवश्यक करें" चेकबॉक्स प्रदान नहीं करता है, लेकिन फिर भी यह सभी Administrator उपयोगकर्ताओं के लिए लॉगिन पर सुरक्षित प्रेफरेंस फलकों को अनलॉक करता है।

अपने सिस्टम को सुरक्षित करने के लिए मैं दृढ़ता से सलाह देता हूँ कि केवल Standard उपयोगकर्ता खाते का उपयोग करें।

नोट: Jaguar System Preferences के बंद होने पर सुरक्षित प्रेफरेंस फलकों को लॉक नहीं करता है, इसलिए सुरक्षित फलकों को हमेशा मैन्युअल रूप से लॉक करें। यदि आप ऐसा करने में विफल रहते हैं, तो एक्सप्लॉइट आपके लॉग आउट करने तक काम करेगा।

नोट: यदि आप मानक उपयोगकर्ता खाते पर स्विच नहीं कर सकते हैं, तो एक साधारण AppleScript जो Login Item के रूप में सुरक्षित प्रेफरेंस फलकों को लॉक करती है, काम कर सकती है।

नोट: RootPipe Tester का सामान्य संस्करण Jaguar पर नहीं चलेगा। यदि आप Jaguar पर चलाना चाहते हैं तो RootPipe Tester का Legacy संस्करण डाउनलोड करें।
RootPipe Tester का Legacy संस्करण कार्यक्षमता में सामान्य संस्करण के समकक्ष है, लेकिन इसे GCC 4.0 के बजाय GCC 3.1 का उपयोग करके कंपाइल किया गया है।

परीक्षण परिणाम:

nil प्राधिकरण:

असुरक्षित नहीं

उपयोगकर्ता प्राधिकरण:

• Administrator खाता: असुरक्षित यदि अंतिम लॉगिन के बाद से सुरक्षित प्रेफरेंस फलकों को मैन्युअल रूप से लॉक नहीं किया गया है (यदि आवश्यक हो तो खोलकर और System Preferences में लॉक बंद करके)।
• मानक उपयोगकर्ता खाता: केवल तभी असुरक्षित यदि सुरक्षित प्रेफरेंस फलक अनलॉक हैं।

4.7. Mac OS X 10.1 (Puma), Mac OS X 10.0 (Cheetah)

Puma के लिए एक एक्सप्लॉइट संभव प्रतीत होता है, क्योंकि यह System Preferences को प्रमाणित करने के लिए समान चरणों का उपयोग करता है और अधिकांश आवश्यक घटक मौजूद हैं। एक्सप्लॉइट को बाधित करने वाली एकमात्र चीज़ यह है कि Puma में SecurityFoundation.framework नहीं है, जिसका उपयोग बाद के संस्करणों में प्राधिकृत करने के लिए किया जाता है। इसके बजाय यह NIInterface.framework नामक एक PrivateFramework का उपयोग करता है, जिसे पहले रिवर्स इंजीनियर किया जाना आवश्यक है।

अच्छी खबर वैसे भी है: कोई भी लगभग नगण्य उपयोगकर्ता आधार का शोषण करने में समय निवेश नहीं करने वाला है।
सुरक्षा बढ़ाने के लिए केवल Standard उपयोगकर्ता खाते का उपयोग करना और सुरक्षित प्रेफरेंस फलकों को मैन्युअल रूप से लॉक करना अभी भी अनुशंसित है।

5. RootPipe के बारे में

5.1. RootPipe कैसे काम करता है?

नोट: इस अनुच्छेद को संदेह के साथ लें। मैंने यह पता लगाने की पूरी कोशिश की कि वास्तव में क्या हो रहा है, लेकिन चूँकि यह सब PrivateFrameworks है, आप कभी 100% नहीं जान सकते कि ये विधियाँ क्या कर रही हैं, विशेष रूप से Mac OS X के इतने सारे संस्करणों के माध्यम से, जिन्हें मैं कवर करने का प्रयास कर रहा हूँ।

जिस तरह से RootPipe एक्सप्लॉइट काम करता है वह मूल रूप से वही है जो System Preferences कॉन्फ़िग फ़ाइलों को लिखने के लिए करता है (इसलिए नाम WriteConfig), इस अपवाद के साथ कि इस एक्सप्लॉइट के उपयोगकर्ताओं को System Preferences एप्लिकेशन नहीं होना चाहिए।
अब तक यह इतना भयानक नहीं है, और वास्तव में पूरा एक्सप्लॉइट भी इतना भयानक नहीं है।
लेकिन आइए कोड को देखें।

	// Authorization
	SFAuthorization auth = [SFAuthorization authorization];
	id authenticator = [Authenticator sharedAuthenticator];
	[authenticator authenticateUsingAuthorizationSync:auth];
	// Profit?
	id sharedLiaison = [ToolLiaison sharedToolLiaison];
	id tool = [sharedLiaison tool];

जैसा कि आप देख सकते हैं, यह "पुरानी शैली" का कोड है, लेकिन नई शैली के लिए सिद्धांत कमोबेश वही है।
इस स्निपेट की पहली तीन पंक्तियाँ प्राधिकरण हैं और अंतिम दो वास्तविक मज़ा हैं।

यदि System Preferences में किसी प्रेफरेंस फलक को ऐसी कार्रवाइयाँ करने की आवश्यकता होती है जिन्हें विशेषाधिकार प्राप्त रूप से चलाया जाना है, तो यह एक SFAuthorizationView (लॉक प्रतीक) को निचले बाएँ कोने में रखेगा। यह SFAuthorizationView फिर system.preferences अधिकार के अधिग्रहण और विनाश को संभालेगा।

अब तक सब ठीक है, लेकिन यह system.preferences क्या है? Apple द्वारा उपयोग किए जाने वाले अधिकार और वे कैसे कॉन्फ़िगर किए गए हैं, समय के साथ बदल गए हैं, लेकिन सिद्धांत वही रहा है। नीचे आप Authorization Services Policy Database से एक अंश देखते हैं।

10.5.8 पर system.preferences

{
    "allow-root" = 1;
    class = user;
    comment = "Checked by the Admin framework when making changes to certain System Preferences.";
    group = admin;
    shared = 1;
}

जैसा कि आप देख सकते हैं, यह एक साझा अधिकार है। इसका मतलब है कि एक बार यह अधिकार किसी भी प्रक्रिया द्वारा प्राप्त कर लिया गया है, हर दूसरी प्रक्रिया इसका उपयोग तब तक कर सकती है जब तक सत्र नष्ट न हो जाए (जब आप लॉग आउट करते हैं)।
यह अपने आप में इतना बुरा नहीं है, क्योंकि पहली बार जब कोई एप्लिकेशन system.preferences का उपयोग करना चाहता है तो आपको प्राधिकृत करना होता है, दुर्भाग्य से सिस्टम लॉगिन पर इसे स्वचालित रूप से प्राधिकृत कर देता है (Administrator उपयोगकर्ताओं के लिए)। इसका मतलब है कि हमारे RootPipe Tester को प्राधिकृत होने की आवश्यकता नहीं होगी और वह इसके बजाय सिस्टम के प्राधिकरण का उपयोग कर सकता है।

मानक उपयोगकर्ता सुरक्षित हैं, क्योंकि सिस्टम लॉगिन पर system.preferences अधिकार प्राधिकृत नहीं करता है।

सही प्राधिकरण प्राप्त करने के साथ, मनमाने अधिकारों के साथ कॉन्फ़िग फ़ाइलें (या उस मामले के लिए कोई अन्य फ़ाइल) लिखना काफी आसान खेल है।
ToolLiaison ख़ुशी से आपके लिए writeconfig के लिए एक NSDistantObject स्थापित करेगा और writeconfig ख़ुशी से आपके लिए फ़ाइल लिखेगा, क्योंकि उनके विचार में, आपने स्वयं को ठीक से प्राधिकृत कर लिया है।

System Preferences में "प्रत्येक System Preferences फलक को अनलॉक करने के लिए पासवर्ड आवश्यक करें" चेकबॉक्स को चेक करने से Mac OS X के 10.4 - 10.8 सभी संस्करणों पर RootPipe ठीक हो जाता है।
इस चेकबॉक्स को चेक करने से system.preferences अधिकार संशोधित हो जाएगा और shared को false पर सेट कर देगा।
यदि कोई अधिकार साझा नहीं है, तो इसका मतलब है कि प्रत्येक प्रक्रिया को अपना स्वयं का प्राधिकरण प्राप्त करना होगा। क्योंकि प्राधिकरण प्राप्त करने के लिए उपयोगकर्ता को एक Administrator का पासवर्ड दर्ज करना पड़ता है, हमला उपयोगकर्ता द्वारा देखा जा सकता है। साथ ही, केवल sudo चलाने से भी समान प्रभाव होगा, जो इस हमले को बेकार बना देता है।

5.2. क्या यह एक बैकडोर है?

वास्तव में नहीं। पहली नज़र में यह एक जैसा लग सकता है, क्योंकि यह एक PrivateFramework में root के रूप में चल रहा है और उचित प्रमाणीकरण नहीं कर रहा है।

लेकिन यहाँ असली मुद्दा खराब डिज़ाइन का है। Apple यह सुनिश्चित करना चाहता था कि प्रत्येक Administrator उपयोगकर्ता के पास System Preferences का पूर्ण उपयोग करने की क्षमता हो और Unix में हर चीज़ के लिए एक कॉन्फ़िग फ़ाइल की आवश्यकता होती है और इन्हें लिखने की आवश्यकता होती है (अधिकांश समय root के रूप में)।

कोई तर्क दे सकता है कि यह एक बुरा विचार है (मैं सहमत हूँ) लेकिन मैं इसे बैकडोर नहीं मानूंगा क्योंकि प्रमाणीकरण सही ढंग से काम कर रहा है और हर Administrator को वैसे भी sudo के माध्यम से root प्राप्त करने की क्षमता है। यहाँ मुख्य समस्या यह है कि Apple ने सुरक्षा पर आराम को तरजीह दी, लेकिन यह भी उनके लिए कुछ विशेष नहीं है।