और एक और स्टीम विंडोज क्लाइंट स्थानीय विशेषाधिकार वृद्धि 0day

पिछली श्रृंखला में

बहुत पहले नहीं मैंने स्टीम के लिए भेद्यता का विवरण प्रकाशित किया था। मुझे पाठकों से बहुत प्रतिक्रिया मिली। वाल्व ने एक शब्द भी नहीं कहा, और हैकरऑन ने एक विशाल आंसू पत्र भेजा और, मूल रूप से, चुप था। परिणामस्वरूप, मुझे H1 पर वाल्व द्वारा प्रतिबंधित कर दिया गया था - मैं कमजोरियों को अस्वीकार करने के लिए उनके कार्यक्रम में भाग नहीं ले सकता (शेष H1 मेरे लिए उपलब्ध है)।



आप पिछले प्रकाशन में कहानी के बारे में अधिक जान सकते हैं, यहाँ मैं वर्तमान स्थिति के बारे में कुछ शब्द कहूँगा।

लेकिन यह सरल और दुखद है - वाल्व अभी भी विफल रहता है। नवीनतम अद्यतन, जिसे समस्या को ठीक करने के लिए डिज़ाइन किया गया था, आसानी से बायपास हो गया है और भेद्यता अभी भी प्रासंगिक है। हां, मैंने इसे चेक किया - यह बहुत अच्छा काम करता है।

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

संक्षिप्तता का संक्षिप्त विवरण

भेद्यता के शोषण का एक सामान्य विवरण काफी सरल है और इसमें तीन चरण शामिल हैं:

1. हम ऑपरेशन के लिए वातावरण तैयार करते हैं (विभिन्न सुरक्षा खामियों का उपयोग करके चुनने के दो तरीके)।
2. हमारे dll को कॉपी और चलाने के लिए स्टीम प्राप्त करें।
3. Dll को छोटी आवश्यकताओं को पूरा करना चाहिए।

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

सैद्धांतिक न्यूनतम

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

"आप HKLM रजिस्ट्री कुंजी को नहीं लिख सकते हैं"

ऐसा कोई सामान्य नियम नहीं है। विशिष्ट रजिस्ट्री कुंजी के लिए विशिष्ट सुरक्षा नियम हैं। वाल्व ने सभी उपयोगकर्ताओं के लिए HKLM \ SOFTWARE \ Wow6432Node \ वाल्व \ भाप शाखा के लिए पूर्ण एक्सेस अधिकार सेट किया है, और इसलिए, कोई भी उपयोगकर्ता इस शाखा में जो चाहे कर सकता है।

"आप प्रशासक अधिकारों के बिना सेवा शुरू या बंद नहीं कर सकते हैं"

ऐसा कोई सामान्य नियम नहीं है। विशिष्ट सेवाओं के लिए विशिष्ट सुरक्षा नियम हैं। वाल्व ने अधिकार निर्धारित किए ताकि स्टीम क्लाइंट सेवा किसी भी उपयोगकर्ता द्वारा शुरू और बंद की जा सके।

"एक सिम्लिंक बनाने के लिए, आपको व्यवस्थापक अधिकारों की आवश्यकता है"

यह अपने आप में एक मज़ेदार सवाल है, यह देखते हुए कि विंडोज में 5 मुख्य प्रकार के लिंक में से केवल डेढ़ को ही इन अधिकारों की आवश्यकता होती है। तो, मिलते हैं: फ़ाइल प्रतीकात्मक लिंक, ऑब्जेक्ट निर्देशिका प्रतीकात्मक लिंक, हार्ड लिंक, NTFS reparse बिंदु और reg_link। एक फ़ाइल प्रतीकात्मक लिंक बनाने के लिए और स्थायी वस्तु निर्देशिका प्रतीकात्मक लिंक के लिए प्रशासक के अधिकारों की आवश्यकता होती है (अस्थायी एक बिल्कुल उस सत्र के रूप में रहता है, जिसमें इसे बनाया जाता है, सामान्य अर्थ में, रिबूट करने से पहले, और विशेष अधिकारों की आवश्यकता नहीं होती है)।

फ़ोल्डर से फ़ोल्डर में सिमिंक

