एक कमजोर विंडोज ड्राइवर का शोषण कैसे करें

CVE-2020-15368 के लिए शोषण और प्रूफ ऑफ कॉन्सेप्ट (PoC)। Asrock ने अपने RGB नियंत्रक कॉन्फ़िगरेशन टूल के लिए rweverything ड्राइवर को पुनः पैकेज किया और उस पर हस्ताक्षर किए। उन्होंने अपने ioctls को एन्क्रिप्ट करके इसे "सुरक्षित" किया... lol। हमें यह CVE पिछली गर्मियों में दुर्घटनावश मिला था, और जहाँ तक मुझे पता है, ड्राइवर अभी भी पैच नहीं किया गया है। प्रभाव निश्चित रूप से कर्नेल में मनमाना कोड निष्पादन आदि है। तो इस "0day" का आनंद लें lol।

यदि आप मेरे साथ इस बात पर बहस करना चाहते हैं कि क्या यह एक वास्तविक BONA FIDE CVE है, तो कृपया मुझसे Twitter पर संपर्क करने में संकोच न करें, हम सार्वजनिक सोशल मीडिया पर एक बड़ी लड़ाई कर सकते हैं और यह इसमें शामिल सभी लोगों के लिए वास्तव में रोमांचक होगा! मैं इस बग के लिए एक डोमेन भी खरीदूंगा यदि आप ऐसा चाहते हैं। यह सब मार्केटिंग के बारे में है!!!!

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

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

पृष्ठभूमि

क्वारंटाइन में फँसे हुए, मेरे रूममेट (Pear0, Codetector) और मैं Pear0 के नए Asrock मदरबोर्ड पर बेवकूफी कर रहे थे। चमकीले लाल LED बेहद कष्टप्रद थे और उन्हें Linux पर कॉन्फ़िगर करना संभव नहीं था। इस प्रकार हमारी योजना थी कि इसे नियंत्रित करने वाले Windows ड्राइवर को रिवर्स करें और Linux पर I/O ऑपरेशन को दोहराएं।

लंबी कहानी को संक्षेप में, हमें यह समझने में अधिक समय नहीं लगा कि ड्राइवर वास्तव में एक सामान्य ड्राइवर है जो किसी भी चीज़ तक मनमाना पढ़ने/लिखने की पहुंच प्रदान करता है। इसमें CR3, CR4 जैसे नियंत्रण रजिस्टर, भौतिक मेमोरी आदि शामिल हैं। इस प्रकार के ड्राइवर डिबगिंग टूल के रूप में उपयोग के लिए अभिप्रेत हैं और विक्रेता की वेबसाइट स्पष्ट रूप से ऐसा बताती है।

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

सेटअप

एक कर्नेल नौसिखिए के रूप में, मैं सोच रहा था कि ड्राइवर को कैसे लोड और इंटरैक्ट किया जाए। पता चला कि यह बेहद आसान है।

आप Process Hacker में ड्राइवर के लिए एक सर्विस बना सकते हैं (स्पष्ट रूप से, ड्राइवर लोड करने के लिए एडमिन की आवश्यकता होती है)। फिर आप बस राइट-क्लिक करके इसे शुरू कर सकते हैं। हाँ, यह वास्तव में इतना सरल है।

हम अपने डिवाइस ऑब्जेक्ट को WinObjEx64 में देख सकते हैं।

हम FileTest में डिवाइस के साथ खेल भी सकते हैं।

ये तीनों टूल अद्भुत हैं, विशेषकर PH और FileTest। ये एक स्विस आर्मी नाइफ की तरह हैं और हर Windows रिवर्सर के टूलबॉक्स में होने चाहिए। उदाहरण के लिए, मेरी समझ से Jonas L ने FileTest में बेवकूफी करते हुए अनगिनत Windows LPE कमजोरियाँ पाई हैं। तो Windows के पास वास्तव में बेवकूफी करने के लिए कुछ बेहतरीन टूल हैं। काश Linux पर भी यह चीज़ होती।

"सुरक्षा" बायपास

