तीसरा स्टीम विंडोज क्लाइंट भेद्यता, लेकिन 0day नहीं

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

इतना समय पहले नहीं, मैंने स्टीम की दो कमजोरियों के बारे में बात की: सीवीई -2019-14743 और सीवीई-2019-15316 । इस बारे में एक पूरी कहानी थी कि मैंने उन्हें कैसे पंजीकृत करने की कोशिश की, मैं सफल नहीं हुआ, मुझे प्रतिबंधित कर दिया गया, और केवल सार्वजनिक प्रकटीकरण और समुदाय की मदद के बाद ही मैं परिणाम प्राप्त करने में सफल रहा। वाल्व ने माफी मांगने का नाटक किया और हैकरऑन पर मुझे नंगा कर दिया, इसलिए मैंने इस सेवा के माध्यम से अगली भेद्यता को स्थानांतरित करने का फैसला किया। तीसरी बार ( हाफ-लाइफ 3 के बारे में एक स्पष्ट मजाक होना चाहिए ), सब कुछ कम या ज्यादा सफलतापूर्वक हो गया।

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

भेद्यता आपको आंशिक रूप से नियंत्रित सामग्री (या मौजूदा फ़ाइलों में आंशिक रूप से नियंत्रित सामग्री जोड़ने) के साथ फ़ाइलें बनाने की अनुमति देती है। असुरक्षित सेवा का संस्करण 5.31.28.21 है (स्टीमस् सेवा। Exe फ़ाइल से डेटा)। सबसे पहले, मैं वर्णन करूंगा कि भेद्यता का दोहन कैसे किया जाए, और फिर मैं संभावित परिणामों का वर्णन करूंगा।

चरण 1. पर्यावरण

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

उपयोगकर्ता के लिए सुलभ किसी भी स्थान पर एक फ़ोल्डर बनाएँ (उदाहरण के लिए, "C: \ test")। इस फ़ोल्डर में, आपको स्टीम। Exe और steamclient.dll फ़ाइलों को स्टीम स्रोत फ़ोल्डर से कॉपी करने की आवश्यकता है (डिफ़ॉल्ट रूप से, यह "C: \ Program Files (x86) \ Steam") है। एक खाली लॉग सबफ़ोल्डर बनाएं ("C: \ test \ log")।

अब रजिस्ट्री को ठीक करते हैं: "HKLM \ Software \ wow6432node \ वाल्व \ भाप" शाखा में, "InstallPath" पैरामीटर का मान बदलकर "C: \ test \ 1 \" करें। " आमतौर पर, गैर-व्यवस्थापक उपयोगकर्ताओं के लिए, HKLM के अंदर रजिस्ट्री शाखाएं लिखने योग्य नहीं होती हैं, लेकिन इस मामले में नहीं। वाल्व स्थापित करते समय, वे HKLM के अंदर अपनी शाखा में ऐसे अधिकार निर्धारित करते हैं कि इसमें सभी उपयोगकर्ता ("उपयोगकर्ता" समूह के लिए "पूर्ण नियंत्रण") उपलब्ध हैं।

चरण 2. चलो थोड़ा परीक्षण करते हैं

स्टीम क्लाइंट सेवा लॉन्च करें। उसके बाद यह बंद हो जाता है (यह कुछ सेकंड के बाद स्वचालित रूप से हो जाएगा), फ़ोल्डर की सामग्री की जांच करें "C: \ test \ Log" - हमें वहां फ़ाइल "service_log.txt" मिलती है। लॉग की सामग्री कुछ इस तरह होगी:

08/27/19 13:45:01 : ERROR: SteamService: Invalid file signature C:\test\1\..\bin\SteamService.dll 

ध्यान दें कि पथ "C: \ test \ 1 \" "पथ" C: \ test "के बराबर है, इसलिए Windows ने काम करने के लिए दूसरे का उपयोग किया, और पहला संदेश में मिला। फ़ाइल "service_log.txt" हटाएं और जारी रखें।

चरण 3. अधिक पाठ जोड़ें।

एक दिलचस्प तथ्य: जब विंडोज "\" वाले पथों के साथ काम करता है, तो यह स्वचालित रूप से ऐसे पथों को सरल करता है। मंचन के लिए कोई जाँच नहीं कर रहा है।

उदाहरण के लिए, पथ "C: \ 1 \ <परीक्षण> \ .." को इस तथ्य के बावजूद "C: \ 1" में परिवर्तित किया जाएगा कि कोण कोष्ठक का उपयोग फ़ोल्डर नाम में नहीं किया जा सकता है।