इसे NTFS पुनर्संरचना बिंदु या NTFS माउंट बिंदु कहा जाता है। नाम विशेष रूप से महत्वपूर्ण नहीं है, तथ्य यह है कि यह चीज आपको एक फ़ोल्डर को दूसरे के लिए सूचक के रूप में उपयोग करने की अनुमति देती है। यह एक खाली फ़ोल्डर से एक साधारण उपयोगकर्ता द्वारा बनाया जा सकता है यदि उसके पास राइट राइट है। निर्माण के लिए, हम लिंक के साथ काम करने के परीक्षण के लिए उपयोगिताओं के एक सेट से CreateMountPoint.exe उपयोगिता का उपयोग करेंगे।

ताला छोड़कर

आउटगोइंग ब्लॉकिंग ( OpLock या ऑपर्च्युनिस्टिक लॉक ) एक विशेष तंत्र है, जिसमें एक एप्लिकेशन एक निश्चित फ़ाइल संसाधन तक पहुँचने से सभी को अस्थायी रूप से ब्लॉक कर सकता है। यहां आप सभी प्रकार के विवरण, फ़ोल्डर्स के साथ काम करने की विशेषताएं और विभिन्न एक्सेस लिख सकते हैं। लब्बोलुआब यह है: कार्यक्रम एक निश्चित फ़ाइल तक पहुंचने की घटना को "पकड़" सकता है और थोड़ी देर के लिए इसे पकड़ सकता है। आप लिंक के साथ काम करने के लिए एक ही परीक्षण सूट से SetOpLock.exe उपयोगिता का उपयोग करके ऑपलॉक स्थापित कर सकते हैं। उपयोगिता चलाने से आवश्यक अनलॉक स्थापित होता है; जब पहुंच होती है, तो उपयोगिता एक संदेश लिखती है; एंटर दबाने से अनलॉक हट जाता है।

BaitAndSwitch

यह तकनीक का नाम है, जो लिंक के निर्माण और TOCTOU को जीतने के लिए ओपोज़ल की स्थापना को जोड़ती है (उपयोग के समय चेक का समय)। एक उदाहरण के साथ समझाने के लिए सार आसान है।

कल्पना कीजिए कि कुछ कार्यक्रम है जो कुछ इस तरह से करता है:

ReadContentFromFile(“C:\test\myfile.txt”); ReadContentFromFile(“C:\test\myfile.txt”); 

यह एक ही फाइल को लगातार दो बार पढ़ रहा है। क्या हमेशा वही पढ़ा जाएगा? नहीं, जरूरी नहीं।

सबसे पहले, C: \ test1 \ myfile.txt और C: \ test2 \ myfile.txt फ़ाइलों के साथ दो फ़ोल्डर बनाएँ। और सामान्य तौर पर हम C: \ test फोल्डर को क्लियर करेंगे और C: \ test1 पर एक रिपेयर पॉइंट बनाएंगे। हमने पहली निर्देशिका से फाइल को अनलॉक किया और प्रोग्राम चलाया। जैसे ही वह फ़ाइल खोलती है, अनलॉक काम करेगा। हम पुनः परिवर्तन बिंदु और C: \ test C: \ test2 को इंगित करेंगे। अब, अनलॉक हटा दिए जाने के बाद, प्रोग्राम दूसरी बार फ़ाइल को दूसरी फ़ाइल से पढ़ेगा।

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

अब सब कुछ ऑपरेशन के लिए तैयार है।

ऑपरेशन 1. पर्यावरण की तैयारी

काम के माहौल को थोड़ा तैयार करना आवश्यक है। आरंभ करने के लिए, आपको निष्पादन योग्य फ़ाइलें CreateMountPoint.exe और SetOpLock.exe लेने की आवश्यकता है।

अब हमें स्टीम की फ़ाइल संरचना में छोटे बदलाव करने की आवश्यकता है। हमारा काम दो फ़ाइलों के साथ एक फ़ोल्डर प्राप्त करना है स्टीम। Exe और steamclient.dll और बिन फ़ोल्डर की अनिवार्य अनुपस्थिति। ऐसा करने के दो तरीके हैं।

विधि 1

मुख्य स्टीम फ़ोल्डर से बिन फ़ोल्डर का नाम बदलें। यह सब, आप महान हैं (स्थापना के दौरान स्टीम किसी भी उपयोगकर्ता को अपने फ़ोल्डर में सब कुछ का अधिकार देता है)।