Rweverything में एक ioctl है जो एक ioctl को पैरामीटर के रूप में लेता है, जो यह नियंत्रित करता है कि कौन सा ऑपरेशन करना है (मेमोरी पढ़ना, मेमोरी लिखना, MSR पढ़ना, आदि), और कुछ ऑपरेशन-विशिष्ट पैरामीटरों का एक यूनियन जैसे स्रोत पता, गंतव्य पता आदि। जब हम दोनों ड्राइवरों के कोड की तुलना करते हैं:

🤔🤔🤔🤔🤔🤔🤔🤔🤔

फिर भी, ड्राइवर अस्पष्टता के माध्यम से सुरक्षा का एक घटिया प्रयास करता है, जिसमें आवश्यकता होती है कि सभी ioctl कॉल को हार्डकोडेड AES कुंजी के साथ उपयुक्त रूप से एन्क्रिप्ट किया जाए। कोड (कुछ सफाई के बाद) इस प्रकार दिखता है:

if ( IoControlCode == 0x22EC00 )
{

  char enc_key[32];
  memset(enc_key, 0, sizeof(enc_key));
  memmove(enc_key, "C110DD4FE9434147B92A5A1E3FDBF29A", 32ui64);
  memcpy(enc_key + 13, ioctl_args->key, 16);
  
  size_t cb_decrypted = 0;
  my_decrypted_cmd* decryptedCmd = NULL;
  DWORD iv_size = ioctl_args->iv_size;
  DWORD input_size = *(DWORD*)(ioctl_args + bufferLen - 6);

  // really just calls BCrypt API to get an AES implementation
  if ( (unsigned int)decrypt_ioctl_params(enc_key, 32, ioctl_args->iv, iv_size, ioctl_args + bufferLen - input_size - 6, input_size, &decryptedCmd, &cb_decrypted) )
  {
    // Decryption failed
    if ( decryptedCmd )
      ExFreePoolWithTag(decryptedCmd, 0);
    irp->IoStatus.Status = 0xC000000D;
    goto Fail_Out;
  }
  IoControlCode = decryptedCmd->opcode;
  Rweverything_Args = &decryptedCmd->args;
}
else // not 0x22EC00
{
  if ( IoControlCode != 0x22E858 &&
       IoControlCode != 0x22E860 &&
       IoControlCode != 0x22E800 &&
       IoControlCode != 0x22E804 )// whitelisted control codes
    IoControlCode = 0; // block everything else
}

ड्राइवर कुछ उबाऊ ऑपरेशनों की अनुमति देता है जो कुछ PMIO करते हैं, लेकिन सभी "मज़ेदार" नियंत्रण कोड इस डिक्रिप्शन रूटीन के पीछे बंद हैं। इस स्पष्ट अनुमति-सूची के बावजूद, इसमें अभी भी सभी खतरनाक Rweverything कार्यक्षमताएँ शामिल हैं। इन खतरनाक सुविधाओं को छिपाने के बजाय, शायद उन्हें पूरी तरह से हटा दिया जाना चाहिए था।

इसके अलावा, दिलचस्प बात यह है कि यह उपयोगकर्ता को कुंजी का कुछ हिस्सा निर्दिष्ट करने की भी अनुमति देता है (???), किस कारण से मुझे कोई विचार नहीं है। कोड बहुत खराब लिखा गया है।

वैसे भी, इस अजीब एन्क्रिप्टेड API का उपयोग करने और इसे अपनी पसंद के अनुसार मनमाना ioctl कॉल पास करने के लिए क्लाइंट कोड लिखना अपेक्षाकृत आसान है। मैं आपको उसके विवरण से बोर नहीं करूंगा।

ड्राइवर से बात करना

हम ड्राइवर के लिए एक हैंडल खोलते हैं और ioctl को कॉल करने के लिए DeviceIoControl का उपयोग करते हैं, यह बहुत मानक सामान है।

