स्टीम क्लाइंट ने एक खतरनाक भेद्यता को समाप्त कर दिया जो दस वर्षों से वहां छिपा हुआ था

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

सुरक्षा के प्रति जागरूक पीसी खिलाड़ियों ने देखा है कि वाल्व ने हाल ही में एक नया स्टीम क्लाइंट अपडेट जारी किया है।

इस पोस्ट में, मैं कम से कम दस वर्षों के लिए स्टीम क्लाइंट में मौजूद एक संबंधित बग की कहानी बताने के लिए काम पर गेम खेलने के लिए बहाना बनाना चाहता हूं, जो पिछले साल जुलाई तक रिमोट कोड निष्पादन (रिमोट कोड निष्पादन, आरसीई) को जन्म दे सकता है। सभी 15 मिलियन सक्रिय ग्राहकों में।

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

हमने वाल्व को 20 फरवरी, 2018 को भेद्यता घोषित किया, और कंपनी के क्रेडिट के लिए, इसे 12 घंटे से भी कम समय बाद बीटा शाखा में तय किया। 22 मार्च, 2018 को फिक्स को स्थिर शाखा में ले जाया गया।

संक्षिप्त समीक्षा

भेद्यता का आधार स्टीम क्लाइंट लाइब्रेरी के अंदर के ढेर को नुकसान था, जिसे दूरस्थ रूप से कहा जा सकता है, कोड के उस हिस्से में जो कई प्राप्त यूडीपी पैकेटों से खंडित डेटाग्राम को पुनर्प्राप्त करने में शामिल था।

स्टीम क्लाइंट अपने स्वयं के प्रोटोकॉल (स्टीम प्रोटोकॉल) के माध्यम से डेटा का आदान-प्रदान करता है, जिसे यूडीपी के शीर्ष पर लागू किया जाता है। इस प्रोटोकॉल में दो क्षेत्र हैं जो भेद्यता के कारण विशेष रूप से दिलचस्प हैं:

• पैकेट की लंबाई
• खंगाले गए डेटाग्राम की कुल लंबाई

साधारण चेक की कमी के कारण त्रुटि हुई थी। कोड ने यह सत्यापित नहीं किया कि पहले खंडित डेटाग्राम की लंबाई डेटाग्राम की कुल लंबाई से कम या उसके बराबर है। यह एक आम ओवरसाइट की तरह प्रतीत होता है जो सभी बाद के पैकेटों के लिए है जो डेटाग्राम के टुकड़े प्रसारित करते हैं, चेक किया जाता है।

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

नीचे भेद्यता और उससे जुड़े शोषण का तकनीकी विवरण दिया गया है
कोड निष्पादन कार्यान्वयन।

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

जानकारी के लिए आवश्यक जानकारी

प्रोटोकॉल