विधि 2

रजिस्ट्री कुंजी में HKLM \ SOFTWARE \ Wow6432Node \ वाल्व \ भाप हमारे कुछ फ़ोल्डर में InstallPath पैरामीटर को बदलते हैं। इस फ़ोल्डर में, Steam.exe और Steamclient.dll को स्टीम के मुख्य फ़ोल्डर से छोड़ दें।

मान लीजिए कि हमने C: \ स्टीम फ़ोल्डर को किसी भी तरीके से तैयार किया है (पथ कोई भी हो सकता है, लेकिन उदाहरण में मैं इसका उपयोग करूंगा)। अब इसमें एक और फोल्डर b1, b2, b3 और b4 बनाएं। पहले तीन में, हम steamservice.dll फ़ाइल अपलोड करेंगे (स्टीम किट से, मूल में यह बिन फ़ोल्डर में था), और b4 फ़ोल्डर में हम एक ही नाम - steamservice.dll के साथ विशेष रूप से बनाई गई लाइब्रेरी को छोड़ देंगे। पुस्तकालय की तैयारी पर विवरण पैराग्राफ 3 में होगा।

हम कंसोल की दो विंडो खोलते हैं। इससे पर्यावरण की तैयारी पूरी होती है।

ऑपरेशन 2. फ़ाइल की जगह

मुझे लगता है कि तैयारियों से यह पहले ही स्पष्ट हो गया है कि ऊपर वर्णित बैटएंडस्विच जैसा कुछ होगा।

ProMMon से स्क्रीनशॉट:



यह स्टीम क्लाइंट सेवा के विशिष्ट लॉन्च का हिस्सा है। उस भाग पर ध्यान दें जहां dll को C: \ Program Files (x86) \ Common Files \ Steam में कॉपी किया गया है, और फिर लोड किया गया है। हम यह सुनिश्चित करेंगे कि हमारी लाइब्रेरी C: \ Steam \ b4 से कॉपी की गई है। दुर्भाग्य से, चेक पहले आयोजित किए जाते हैं, जिसमें पुस्तकालय के हस्ताक्षर भी शामिल हैं, ताकि इसे प्रतिस्थापित नहीं किया जा सके (ओह, विडंबना)।

इसलिए, मैं चरणों में हस्ताक्षर करूंगा। चरणों को समान कार्यों के समूहों में जोड़ा जाता है। प्रत्येक चरण के लिए, यह इंगित किया जाएगा कि कहां लॉन्च किया जाना है और क्या होता है (मैंने विभिन्न कंसोल विंडोज़ cmd1 और cmd2 कहा है)।

1. फ़ोल्डर बनाएँ C: \ Steam \ bin और cmd1 में निष्पादित करें:
   CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b1
2. Cmd1 में हम ऑपलॉक डालते हैं:
   SetOpLock.exe C: \ Steam \ b1 \ steamservice.dll
3. हम स्टीम क्लाइंट सेवा शुरू करते हैं, हम cmd1 में देखते हैं कि हमने फ़ाइल तक पहुंच पकड़ी है।
   
   ***
4. C: \ Steam \ bin को हटाएं, C: \ भाप \ बिन फ़ोल्डर को इसके स्थान पर और cmd2 निष्पादित करें:
   CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b2
5. Cmd2 में हम ऑपलॉक डालते हैं:
   SetOpLock.exe C: \ Steam \ b2 \ steamservice.dll
6. Cmd1 में हम अनलॉक जारी करते हैं, हम देखते हैं कि cmd2 ने फ़ाइल तक पहुंच पकड़ ली है।
   
   ***
7. हटाएं C: \ Steam \ bin, इसके स्थान पर C: \ Steam \ bin फ़ोल्डर बनाएं और cmd1 निष्पादित करें:
   CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b3
8. Cmd1 में हम ऑपलॉक डालते हैं:
   SetOpLock.exe C: \ Steam \ b3 \ steamservice.dll
9. Cmd2 में हम अनलॉक जारी करते हैं, हम देखते हैं कि cmd1 ने फ़ाइल तक पहुंच पकड़ ली है।
   
   ***