HANDLE hDevice = CreateFileA("\\\\.\\GlobalRoot\\Device\\AsrDrv104", GENERIC_READ | GENERIC_WRITE | SYNCHRONIZE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

// ... set up the encrypted ioctl data

BOOL result = DeviceIoControl(hDevice, 0x22EC00, ioctl_data, in_buf_size, out_buf, sizeof(out_buf), &bytes_returned, NULL);

अब जब हम ड्राइवर के छिपे हुए Rweverything भाग से बात करने में सक्षम हैं, तो पहली चीज़ जो मैं करना चाहता था वह एक क्रैश ट्रिगर करना था ताकि मुझे पता चले कि मेरा ड्राइवर क्लाइंट काम कर रहा है।

इसे प्राप्त करने का सबसे सीधा तरीका CR3 को कबाड़ से ओवरराइट करना है। मुझे पता है कि आप में से कुछ पढ़ने वाले नौसिखिए हैं और यह ठीक है, इसलिए मैं विस्तार से समझाऊंगा। मैं भी बेवकूफ हूँ, इसलिए शायद इससे आपको सीखने में मदद मिलेगी। यदि आप जानते हैं कि आप क्या कर रहे हैं, तो आप इसे छोड़ सकते हैं।

x86 पर, जब पेजिंग सक्षम होती है (आधुनिक ऑपरेटिंग सिस्टम में लगभग हर समय), CR3 शीर्ष स्तर के पेज टेबल डायरेक्ट्री के भौतिक आधार पते की ओर इशारा करता है। यदि आप नहीं जानते कि इसका क्या अर्थ है, तो वर्चुअल मेमोरी के लिए Wikipedia लेख पढ़ें।

जब हम CR3 को कबाड़ से ओवरराइट करते हैं, मान लीजिए 0x0000000000000000, TLB फ्लश हो जाता है, और अगले निर्देश को निष्पादित करने का प्रयास करने पर, प्रोसेसर (विशेष रूप से MMU) इंस्ट्रक्शन पॉइंटर को भौतिक पते में अनुवाद करने का प्रयास करेगा। पता अनुवाद को मूल रूप से CR3 से शुरू होने वाले पेजटेबल वॉक की एक श्रृंखला के रूप में सोचा जा सकता है। CR3 अब भौतिक मेमोरी को 0 पर इंगित करता है, जो मौजूद है और सुलभ है; हालांकि यह अत्यधिक संभावना नहीं है कि यह एक मान्य पेजटेबल है। (पेजटेबल एंट्री, या संक्षेप में PTE, की एक विशिष्ट संरचना होनी चाहिए जिसका उन्हें पालन करना चाहिए।)

जब ऐसा होता है, तो हमें पता अनुवाद पर एक पेज फॉल्ट मिलेगा। अब, सामान्यतः CPU हमें पेज फॉल्ट हैंडलर के पते पर ले जाएगा। लेकिन यह कैसे जानता है कि पेज फॉल्ट हैंडलर फ़ंक्शन कहाँ है? यह इंटरप्ट डिस्क्रिप्टर टेबल (IDT) नामक एक मेमोरी डेटा संरचना में संग्रहीत होता है। प्रोसेसर के पास एक रजिस्टर होता है (sidt और lidt निर्देशों द्वारा पढ़ा/लिखा जाता है) जो IDT का वर्चुअल पता रखता है। क्या आप अब समस्या देख रहे हैं? पेज फॉल्ट को संभालने के लिए हमें पहले एक और वर्चुअल मेमोरी एक्सेस करनी होगी, और इसलिए एक और पता अनुवाद।

बेशक, हमारा दूसरा पता अनुवाद भी फॉल्ट करेगा। अब हमारे पास एक डबल फॉल्ट है: एक फॉल्ट जो पहले पेज फॉल्ट को संभालने के दौरान होता है। यह काफी गंभीर है लेकिन फिर भी पुनर्प्राप्ति योग्य है—प्रोसेसर हमें एक आखिरी मौका देगा। बेशक, यह प्रयास भी तीसरे और अंतिम पेज फॉल्ट, ट्रिपल फॉल्ट द्वारा बुरी तरह से काट दिया जाता है। इस बिंदु पर, CPU बस हार मान लेता है और मशीन को हार्ड रीसेट कर देता है। यदि आपने यह प्रक्रिया भौतिक मशीन पर की होती, तो आप शायद अब तक अपना BIOS स्प्लैश स्क्रीन देख रहे होते।

अब यदि आपके कोई प्रश्न हैं, तो मैं आपको वही उत्तर दूंगा जो मुझे हमेशा दिया जाता था। जो कि Intel Manual Volume 3A (उर्फ बाइबल) पढ़ने जाना है।

ड्राइवर का शोषण

ठीक है, अब हम वास्तव में ड्राइवर का शोषण कैसे करें? चारों ओर देखने पर, हमें एक मुफ्त arb भौतिक मेमोरी रीड/राइट प्रिमिटिव दिखाई देता है। यह मूल रूप से आप जिस भी भौतिक पते को चाहते हैं, उसे MmMapIoSpace का उपयोग करके मैप करता है, आपके बफर को उसमें (या इसके विपरीत) कॉपी करता है, और पते को अनमैप करता है।

छोटा नोट: जब आप कर्नेल डिबगर संलग्न होने पर हमारे जैसे कुछ बेवकूफी भरे तर्कों के साथ MmMapIoSpace को कॉल करने का प्रयास करते हैं, तो आपको बगचेक मिलेगा। आप WinDbg में एक मैजिक बाइट लिखकर इसे बायपास कर सकते हैं। अधिक जानकारी के लिए exploit.cpp में MiShowBadMapper को संदर्भित करने वाली टिप्पणी देखें। मैं वास्तव में नहीं जानता कि वह बकवास किस बारे में है और मुझे वास्तव में पता लगाने की परवाह नहीं है

हम कर्नेल में कोड निष्पादन प्राप्त करने के लिए इस प्रिमिटिव का लाभ कैसे उठा सकते हैं? इस प्रिमिटिव के साथ मुख्य समस्या यह है कि यह भौतिक मेमोरी पर काम करता है। एक यूजरमोड प्रोग्राम के रूप में, हमें लगभग कोई जानकारी नहीं है कि भौतिक मेमोरी का लेआउट कैसा दिखता है—ऑपरेटिंग सिस्टम हमारे लिए यह सब संभालता है। भले ही हम कुछ कर्नेल डेटा संरचनाओं या कर्नेल फ़ंक्शन पॉइंटर्स के वर्चुअल पते प्राप्त कर सकें, हमें नहीं पता कि वे भौतिक पता स्थान में कहाँ हैं।

एक विचार CR3 को पढ़ना, पेज टेबल्स को पढ़ना, और स्वयं वर्चुअल पता अनुवाद करना है। यह एक शानदार विचार है। यह काम नहीं करता है। ऐसा इसलिए है क्योंकि Windows अब आपको MmMapIoSpace के साथ पेज टेबल्स को मैप करने की अनुमति नहीं देता है। इसलिए हमें अधिक चालाक होने की आवश्यकता है।

मैंने xeroxz की तकनीक VDM से उपयोग की। यह काफी सरल है, लेकिन तकनीक काफी चतुर है। हालाँकि हम भौतिक मेमोरी के लेआउट को नहीं जानते हैं, फिर भी हम जो खोज रहे हैं उसे खोजने तक सभी भौतिक मेमोरी को स्कैन कर सकते हैं। एक चीज़ जिसका हम लाभ उठा सकते हैं, वह यह है कि पेज सामग्री हमेशा भौतिक और वर्चुअल दोनों रूप से समान होती है: पेज सीमाओं के सापेक्ष कोई भी ऑफसेट हमेशा संरक्षित रहता है। उदाहरण के लिए, यदि मेरे पास पेज 0x7fff000000000XXX भौतिक फ्रेम 0x0000000123456XXX पर मैप किया गया है, तो सभी पतों का XXX भौतिक और वर्चुअल दोनों पते में समान है। अंतर-पेज संरचना संरक्षित है; इस प्रकार हम किसी दिलचस्प पेज को स्कैन कर सकते हैं जिसे हम ओवरराइट करना चाहते हैं।

सबसे आसान चीज़ जिसे हम ओवरराइट कर सकते हैं, वह शायद कुछ आसानी से पहुँचने योग्य syscall या ioctl हैंडलर है। Windows पर, एक मानक Beep() फ़ंक्शन है जो आपके कंप्यूटर को बीप करता है। मानें या न मानें, यह एक ड्राइवर, Beep.sys में कार्यान्वित है, जो Beep डिवाइस प्रदान करता है। (वास्तव में, आप इसे पहले के WinObjEx64 स्क्रीनशॉट में देख सकते हैं।) कोई भी Beep डिवाइस का उपयोग कर सकता है, और इसे शायद ही कभी कॉल किया जाता है। तो चलिए Beep ioctl हैंडलर को ओवरराइट करते हैं।

हम Beep.sys को IDA में खोल सकते हैं और DeviceIoControl हैंडलर की जांच कर सकते हैं।

पेज ऑफसेट 0x270 पर, हमारे पास यह कोड है जिसमें बाइट्स 40 53 48 ... हैं। इनमें से कोई भी बाइट रीलोकेट नहीं की गई है, इसलिए इस फ़ंक्शन को स्कैन करना बहुत आसान है। यदि रीलोकेटेड बाइट्स होते, तो हमें उन्हें वाइल्डकार्ड करने की आवश्यकता होती। यह उसी तरह का विचार है जैसे कि जब आप कोई गेम हैक लिख रहे होते हैं तो सिग्नेचर स्कैनिंग करते हैं।

इसलिए इस कोड का पता लगाने के लिए भौतिक मेमोरी को स्कैन करने के बाद, हम इसे अपने स्वयं के शेलकोड से ओवरराइट कर सकते हैं। आपको सावधान भी रहना होगा क्योंकि भौतिक मेमोरी में इस पेज की कई प्रतियां पड़ी हो सकती हैं (!) इसलिए सभी प्रतियां ढूंढें।

इस बिंदु पर, हम अपनी प्रक्रिया के सुरक्षा टोकन को सिस्टम प्रक्रिया के साथ स्वैप करके आसानी से विशेषाधिकारों को बढ़ा सकते हैं ताकि nt authority\system अनुमतियाँ प्राप्त हो सकें। दुर्भाग्य से, asrock ड्राइवर को वैसे भी खोलने के लिए एडमिन अनुमतियों की आवश्यकता होती है, इसलिए यह बहुत दिलचस्प नहीं है।

हमारे लिए, हम एक बुनियादी शेलकोड लिखते हैं जो एक स्टेज 2 पेलोड आवंटित और कॉपी करता है, फिर एक नया कर्नेल थ्रेड स्पॉन करता है। हम अपने ओवरराइट किए गए Beep हैंडलर में सब कुछ नहीं कर सकते क्योंकि 1) हम एक पेज तक सीमित हैं और 2) जब हम Beep डिवाइस के लिए अपना हैंडल बंद करने का प्रयास करेंगे तो हम सिस्टम को क्रैश कर देंगे, क्योंकि हमने Beep डिवाइस के बाकी कोड को भी खराब कर दिया है। कर्नेल पॉइंटर्स प्राप्त करने के लिए, यह वास्तव में आसान है क्योंकि NtQuerySystemInformation उन्हें हमें मुफ्त में देगा यदि हम विनम्रता से पूछें।

