ईए मूल विंडोज क्लाइंट (CVE-2019-19247 और CVE-2019-19248) में विशेषाधिकार वृद्धि

उन सभी को शुभकामनाएं जिन्होंने भेद्यता विश्लेषण पर मेरे नए लेख को पढ़ने का फैसला किया। पिछली बार, तीन लेखों की एक छोटी श्रृंखला में, मैंने स्टीम कमजोरियों ( 1 , 2 और 3 ) के बारे में बात की थी। इस लेख में मैं एक समान उत्पाद की उत्पत्ति की कमजोरियों के बारे में बात करूंगा - उत्पत्ति, जो खेलों के लिए एक लांचर भी है। खोजी गईं CVW-2019-19247 और CVE-2019-19248 द्वारा प्राप्त की गईं थीं।



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

अब कमजोरियों के लिए। मुझे मूल विंडोज क्लाइंट में "विशेषाधिकार वृद्धि" (एलपीई - स्थानीय विशेषाधिकार वृद्धि या ईओपी - विशेषाधिकारों में वृद्धि) जैसी दो कमजोरियां मिलीं। इस प्रकार की भेद्यता किसी भी विंडोज उपयोगकर्ता को मूल रूप से प्रशासक द्वारा जारी किए गए से अधिक अधिकार प्राप्त करने की अनुमति देती है। इस मामले में, हम दो "विशिष्ट" संवर्द्धन के बारे में बात कर रहे हैं - किसी भी उपयोगकर्ता से NT AUTHORITY \ SYSTEM (OS में अधिकतम अनुमतियों वाला एक खाता)। पहली भेद्यता बल्कि उबाऊ है, इसलिए अगले भाग में मैं संक्षेप में इसका वर्णन करूंगा। लेकिन दूसरा काफी दिलचस्प था, उसके खंड में मैं आपको बताऊंगा कि मैंने उसके लिए कैसे देखा।

CVE-2,019-19,248

इस भेद्यता में दो भाग होते हैं:

1. एक मनमाना पथ पर एक फ़ोल्डर बनाना (सभी-पूर्ण एक्सेस अधिकारों के साथ);
2. NT AUTHORITY \ SYSTEM विशेषाधिकार प्राप्त करने के लिए खंड 1 का उपयोग करें।

अब पहले बिंदु के बारे में अधिक विस्तार से:

पर्यावरण की तैयारी

उत्पत्ति ग्राहक को बंद करना और मूल ग्राहक सेवा को रोकना आवश्यक है (सिद्धांत रूप में, ग्राहक को बंद करने पर सेवा स्वयं बंद हो जाएगी, लेकिन सिर्फ मामले में)।

फ़ोल्डर "C: \ ProgramData \ Origin" के लिए अधिकार "ऑल-फुल एक्सेस" हैं, जो हमें इसकी सामग्री को पूरी तरह से हटाने की अनुमति देता है।

लिंक बिल्डिंग

अब कुछ लिंक बनाएं। पहला लिंक NTFS रेपर्स प्वाइंट (NTFS माउंट प्वाइंट) प्रकार का होगा - फ़ोल्डर से फ़ोल्डर की ओर इशारा करने वाले लिंक का प्रकार: "C: \ ProgramData \ Origin" <-> "\ RPC नियंत्रण"। रिपर पॉइंट बनाने के लिए एडमिनिस्ट्रेटर राइट्स की जरूरत नहीं है। यह केवल आवश्यक है कि स्रोत फ़ोल्डर खाली है और उपयोगकर्ता ने इसे लिखने की अनुमति दी है (उन्हें अंतिम चरण में मंजूरी दे दी गई थी, अधिकारों की जाँच की गई थी)। "" आरपीसी कंट्रोल "फ़ाइल सिस्टम में एक फ़ोल्डर नहीं है, लेकिन एक विशेष प्रकार का फ़ोल्डर - ऑब्जेक्ट डायरेक्टरी है। आप इसे एक नियमित खोजकर्ता के साथ नहीं देख सकते हैं, लेकिन आप विंडोज के आंत्र में उपयोग किए जाने वाले सामान्य अमूर्त के कारण, वहां एक पुनरावृत्ति बिंदु कर सकते हैं।

अब हम सामान्य प्रतीकात्मक लिंक "\ RPC कंट्रोल \ कैटलॉग कैश" <-> "C: \ Path \ To \ Target \ Folder" बनाएंगे। फ़ाइल सिस्टम में, व्यवस्थापक अधिकारों के बिना प्रतीकात्मक लिंक बनाना निषिद्ध है, लेकिन यह नियम ऑब्जेक्ट निर्देशिकाओं पर लागू नहीं होता है। इसलिए, हमारा लिंक सफलतापूर्वक बनाया जाएगा। इन दो लिंक के संयोजन के परिणामस्वरूप, "C: \ ProgramData \ Origin \ कैटलॉग कैश" को "C: \ Path \ To \ Target \ Folder" पर पुनर्निर्देशित किया जाएगा।