10. हटाएं C: \ Steam \ bin, इसके स्थान पर C: \ Steam \ bin फ़ोल्डर बनाएं और cmd2 निष्पादित करें:
    CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b2
11. Cmd2 में हम ऑपलॉक डालते हैं:
    SetOpLock.exe C: \ Steam \ b2 \ steamservice.dll
12. Cmd1 में हम अनलॉक जारी करते हैं, हम देखते हैं कि cmd2 ने फ़ाइल तक पहुंच पकड़ ली है।
    
    ***
13. हटाएं C: \ Steam \ bin, इसके स्थान पर C: \ Steam \ bin फ़ोल्डर बनाएं और cmd1 निष्पादित करें:
    CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b3
14. Cmd1 में हम ऑपलॉक डालते हैं:
    SetOpLock.exe C: \ Steam \ b3 \ steamservice.dll
15. Cmd2 में हम अनलॉक जारी करते हैं, हम देखते हैं कि cmd1 ने फ़ाइल तक पहुंच पकड़ ली है।
    
    ***
16. हटाएं C: \ Steam \ bin, इसके स्थान पर C: \ Steam \ bin फ़ोल्डर बनाएं और cmd2 निष्पादित करें:
    CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b4
17. Cmd1 में हम अनलॉक जारी करते हैं

हालांकि यह जटिल दिखता है, वास्तव में यह विचार सरल है: 6 सी से फाइल तक पहुंच सी: \ स्टीम \ बिन \ स्टीमर सर्विस। पहले 5 बार विभिन्न फ़ोल्डरों से मूल फाइलें दी गई थीं (एक्सेस के क्रम में: बी 1, बी 2, बी 3, बी 2, b3), और छठी बार एक पेलोड वाली फाइल को कॉपी करने के लिए दिया गया था।

योजनाबद्ध रूप से, मैंने इसे इस तरह दर्शाया:


बाईं ओर सामान्य व्यवहार है, दाईं ओर शोषण व्यवहार है।

संचालन 3. कार्यान्वित पुस्तकालय

पेलोड के लिए, मैंने सबसे पहले अपने सबसे खास dll का इस्तेमाल किया, जो कि DllEntry में एक इंटरैक्टिव कंसोल बनाता है। चूंकि dll से कोड को स्टीम क्लाइंट सेवा के संदर्भ में निष्पादित किया जाएगा, इसलिए इसे सेवा के समान अधिकार के साथ निष्पादित किया जाएगा - NT AUTHORITY \ SYSTEM। लेकिन ऑपरेशन के परिणामस्वरूप, कंसोल दिखाई नहीं दिया।

डाउनलोड के बाद, स्टीम सेवा अभी भी समझती है कि उन्होंने एक लिंडन को ऊपर खिसका दिया है और काम खत्म कर दिया है, इसलिए मेरे डीएल से पेलोड को निष्पादित करने का प्रबंधन नहीं किया।

मुझे थोड़ा घूमना पड़ा, और यह पता चला कि डीएल को लोड करने के बाद सेवा कार्यों के अस्तित्व की जांच करती है

 int WINAPI SteamService_RunMainLoop() void WINAPI SteamService_Stop() 

पुस्तकालय में। इसके अलावा, सेवा पहले फ़ंक्शन को कॉल करती है, जहां मैंने पेलोड डालने का फैसला किया (सेवा के अधिकारों के साथ एक इंटरैक्टिव कंसोल लॉन्च करना - NT AUTHORITY \ SYSTEM)। अब बस इतना ही है - हम सभी चरणों को दोहराते हैं और अधिकतम अनुमतियों के साथ एक कंसोल प्राप्त करते हैं।

निष्कर्ष

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

अपडेट (08/22/2019)

फिलहाल, दो खबरें हैं:

1. बीटा क्लाइंट ने पैच फिक्स प्राप्त किया । मैं देखूंगा जब अपडेट मुख्य ग्राहक तक पहुंच जाएगा।
2. वाल्व ने एलपीई नीति को बदल दिया है। और यह बहुत अच्छी खबर है!

अपडेट (08/27/2019)

अच्छी खबर है।

1. मुख्य ग्राहक को पैच अपडेट प्राप्त हुआ ।
2. मुझे H1 पर प्रतिबंध लगा दिया गया और उसने इनाम दिया

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