पहले चरण में, हमने रजिस्ट्री में पथ पंजीकृत किया, अब हम इसमें लाइन ब्रेक जोड़ देंगे। यह सरल कोड लिखकर किया जा सकता है, लेकिन यह regedit इंटरफ़ेस से भी किया जा सकता है। बस रजिस्ट्री शाखा "HKLM \ Software \ wow6432node \ वाल्व" खोलें और "InstallPath" पैरामीटर के संदर्भ मेनू में "बाइनरी डेटा संशोधित करें" का चयन करें। हेक्स संपादक जैसा कुछ दिखाई देगा जहां आप आवश्यक संपादन कर सकते हैं।



हम सेवा का एक और परीक्षण लॉन्च करेंगे और अपने कार्यों के परिणाम की जांच करेंगे।



परीक्षण के बाद, आपको फिर से "service_log.txt" फ़ाइल को हटाना होगा।

चरण 4. बनाई गई फ़ाइल को रीडायरेक्ट करें

बिना व्यवस्थापक अधिकारों के उपयोगकर्ता एक फ़ाइल से दूसरी फ़ाइल में प्रतीकात्मक लिंक नहीं बना सकते हैं। लेकिन एक फ़ोकस है - आप अन्य प्रकार के लिंक को जोड़ सकते हैं जो उपयोगकर्ताओं को बिना किसी प्रशासक के अधिकारों के लिए उपलब्ध हैं जो एक फ़ाइल से फाइल के लिए सिम्लिंक के करीब है।

सबसे पहले, फ़ोल्डर "C: \ test \ Log" से "\ RPC Control \" के लिए NTFS आरपार बिंदु (NTFS आरोह बिंदु के लिए दूसरा नाम) बनाएँ। "" RPC Control \ "सामान्य अर्थों में एक सामान्य फ़ोल्डर नहीं है, इसे देखा नहीं जा सकता है, उदाहरण के लिए, एक्सप्लोरर में। यह एक सिस्टम ऑब्जेक्ट डायरेक्टरी है, जिसके अंदर, उदाहरण के लिए, म्यूटेक्स, इवेंट और अन्य समान ऑब्जेक्ट्स नाम हैं। एनटीएफएस पुनर्मिलन बिंदु के माध्यम से पुनर्निर्देशन उसके लिए क्यों काम करता है स्पष्ट नहीं है, सबसे अधिक संभावना है, बिंदु फ़ाइल सिस्टम और ऑब्जेक्ट निर्देशिकाओं में फ़ोल्डर्स के लिए समान सार का उपयोग करना है। ऑब्जेक्ट डायरेक्टरी से, आप एडमिनिस्ट्रेटर राइट्स के बिना किसी फाइल के लिए सिम्लिंक बना सकते हैं। "\ RPC Control \ service_log.txt" <-> "C: \ Path \ to \ file" फ़ॉर्म का एक सिमलिंक बनाएं।

नतीजतन, "C: \ test \ log \ service_log.txt" किसी भी कॉल को फ़ाइल "C: \ Path \ to to" फ़ाइल पर पुनर्निर्देशित किया जाएगा। इस तरह के पुनर्निर्देशन को बनाने के लिए दो बुनियादी आवश्यकताएं होती हैं - वह फ़ोल्डर जिसमें से NTFS रिपार बिंदु बनाया जाता है वह खाली होना चाहिए, और यह उपयोगकर्ता के लिए भी योग्य होना चाहिए। पहली शर्त को पूरा करने के लिए, प्रत्येक परीक्षण के बाद हमने "service_logs.txt" फ़ाइल को हटा दिया, दूसरी स्थिति इस तथ्य से सुनिश्चित होती है कि हमने उपयोगकर्ता नियंत्रित स्थान पर स्रोत फ़ोल्डर बनाया है।

एक विशेष उपयोगिता है जो इस तरह के जोड़े को सीमलिंक बनाती है - CreateSymlink और GitHub पर डाउनलोड के लिए उपलब्ध है । उपयोगिता उपयोग:

 CreateSymlink.exe <> <> 

हमारे मामले में, यह होगा:

 CreateSymlink.exe "C:\test\logs\service_log.txt" "C:\\\" 

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

प्रभाव