तृतीय पक्ष (उदाहरण के लिए, https://imfreedom.org/wiki/Steam_Friends ), स्टीम क्लाइंट द्वारा उत्पन्न ट्रैफ़िक के विश्लेषण के आधार पर, रिवर्स इंजीनियरिंग का प्रदर्शन किया और स्टीम प्रोटोकॉल का विस्तृत प्रलेखन बनाया। प्रारंभ में, प्रोटोकॉल 2008 में प्रलेखित किया गया था और तब से बहुत कुछ नहीं बदला है।

प्रोटोकॉल UDP डेटाग्राम की एक धारा पर एक कनेक्शन की स्थापना के साथ एक ट्रांसमिशन प्रोटोकॉल के रूप में लागू किया गया है। पैकेज, ऊपर दिए गए लिंक पर प्रलेखन के अनुसार, निम्नलिखित संरचना है:


महत्वपूर्ण पहलू:

• सभी पैकेट " VS01 " के 4 बाइट्स से शुरू होते हैं
• packet_len उपयोगी जानकारी की लंबाई का वर्णन करता है ( अप्रकाशित डेटाग्राम के लिए, मान डेटा की लंबाई के बराबर है)
• प्रकार पैकेज के प्रकार का वर्णन करता है, जिसमें निम्न मान हो सकते हैं:
  
  • 0x2 कॉल प्रमाणीकरण
  • 0x4 कनेक्शन स्वीकार करें
  • 0x5 रीसेट कनेक्शन
  • 0x6 एक पैकेट डेटाग्राम का एक टुकड़ा है
  • 0x7 पैकेज एक अलग डेटाग्राम है
• स्रोत और गंतव्य फ़ील्ड पहचानकर्ता हैं, जो स्टीम क्लाइंट के भीतर कई कनेक्शनों पर पैकेट को सही ढंग से रूट करने के लिए असाइन किए गए हैं
• मामले में पैकेट डेटाग्राम का एक टुकड़ा है:
  
  • विभाजन_ संकेत यह बताता है कि डेटाग्राम के टुकड़े कितने टुकड़ों में हैं
  • data_len बरामद किए गए डेटाग्राम की कुल लंबाई को इंगित करता है
• इन यूडीपी पैकेटों की प्रारंभिक प्रोसेसिंग फंक्शन CUDPConnection में होती है :: UDPRecvPkt के अंदर steamclient.dll

एन्क्रिप्शन

डेटाग्राम पैकेट की उपयोगी जानकारी AES-256 एक कुंजी का उपयोग करके एन्क्रिप्ट की गई है, जो प्रत्येक सत्र में क्लाइंट और सर्वर के बीच बातचीत की जाती है। मुख्य बातचीत इस प्रकार की जाती है:

• क्लाइंट एक 32-बाइट एईएस यादृच्छिक कुंजी उत्पन्न करता है, और आरएसए इसे सर्वर पर भेजने से पहले वाल्व सार्वजनिक कुंजी के साथ एन्क्रिप्ट करता है।
• निजी कुंजी रखने वाला सर्वर इस मान को डिक्रिप्ट कर सकता है और इसे AES-256 कुंजी के रूप में स्वीकार कर सकता है, जिसका उपयोग सत्र में किया जाएगा
• कुंजी के सहमत होने के बाद, वर्तमान सत्र की सभी उपयोगी जानकारी इस कुंजी के साथ एन्क्रिप्ट की गई है।

भेद्यता

भेद्यता CUDPConnection वर्ग के RecvFragment विधि के अंदर मौजूद है। वाष्पशील पुस्तकालय के रिलीज़ संस्करण में कोई प्रतीक नहीं हैं, हालांकि, जब हमारे लिए ब्याज के एक समारोह में द्विआधारी लाइनों के माध्यम से खोज करते हैं, तो " CUDPConnection :: RecvFragment " का लिंक मिलता है। इस फ़ंक्शन में प्रवेश तब किया जाता है जब क्लाइंट को UDP पैकेट मिलता है जिसमें 0x6 का स्टीम डेटाग्राम ("डेटाग्राम का टुकड़ा") होता है।

1. फ़ंक्शन यह सुनिश्चित करने के लिए कनेक्शन की स्थिति की जांच करके शुरू करता है कि यह " कनेक्टेड " स्थिति में है।
2. फिर, स्टीम डेटाग्राम में data_len फ़ील्ड को यह सुनिश्चित करने के लिए जांचा जाता है कि इसमें 0x20000060 बाइट्स से कम है (ऐसा लगता है कि यह मान मनमाने ढंग से चुना गया है)।
3. यदि चेक पास हो जाता है, तो फ़ंक्शन यह जांचता है कि क्या कनेक्शन कुछ डेटाग्राम के टुकड़े एकत्र करता है, या क्या यह स्ट्रीम का पहला पैकेट है।


4. यदि यह स्ट्रीम का पहला पैकेट है, तो स्प्लिट_काउंट फ़ील्ड को यह देखने के लिए चेक किया जाता है कि यह पैकेट कितने स्ट्रेच को खींचेगा
5. यदि धारा को कई पैकेटों में विभाजित किया जाता है, तो seq_no_of_first_pkt फ़ील्ड को यह सुनिश्चित करने के लिए चेक किया जाता है कि यह मौजूदा पैकेट के सीरियल नंबर से मेल खाती है। यह सुनिश्चित करता है कि पैकेट स्ट्रीम में पहला है।
6. 0x20000060 बाइट्स की सीमा के खिलाफ डेटा_लेन फ़ील्ड को फिर से जांचा जाता है । इसके अलावा, यह सत्यापित किया जाता है कि विभाजित_काउंट 0x709b पैकेट से कम है।


7. यदि ये स्थितियां पूरी हो जाती हैं, तो एक बूलियन मान यह इंगित करने के लिए सेट है कि हम अब टुकड़े एकत्र कर रहे हैं। यह भी जांचता है कि हमारे पास अभी तक एक बफ़र नहीं है जो कि भंडारण के लिए आवंटित किया गया है।


8. यदि टुकड़ा संग्रह बफर को सूचक शून्य नहीं है, तो वर्तमान टुकड़ा संग्रह बफर मुक्त हो जाता है और एक नया बफर आवंटित किया जाता है (नीचे दिए गए आंकड़े में पीले आयत देखें)। यह वह जगह है जहाँ त्रुटि दिखाई देती है। टुकड़ा संग्रह बफर को data_len बाइट्स के आकार में आवंटित किए जाने की उम्मीद है। यदि सब कुछ सफल था (और कोड की जांच नहीं होती है - एक छोटी सी त्रुटि), तो डेटाग्राम की उपयोगी जानकारी को इस बफर में मेमॉव का उपयोग करके कॉपी किया जाता है, यह विश्वास करते हुए कि प्रतिलिपि के लिए बाइट्स की संख्या packet_len में इंगित की गई है ।

डेवलपर का सबसे महत्वपूर्ण निरीक्षण यह था कि चेक " पैकेट_लेन डेटा से कम या बराबर है_लेन " का प्रदर्शन नहीं किया गया है। इसका मतलब यह है कि packet_len से कम data_len को स्थानांतरित करना संभव है और बहुत छोटे बफर में कॉपी किए गए packet_len क्षेत्र (2 बाइट्स चौड़ी होने के कारण) तक 64 KB डेटा है, जो ढेर भ्रष्टाचार का शोषण करना संभव बनाता है।

भेद्यता का शोषण

यह खंड मानता है कि ASLR के लिए वर्कअराउंड है। यह इस तथ्य की ओर जाता है कि ऑपरेशन शुरू करने से पहले, steamclient.dll का शुरुआती पता ज्ञात है।

पैकेट स्पूफिंग

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

मेमोरी प्रबंधन

1024 (0x400) बाइट्स से अधिक मेमोरी आवंटित करने के लिए, एक मानक सिस्टम एलोकेटर का उपयोग किया जाता है। 1024 बाइट्स से कम या बराबर मेमोरी आवंटित करने के लिए, स्टीम अपने स्वयं के आवंटनकर्ता का उपयोग करता है जो सभी समर्थित प्लेटफार्मों पर समान काम करता है। इस लेख में इस वितरक के बारे में विस्तार से चर्चा नहीं की जाएगी, निम्नलिखित प्रमुख पहलुओं के अपवाद के साथ:

1. मेमोरी के बड़े ब्लॉकों को सिस्टम एलोकेटर से अनुरोध किया जाता है, जो तब स्टीम क्लाइंट मेमोरी आवंटन अनुरोधों के तहत उपयोग के लिए एक निश्चित आकार के टुकड़ों में विभाजित होते हैं।
2. चयन क्रमिक रूप से किया जाता है, उपयोग किए गए टुकड़ों के बीच कोई मेटाडेटा उन्हें अलग नहीं करता है।
3. प्रत्येक बड़े ब्लॉक एक एकल लिंक की गई सूची के रूप में लागू की गई अपनी स्वयं की मुफ्त मेमोरी सूची को संग्रहीत करता है।
4. मुक्त मेमोरी सूची में सबसे ऊपर स्मृति में पहले मुक्त टुकड़े को इंगित करता है, और इस टुकड़े के पहले 4 बाइट्स अगले मुक्त टुकड़ा (यदि कोई मौजूद है) को इंगित करता है।

मेमोरी आवंटन

जब स्मृति आबंटित की जाती है, तो पहले मुक्त ब्लॉक को मुक्त मेमोरी सूची के शीर्ष से काट दिया जाता है, और इस ब्लॉक के पहले 4 बाइट्स जो अगले_फ्री_ब्लॉक के लिए होते हैं, उन्हें एलाटेटर वर्ग के अंदर फ्रीलास्ट_हेड सदस्य चर में कॉपी किया जाता है।

मुक्त स्मृति

जब एक ब्लॉक को मुक्त किया जाता है, तो फ्रीलास्ट_हेड फ़ील्ड को फ्रीक्ड ब्लॉक के अगले 4 बाइट्स ( नेक्स्ट_फ्री_ब्लॉक ) पर कॉपी किया जाता है, और फ्रीक्ड ब्लॉक के पते को वितरक वर्ग के सदस्य चर फ्रीलास्ट_हेड में कॉपी किया जाता है।

कैसे एक रिकॉर्डिंग आदिम प्राप्त करने के लिए

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

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

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

क्या उपयोग करें: डेटाग्राम या टुकड़े

मेमोरी भ्रष्टाचार के साथ एक त्रुटि डेटाग्राम के टुकड़े (प्रकार 6 के पैकेट) के प्रसंस्करण के लिए जिम्मेदार कोड में होती है। क्षति की घटना के बाद, RecFFragment () फ़ंक्शन एक ऐसी स्थिति में है जिसमें यह आगे के टुकड़े प्राप्त करने की अपेक्षा करता है। हालांकि, अगर वे आते हैं, तो एक चेक किया जाता है:

fragment_size + num_bytes_already_received < sizeof(collection_buffer)

लेकिन जाहिर है, यह ऐसा मामला नहीं है, क्योंकि हमारे पहले पैकेज ने पहले ही इस नियम का उल्लंघन किया है (इस चेक को छोड़ना एक त्रुटि का अस्तित्व संभव है) और एक त्रुटि उत्पन्न होगी। इससे बचने के लिए, आपको मेमोरी भ्रष्टाचार के बाद CUDPConnection :: RecvFragment () विधि से बचने की आवश्यकता है।

सौभाग्य से, CUDPConnection :: RecvDatagram () अभी भी टाइप 7 (डेटाग्राम) के भेजे गए पैकेटों को प्राप्त और संसाधित कर सकता है जब तक कि RecvFragment () मान्य नहीं है, और इसका उपयोग रिकॉर्डिंग आदिम शुरू करने के लिए किया जा सकता है।

एन्क्रिप्शन समस्याएँ

RecvDatagram () और RecvFragment () द्वारा प्राप्त पैकेट को एन्क्रिप्ट किए जाने की उम्मीद है। रिकवेटाग्राम () के मामले में , रसीद के लगभग तुरंत बाद डिक्रिप्शन किया जाता है। RecvFragment () के मामले में , यह सत्र में अंतिम टुकड़ा प्राप्त करने के बाद होता है।

भेद्यता के दोहन की समस्या उत्पन्न होती है क्योंकि हम प्रत्येक सत्र में बनाई जाने वाली एन्क्रिप्शन कुंजी को नहीं जानते हैं। इसका मतलब यह है कि हम जो भी ओपी कोड / शेल कोड भेजते हैं, उसे AES256 का उपयोग करके "डिक्रिप्ट" किया जाएगा, जो हमारे डेटा को कचरे में बदल देगा। इसलिए, ऑपरेशन की एक विधि खोजना आवश्यक है, जो पैकेट प्राप्त करने के लगभग तुरंत बाद संभव है, इससे पहले कि डिक्रिप्शन प्रक्रियाएं पैकेट बफर में निहित उपयोगी जानकारी को संसाधित करने में सक्षम होंगी।

कोड निष्पादन कैसे प्राप्त करें

ऊपर वर्णित डिक्रिप्शन प्रतिबंध को देखते हुए, आने वाले डेटा के डिक्रिप्शन से पहले ऑपरेशन किया जाना चाहिए। यह अतिरिक्त प्रतिबंध लगाता है, लेकिन कार्य अभी भी संभव है: आप सूचक को फिर से लिख सकते हैं ताकि यह बाइनरी फ़ाइल के डेटा अनुभाग के अंदर एक अनुमानित जगह में संग्रहीत CWorkThreadPool ऑब्जेक्ट को इंगित करता है। यद्यपि इस वर्ग का विवरण और आंतरिक कार्यक्षमता अज्ञात है, लेकिन इसके नाम से माना जा सकता है कि यह थ्रेड्स के एक पूल का समर्थन करता है जिसका उपयोग आप तब कर सकते हैं जब आपको "काम" करने की आवश्यकता होती है। बाइनरी फ़ाइल में कई डीबगिंग लाइनों का अध्ययन करने के बाद, आप समझ सकते हैं कि ऐसे कार्यों के बीच एन्क्रिप्शन और डिक्रिप्शन ( CWorkItemNetFilterEncrypt , CWorkItemNetFilterDecrypt ) है, इसलिए जब ये कार्य पंक्तिबद्ध होते हैं, तो CWorkThreadPool क्लास का उपयोग किया जाता है । इस पॉइंटर को ओवरराइट करके और हमें जिस जगह की ज़रूरत है, उस पर लिखकर, हम वीआईबीटी पॉइंटर और इसके साथ जुड़े वाइबेट का अनुकरण कर सकते हैं, जो हमें कोड निष्पादित करने की अनुमति देता है, उदाहरण के लिए, जब CWorkThreadPool :: AddWorkItem () कहा जाता है, जो किसी भी डिक्रिप्शन प्रक्रियाओं से पहले होना चाहिए।

नीचे दिया गया आंकड़ा ईआईपी रजिस्टर के नियंत्रण के चरण तक भेद्यता के सफल शोषण को दर्शाता है।


अब से, आप एक आरओपी श्रृंखला बना सकते हैं जो मनमाने कोड के निष्पादन की ओर ले जाती है। नीचे दिए गए वीडियो में दिखाया गया है कि कैसे एक हमलावर दूरस्थ रूप से विंडोज 10 के पूरी तरह से पैच किए गए संस्करण में एक विंडोज कैलकुलेटर शुरू करता है।

संक्षेप में देना

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

अंत में, यह जानकारी के जिम्मेदार प्रकटीकरण की प्रक्रिया के बारे में बात करने लायक है। हमने इस बग को वाल्व को अपनी सुरक्षा टीम ( Security@valvesoftware.com ) को एक पत्र में लगभग 4 बजे GMT पर सूचना दी और केवल 8 घंटे बाद, एक फिक्स बनाया गया और बीटा क्लाइंट स्टीम में लॉन्च किया गया। इसके लिए धन्यवाद, वाल्व अब प्रतियोगिता की हमारी (काल्पनिक) तालिका में पहले स्थान पर है "जो भेद्यता को तेजी से ठीक करेगा" - अन्य कंपनियों की त्रुटियों का खुलासा करने की तुलना में एक सुखद अपवाद, जो अक्सर एक लंबी अनुमोदन प्रक्रिया का परिणाम होता है।

एक पेज जो सभी क्लाइंट अपडेट के विवरण का वर्णन करता है