SmmExploit

यह CVE-2021-26943 की एक रिपोर्ट और शोषण है, जो ASUS UX360CA BIOS संस्करण 303 में कर्नेल-से-SMM स्थानीय विशेषाधिकार वृद्धि भेद्यता है। यह समस्या संस्करण 304 में ठीक की गई थी।

समस्या विवरण

सारांश

UX360CA BIOS संस्करण 303 में 3 संवेदनशील मॉड्यूल हैं जो ring0 विशेषाधिकार वाले हमलावर को SMRAM सहित लगभग किसी भी भौतिक मेमोरी को अधिलेखित करने और SMM में मनमाना कोड निष्पादित करने की अनुमति देते हैं।

उन मॉड्यूलों की पहचान इस प्रकार है:

ये मॉड्यूल AMI (BIOS विक्रेता) से हैं और अन्य OEM के BIOS में भी मौजूद हो सकते हैं।

भेद्यताएँ

संवेदनशील मॉड्यूल और संबंधित SMI हैं: UsbRt (0x31), SdioSmm (0x40), और NvmeSmm (0x42)। ये सभी SMI हैंडलर भौतिक मेमोरी पता 0x40E को पढ़ते हैं ताकि काम करने के लिए एक पता प्राप्त कर सकें और त्रुटि की स्थिति में उस पते पर एक बाइट लिखते हैं, भले ही वह SMRAM ही क्यों न हो।

उदाहरण के लिए, SdioSmm का SMI हैंडलर इस प्रकार दिखता है:

EFI_STATUS
EFIAPI
SdioSmm_SwSmi_40h(
  EFI_HANDLE  DispatchHandle,
  CONST VOID  *Context,
  VOID        *CommBuffer,
  UINTN       *CommBufferSize
  )
{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if ( EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0)))
    || userControlled->Offset0_FunctionCode >= 4 )
  {
    userControlled->Offset2 = 7;
  }
  else
  {
    // ...
  }
  return EFI_SUCCESS;
}

यह समस्या INTEL-SA-00057 के समान प्रतीत होती है, जिसका Aptiocalypsis में विस्तार से वर्णन किया गया है। हालांकि, UX360CA के लिए BIOS संस्करण 303 में उनके लिए सुधार शामिल नहीं हैं।

शोषण

यह भौतिक मेमोरी और OUT निर्देश (अर्थात, ring0 विशेषाधिकार) तक लिखने की पहुंच वाले हमलावर को निम्नलिखित चरणों के साथ SMRAM की सामग्री को अधिलेखित करने की अनुमति देता है:

1. सुनिश्चित करें कि भौतिक पता 0x40e शून्य है (जो सबसे अधिक संभावना पहले से ही है)
2. SMRAM का एक पता, मान लीजिए 0x88400000, भौतिक पता 0x104 पर लिखें
3. SMI 0x40 जारी करें
4. 0x88400000+2 को 0x7 से अपडेट किया जाता है।

इसका उपयोग SMM में मनमाना कोड निष्पादन प्राप्त करने के लिए निम्नानुसार किया जा सकता है:

1. SMRAM में सिस्टम मैनेजमेंट सर्विस टेबल (SMST) का पता खोजें, नीचे दिए गए चरणों के साथ:
   1. HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved में .Raw मान की सामग्री से UEFI रनटाइम कोड के लिए एक भौतिक मेमोरी सीमा प्राप्त करें
   2. पता सीमा से 'smmc' हस्ताक्षर स्कैन करके SMM_CORE_PRIVATE_DATA का पता खोजें
   3. SMM_CORE_PRIVATE_DATA में ऑफसेट 30h पर SMST का पॉइंटर होता है
2. उपरोक्त लेखन प्राइमिटिव का उपयोग करके SMST के ऑफसेट d0h पर SmmLocateProtocol फ़ंक्शन के पॉइंटर को अधिलेखित करें। मान 0x07070707 में अपडेट हो जाता है।
3. भौतिक मेमोरी 0x07070707 पर शेलकोड लिखें
4. एक और SMI ट्रिगर करें जो Smst->SmmLocateProtocol को कॉल करता है, जैसे SMI 0xdf। 0x07070707 पर शेलकोड SMM में निष्पादित होता है।