अब मैं कम से कम महत्वपूर्ण और आरोही के संभावित प्रभावों को सूचीबद्ध करूंगा।

1. DoS
   
   यदि सिमलिंक का लक्ष्य "C: \ Windows \ System32 \ config \ SAM" या "C: \ Windows \ System32 \ config \ SECURITY" सेट करना है, तो यह संभावना नहीं है कि ओएस रिबूट के बाद बूट करने में सक्षम होगा।
2. इंटरनेट पर उपयोगकर्ता पुनर्निर्देशन
   
   सिम्लिंक "C: \ Windows \ system32 \ driver \ etc \ मेजबान" का लक्ष्य निर्धारित करें और वहां "127.0.0.1 google.com" जैसी एक पंक्ति जोड़ें।
   
   परिणाम:
   
   
3. क्षैतिज ईओपी
   विशेषाधिकारों में एक क्षैतिज वृद्धि उन अधिकारों में परिवर्तन है जिसमें हम उच्च अधिकारों तक नहीं पहुंचते हैं, लेकिन समान स्तर के अधिकारों के लिए, लेकिन अन्य वस्तुओं के सापेक्ष, उदाहरण के लिए, अन्य उपयोगकर्ताओं के अधिकारों के लिए।
   
   सिम्लिंक "C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp \ run.bat" का लक्ष्य निर्धारित करें और वहां "start C: \ test \ 1.exe" जैसी एक पंक्ति जोड़ें।
   C / \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp फ़ोल्डर की सभी फाइलें उपयोगकर्ताओं द्वारा लॉग इन करने पर निष्पादित होती हैं। इस प्रकार, एक उपयोगकर्ता दूसरे उपयोगकर्ता को कोड चलाने के लिए बाध्य कर सकता है। बैट फ़ाइल से, सभी लाइनों को बारी-बारी से निष्पादित किया जाएगा। पहला और आखिरी बस कुछ भी नहीं करेगा, लेकिन कार्यान्वित कमांड "स्टार्ट सी: \ test \ 1.exe" काम करेगा।
   
   इस तरह की कमांड की शुरुआत के साथ, एक सूक्ष्मता है - पथ के सामान्यीकरण के दौरान वर्णों को ध्यान में रखा जाएगा, इसलिए सही संचालन के लिए रजिस्ट्री में पथ के लिए कुछ और \ ".." जोड़ना आवश्यक होगा।
4. कार्यक्षेत्र EoP
   वर्टिकल विशेषाधिकार वृद्धि एक सामान्य वृद्धि है, उदाहरण के लिए, NT AUTHORITY \ SYSTEM के प्रशासक अधिकारों के बिना उपयोगकर्ता से।
   
   अक्सर आप ऐसे सॉफ़्टवेयर पा सकते हैं जो उच्च अधिकारों के साथ पाठ स्क्रिप्ट निष्पादित करते हैं। हम ऐसी स्क्रिप्ट्स में कमांड जोड़ सकते हैं और उच्च अनुमतियों के साथ हमारे कोड को निष्पादित कर सकते हैं। मुझे एक साफ OS में ऐसी स्क्रिप्ट्स नहीं मिलीं, इसलिए आप इस तरह के शोषण का प्रदर्शन नहीं कर सकते। लेकिन एक उदाहरण के रूप में, मैं बैट फ़ाइलों को निर्दिष्ट कर सकता हूं जो कि डोमेन में ओएस के लिए NVIDIA और VmWare या लॉगऑन स्क्रिप्ट द्वारा बनाई गई हैं।

इसके अतिरिक्त, बढ़ाने के लिए, आप टूटे हुए प्रारूप के साथ xml-files, ini-files बनाने की क्षमता की जांच कर सकते हैं। दुर्भाग्य से, बहुत सारे विकल्प हैं - टास्कशेड्यूलर के लिए कार्य बनाना, .manifest और अन्य लाइब्रेरी डाउनलोड के साथ काम करना, और कई अन्य। यह मुझे लगता है कि ऊपर वर्णित परिणाम भेद्यता के परिणामों को समझने के लिए पहले से ही पर्याप्त हैं।

समय

चित्र को पूरा करने के लिए, मैं इस भेद्यता पर एक उबाऊ समय देता हूँ।
08/26 - एक भेद्यता मिली।
27 अगस्त - h1 पर अनबन, एक रिपोर्ट प्रकाशित की।
12.09 - एक सुधार जारी किया गया है ।

निष्कर्ष

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

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

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