इस तरह के लिंक के बारे में यहाँ और पढ़ें। उसी रिपॉजिटरी में, आप लिंक के साथ काम करने के लिए उपयोगिताओं को डाउनलोड कर सकते हैं ।

लांच

अंतिम चरण में, क्लाइंट को चलाएँ। अपने काम की शुरुआत में, वह "ओरिजिनल क्लाइंट सर्विस" लॉन्च करेंगे और यह पाते हुए कि कोई फ़ोल्डर नहीं है "C: \ ProgramData \ Orig \ कैटलॉग कैश", वह इसे बनाने की कोशिश करेगा। सिमिलिंक के माध्यम से नेविगेट करने के परिणामस्वरूप, यह "C: \ Path \ To \ Target \ Folder" बनाएगा और इस फ़ोल्डर को "ऑल-फुल एक्सेस" अधिकार देगा।

ऑपरेशन के पहले बिंदु में क्या प्राप्त करना आवश्यक था। चलिए दूसरे पर चलते हैं।

एक मनमाना पथ पर एक फ़ोल्डर बनाने का संचालन

यहां आप कई तरह से काम कर सकते हैं।

सरल और काफी विश्वसनीय "C: \ Windows \ system32 \ LogonUI.exe.local" फ़ोल्डर बनाना है। "LogonUI.exe" (NT AUTHORITY \ SYSTEM से चलने वाला एप्लिकेशन, उपयोगकर्ता चयन स्क्रीन और लॉक स्क्रीन के संचालन के लिए जिम्मेदार है।) .local-redirection ("dotlocal पुनर्निर्देशन") तंत्र के लिए धन्यवाद, यह पथ से पुस्तकालय को लोड करेगा "C: \ Windows \ system32 \ LogonUI.exe.local \ amd64_microsoft.windows.common-control_6595b64144ccf1df_6.0.17134.648_none_fb45a093030a6d2 \ comctl32.dll। " सामान्य तौर पर, तंत्र स्वयं काफी सामान्य है, इसलिए इसके कई लक्ष्य हो सकते हैं।

एक लंबा लेकिन दिलचस्प तरीका विशेष पासवर्ड के माध्यम से व्यवस्थापक पासवर्ड के हैश को घटाना है। अधिक जानकारी यहाँ ।

कुल मिलाकर

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

CVE-2,019-19,247

यह मेरी पसंदीदा कमजोरियों में से एक है। यह दिखाता है कि आपको इस्तेमाल की गई क्रिप्टोग्राफी से कितनी सावधानी से संबंधित होना चाहिए।

यह सब इस तथ्य से शुरू हुआ कि मैंने ओरिजिन के माध्यम से खेल को स्थापित किया। सब कुछ किसी भी तरह सुचारू रूप से चला गया - क्लिक के एक जोड़े और खेल को डाउनलोड करने के कुछ मिनट बाद लॉन्च किया जा सकता है। तुरंत नहीं, लेकिन मुझे समझ में आया कि मामला क्या था: खेल "C: \ Program Files \ GameName" पथ के साथ स्थापित किया गया था, लेकिन UAC के माध्यम से एक भी सवाल नहीं पूछा। मैंने जल्दी से अधिकारों की जाँच की, सब कुछ मानक था - एक साधारण उपयोगकर्ता "C: \ Program Files" को नहीं लिख सकता था। थोड़ा और शोध और मुझे पता चला कि खेल मूल ग्राहक द्वारा "निर्धारित" नहीं है, बल्कि इसकी मूल ग्राहक सेवा द्वारा।

मैंने इस बारे में धारणा बनाना शुरू किया कि कैसे ग्राहक सेवा की जानकारी को जांचने के लिए पहुंचाता है कि क्या कुछ शोषण किया जा सकता है।

सूचना प्रसारित करने की विधि सरल हुई - एक नामित पाइप। मैंने इसके बारे में इंस्टॉलेशन लॉग से सीखा - सादे पाठ में यह इंगित किया गया था कि OrigClientService पाइप फाइलों और फ़ोल्डरों के साथ काम करने के लिए आदेशों को स्वीकार कर रहा है।

आईडीए खोला, ग्राहक को वहां अपलोड किया।

* आईडीए में किया गया काम: 1 *

बहुत जल्दी, मैंने पाया कि कमांड को सामान्य रूप से टेक्स्ट फॉर्म में पाइप पर भेजा गया था। पास ही मुझे आदेशों की एक सूची मिली और आगे की हलचल के बिना, पाइप पर "प्रतिलिपि" C: \ test \ payload.dll "" C: \ Windows \ pwn.dll "" टाइप की एक कमांड भेजी। एक त्वरित परिणाम की प्रत्याशा में, मैं "C: \ Windows" फ़ोल्डर की जांच करता हूं और इसमें कुछ भी नया नहीं पाता। लेकिन लॉग में कुछ नया है - इस तथ्य के बारे में कुछ शब्द कि पाइप पर क्लाइंट ने डिजिटल हस्ताक्षर सत्यापन पारित नहीं किया था।