SMM में मनमाना कोड निष्पादन एक हमलावर को कर्नेल और हाइपरवाइजर द्वारा सुरक्षा उपायों जैसे HVCI को बायपास करने की अनुमति देगा, जैसा कि एक अन्य SMM भेद्यता रिपोर्ट में प्रदर्शित किया गया है, और SPI फ्लैश (BIOS) की सामग्री को अपडेट करके स्थायित्व स्थापित करेगा।

प्रूफ ऑफ कॉन्सेप्ट (PoC)

संलग्न डेमो प्रोजेक्ट सफल शोषण प्रदर्शित करता है और उन MSRs की सामग्री को डंप करता है जो केवल SMM और EPTP के भौतिक पते में सुलभ हैं। यह Hyper-V हाइपरवाइजर के CPUID VM-Exit हैंडलिंग कोड को भी संशोधित करता है ताकि एक परिवर्तित हाइपरवाइजर विक्रेता स्ट्रिंग लौटा सके।

PoC का परीक्षण Windows बिल्ड 18362.1256 पर, HVCI सक्षम और अक्षम दोनों के साथ किया गया है।

सफल शोषण की रिकॉर्डिंग YouTube पर उपलब्ध है।

परीक्षण निर्देश

1. Visual Studio 2019 में demo.sln खोलें
2. डीबग या रिलीज़ बिल्ड के लिए समाधान बनाएँ
3. संकलित demo.sys को लक्ष्य सिस्टम पर कॉपी करें (जैसे, C:\users\user\desktop\demo.sys)

लक्ष्य सिस्टम पर,

1. BIOS से सिक्योर बूट अक्षम करें, और रीबूट करें
2. टेस्ट साइनिंग मोड सक्षम करें, और रीबूट करें
   root@kitploit:~

   > bcdedit /set testsigning on
   

3. demo.sys को लोड करने के लिए सेवा बनाएँ
   root@kitploit:~

   > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
   

4. DebugView प्रारंभ करें और "Capture" मेनू से "Capture Kernel" सक्षम करें।
5. डेमो प्रारंभ करें
   root@kitploit:~

   > sc start demo
   

6. यदि सफल हो, तो DebugView SMM से संबंधित MSRs के मान दिखाएगा।
   root@kitploit:~

   [+] ReportSmramRange: TSEG implied SMRAM: 0x88400000 - 0x88800000
   [-] ReportSmramRange: Exception occurred while accessing SMRR MSR : c0000096
   [+] FindSystemManagementServiceTable: SMM core found at 0x87f1b390 in RT Code
   [+] FindSystemManagementServiceTable: SMST found at 0x887fa710 in SMRAM
   [+] ExploitSmm: Patched SMST->SmmLocateProtocol in SMRAM
   [+] ExploitSmm: Placed SMM shell code
   [+] ExploitSmm: Triggered SMM exploit
   [+] DumpSmmExploitOuput: IA32_SMBASE             = 0x887cd000
   [+] DumpSmmExploitOuput: MSR_SMM_FEATURE_CONTROL = 0x1
   [+] DumpSmmExploitOuput: MSR_SMM_MCA_CAP         = 0xc00000000000000
   [+] DumpSmmExploitOuput: EPT pointer             = 0x10a72001e
   [+] DumpSmmExploitOuput: Patched Hv address      = 0x1004382f0
   [+] ExploitSmm: Successfully executed shell code in SMM. Failing DriverEntry to unload itself
   DriverEntry failed 0xc0000120 for driver \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\demo
   

समाधान

समाधान उपयोगकर्ता-नियंत्रित सामग्री का पूरी तरह से उपयोग करने से बचना है जब यह SMRAM के अंदर इंगित करता है, जैसा कि नीचे दिखाया गया है।