__int64 __declspec(dllexport) __fastcall MyIRPHandler(struct _DEVICE_OBJECT* a1, IRP* irp)
{
    MyIrpStruct* user_data = (MyIrpStruct*)irp->AssociatedIrp.SystemBuffer;

    void* my_rwx = user_data->nt_ExAllocatePoolWithTag(NonPagedPoolExecute, user_data->payload_size, 'lmao');

    user_data->nt_memcpy(my_rwx, user_data->payload, user_data->payload_size);

    HANDLE hThread;
    user_data->nt_PsCreateSystemThread(&hThread, THREAD_ALL_ACCESS, NULL, NULL, NULL, (PKSTART_ROUTINE)my_rwx, NULL);

    user_data->nt_IofCompleteRequest(irp, 0);

    return 0;
}

इसलिए हम जल्दी से Beep को पैच करते हैं, ओवरराइट किए गए ioctl हैंडलर को कॉल करते हैं, और Beep को अनपैच करते हैं। अब हमने सुरक्षित रूप से हमारे कोड को निष्पादित करने वाला एक कर्नेल थ्रेड बनाया है, बिना सिस्टम पर कुछ और खराब किए। इस बिंदु पर हम अपने स्वयं के ड्राइवर मैप कर सकते हैं या जो कुछ भी।

निष्कर्ष

मैं एक बुरा सुरक्षा शोधकर्ता हूँ और मुझे केवल बेकार बग, दुर्घटनावश मिलते हैं। पढ़ने के लिए सभी का धन्यवाद। कृपया मेरे OnlyFans को सब्सक्राइब करें।