आईडीए खोला, वहां सेवा अपलोड की।

* आईडीए में किया गया काम: 2 *

मुझे पता चला कि टीमों को वैसे भी किसी से उम्मीद नहीं है। पाइप से कनेक्ट करते समय, सेवा यह जांचती है कि कौन किससे जुड़ा है। कनेक्शन से प्रक्रिया पीआईडी ​​निकाली जाती है, निष्पादन योग्य फ़ाइल के लिए पथ को पीआईडी ​​से निकाला जाता है, हस्ताक्षर को शुद्धता के लिए जांचा जाता है और यह ईए द्वारा जारी किया जाता है।
ध्वनि ध्वनि, लेकिन पर्याप्त नहीं है। आप कानूनी "Orig.exe" (क्लाइंट निष्पादन योग्य फ़ाइल) ले सकते हैं, इसे अपने फ़ोल्डर में कहीं कॉपी कर सकते हैं। इस फ़ोल्डर में आयात सूची "Origin.exe" से कुछ dll रखें। उदाहरण के लिए, version.dll ऊपर आया। मैंने इस दृष्टिकोण को "रिवर्स डीएल इंजेक्शन" कहा: एक नियमित डीएल इंजेक्शन में, हम एक्सएल फ़ाइल में डीएल को कॉपी करते हैं, लेकिन अब हमने इसके विपरीत किया है। मैं जल्दी से version.dll के लिए प्रॉक्सी dll लिखता हूं, पाइप में कमांड भेजने के साथ कोड जोड़ता हूं। पेलोड अभी भी कॉपी नहीं किया गया है। हम लॉग पढ़ते हैं - "इसका क्या मतलब है, कमांड को डिक्रिप्ट नहीं किया जा सकता है!"। मैंने एन्क्रिप्शन को छोड़ दिया।

आईडीए खोला, ग्राहक को वहां अपलोड किया।

* आईडीए में किए गए कार्य: 3, हस्ताक्षर बायपास: 1 *

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

आईडीए खोला, वहां सेवा अपलोड की।

* आईडीए में किया गया काम: 4, हस्ताक्षर बायपास: 1, एन्क्रिप्शन बाईपास: 1 *

तो, सच्चाई यह है कि एक कमांड प्राप्त करने के लिए चेक हैं, जो यह बताता है कि फ़ाइलों को हर जगह कॉपी नहीं किया जा सकता है। और "\ .. \" वाले पथ लिखे नहीं जा सकते। हम देखते हैं कि अन्य टीमें क्या हैं।
रजिस्ट्री के साथ काम करना - फिर से बहुत सारे प्रतिबंध हैं। लेकिन लॉन्चिंग फाइलें दिलचस्प लगती हैं। कम से कम चेक विशेष रूप से दिखाई नहीं देते हैं। कोड संपादित करें, कमांड "ExecuteProcess" C: \ test \ payload.exe "" भेजें। खैर, आप समझ गए ... कुछ नहीं।

लॉग फिर से हस्ताक्षर के बारे में बात करते हैं। ओह, हम पहले ही इसे जीत चुके हैं। हम उस कोड में इंगित करते हैं जिसे हमने अपने प्रॉक्सी डीएल को फिर से लोड करने के लिए अपने कॉपी किए गए ओरिजिनल। चेक जोड़ें और कंसोल लॉन्च करें। हम शुरू करते हैं और NT AUTHORITY \ SYSTEM अधिकारों के साथ कंसोल दिखाई देता है - आखिरकार काम किया।

* आईडीए में किया गया काम: 4, हस्ताक्षर बायपास: 2, एन्क्रिप्शन बाईपास: 1 *

तो, आपको रीबूट करने की आवश्यकता है, एक अंतिम रन का संचालन करें और अभी भी अधिकतम अधिकारों के साथ कंसोल की प्रशंसा करें। रिबूट, चेक और ... कुछ भी नहीं। ऐसा कैसे? यह सिर्फ काम किया।

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

आईडीए खोला, वहां सेवा अपलोड की।

* आईडीए में काम किया: 5, बाईपास हस्ताक्षर: 2, बाईपास एन्क्रिप्शन: 1 *

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

कुल मिलाकर

शोषक काम कर रहा है। आईडीए: 5 बार, बायपास हस्ताक्षर: 3 बार, एन्क्रिप्शन बायपास: 2 बार: में काम किया गया था।

निष्कर्ष

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

समयरेखा कमजोरियाँ:

1 अप्रैल, 2019 : पाइप के साथ भेद्यता रिपोर्ट रिपोर्टिंग;

7 अप्रैल, 2019 : एक मनमाना फ़ोल्डर के साथ भेद्यता रिपोर्ट भेजना;

... बहुत बहुत पत्र (मैं 40 गिना) ...

10 दिसंबर, 2019 : खुलासे पर सहमति।

आपका ध्यान देने के लिए आप सभी का धन्यवाद, मैं आपको समान सुरक्षा एजेंट चाहता हूं।

यह लेख अंग्रेजी में।