{
  // ...
  struct_v0 *userControlled = *(0x10 * MEMORY[0x40E] + 0x104);
  if (!EFI_ERROR(ValidateBufferIsOutsideSmram(userControlled, sizeof(struct_v0))))
  {
    if (userControlled->Offset0_FunctionCode < 7 )
    {
      // ...
    }
    else
    {
      userControlled->Offset2 = 7;
    }
  }
  return EFI_SUCCESS;
}

विचार

हाइपरवाइजर के लिए सुरक्षा का अभाव

समाधान वर्तमान उद्योग की सर्वोत्तम प्रथाओं का पूरी तरह से पालन करता है और भ्रमित डिप्टी हमले को रोकता है जो SMRAM भ्रष्टाचार की ओर ले जाता है।

हालांकि, ध्यान दें कि यह हाइपरवाइजर मेमोरी क्षेत्रों को ध्यान में नहीं रखता है। भौतिक मेमोरी पते के ज्ञान वाला हमलावर जहां हाइपरवाइजर लोड या उपयोग किया जाता है, फिर भी हाइपरवाइजर कोड या डेटा को अधिलेखित करने और हाइपरवाइजर भ्रष्टाचार प्राप्त करने के लिए SMI का अनुरोध कर सकता है।

यह एक व्यापक, लंबे समय से विद्यमान और यहां तक कि डिज़ाइन-स्तरीय समस्या है।

गहराई में सुरक्षा का अभाव

रिपोर्ट की गई समस्याओं को हल किया गया था, लेकिन गहराई में सुरक्षा रणनीति का प्रयोग करने के मामले में कुछ समस्याएं थीं।

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

मेरा मानना है कि ये OEM और कई BIOS संस्करणों में सामान्य समस्याएं हैं। मैं चेतावनी देता हूं कि यदि आप किसी भी OEM के पुराने मॉडल पर हैं, तो वह BIOS उतना सुरक्षित होने की संभावना नहीं है जितना आप उनके नवीनतम BIOS संस्करणों के साथ भी चाह सकते हैं।

सुधार

ये समस्याएं जल्द ही दूर नहीं होंगी, लेकिन मैं यह देखकर उत्साहित हूं कि उद्योग SMM विशेषाधिकारों को कम करके एक आर्किटेक्चरल समाधान पर काम कर रहा है। यहां कुछ कार्य और लेख हैं जिन्हें आप देख सकते हैं:

• प्लेटफॉर्म रनटाइम मैकेनिज्म (PRM)
  • प्रस्तुति (Open-Source Firmware Conference 2020)
  • विनिर्देश (uefi.org)
  • कार्यान्वयन (edk2-staging)
• सिस्टम मैनेजमेंट मोड डीप डाइव: SMM आइसोलेशन प्लेटफॉर्म को कैसे मजबूत करता है
• सिस्टम गार्ड के लिए सिस्टम आवश्यकताएँ

समयरेखा

यहां कुछ मुख्य बिंदु हैं।

• 2020-12-31 - मैंने भेद्यता की रिपोर्ट की
• 2021-01-05 - ASUS ने रिपोर्ट स्वीकार की
• 2021-01-18 - ASUS ने मुझे परीक्षण के लिए BIOS का निश्चित संस्करण भेजा
• 2021-01-20 - मैंने समाधान की पुष्टि की और वापस उत्तर दिया
• 2021-01-25 - ASUS ने मेरे उत्तर को स्वीकार किया
• 2021-03-21 - ASUS ने समाधान सार्वजनिक किया, संस्करण 304
• 2021-03-29 - ASUS ने CVE-2021-26943 के लिए एक सलाहकार प्रविष्टि जारी की

अंत में, ASUS टीमों को संचार लूप को करीब और पारदर्शी रखने के लिए बड़ा धन्यवाद❤ कुल प्रक्रिया तेज नहीं थी, लेकिन निराशा मुक्त थी।