بارگیری بوت‌کیت‌های مخرب توسط مهاجمان به دلیل آسیب‌پذیری جدید بوت امن UEFI

بنابراین، مهاجمی که CVE-2024-7344 را مسلح می‌کند، می‌تواند حفاظت‌های Secure Boot را کنار بگذارد و کدهای بدون امضا را در طول فرآیند بوت درزمینه UEFI حتی قبل از بارگیری سیستم‌عامل اجرا کند و به آن‌ها دسترسی پنهان و دائمی به میزبان بدهد.

مرکز هماهنگی CERT (CERT/CC) گفت[۷]: “کد اجراشده در مرحله اولیه راه‌اندازی می‌تواند روی سیستم باقی بماند و به‌طور بالقوه برنامه‌های افزودنی هسته مخربی را بارگیری کند که هم از راه‌اندازی مجدد و هم نصب مجدد سیستم‌عامل زنده می‌مانند. علاوه بر این، ممکن است از تشخیص توسط اقدامات امنیتی مبتنی بر سیستم‌عامل و تشخیص و پاسخ نقطه پایانی (EDR) جلوگیری کند.”

عوامل مخرب می‌توانند با آوردن کپی خود از باینری آسیب‌پذیر “reloader.efi” به هر سیستم UEFI که گواهی UEFI شخص ثالث مایکروسافت را ثبت کرده باشد، دامنه بهره‌برداری را بیشتر گسترش دهند. بااین‌حال، برای استقرار فایل‌های آسیب‌پذیر و مخرب در پارتیشن سیستم EFI، به امتیازات بالایی نیاز است: مدیر محلی در ویندوز و روت در لینوکس.

شرکت امنیت سایبری اسلواکی اعلام کرد که در ژوئن ۲۰۲۴ این یافته‌ها را به‌طور مسئولانه به CERT/CC فاش کرده است و پس‌ازآن شرکت Howyar Technologies و شرکای آن به این موضوع در محصولات مربوطه رسیدگی کردند. در ۱۴ ژانویه ۲۰۲۵، مایکروسافت باینری‌های قدیمی و آسیب‌پذیر را به‌عنوان بخشی از به‌روزرسانی Patch Tuesday خود لغو کرد[۸].

خارج از اعمال لغو UEFI، مدیریت دسترسی به فایل‌های واقع در پارتیشن سیستم EFI، سفارشی‌سازی Secure [9]Boot و تأیید از راه دور[۱۰] با ماژول پلتفرم مورد اعتماد (TPM)[11] از دیگر راه‌های محافظت در برابر بهره‌برداری از بوت‌لودرهای ناشناخته آسیب‌پذیر امضاشده UEFI و استقرار بوت‌کیت‌های UEFI هستند.

اسمولار می‌گوید: «تعداد آسیب‌پذیری‌های UEFI کشف‌شده در سال‌های اخیر و شکست‌ها در اصلاح آن‌ها یا باطل کردن باینری‌های آسیب‌پذیر در یک بازه زمانی معقول نشان می‌دهد که حتی یک ویژگی ضروری مانندUEFI Secure Boot نباید به‌عنوان یک مانع غیرقابل نفوذ در نظر گرفته شود».

“بااین‌حال، آنچه ما را در مورد آسیب‌پذیری بیش از همه نگران می‌کند، زمان صرف شده برای تعمیر و لغو باینری نیست، که در مقایسه با موارد مشابه بسیار خوب بود، اما این اولین بار نیست که چنین باینری امضاشده UEFI آشکارا ناامن کشف می‌شود. این پرسش‌هایی را مطرح می‌کند که استفاده از چنین تکنیک‌های ناامنی در میان فروشندگان نرم‌افزار UEFI شخص ثالث تا چه اندازه رایج است، و چه تعداد بوت‌لودر مبهم، اما امضاشده مشابه دیگر ممکن است وجود داشته باشد.”

منابع

[۱] https://www.welivesecurity.com/en/eset-research/under-cloak-uefi-secure-boot-introducing-cve-2024-7344

[۲] https://msrc.microsoft.com/update-guide/en-US/advisory/CVE-2024-7344

[۳] https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/trusted-boot

[۴] https://access.redhat.com/articles/5254641

[۵] https://uefi.org/specs/UEFI/2.9_A/07_Services_Boot_Services.html#efi-boot-services-loadimage

[۶] https://uefi.org/specs/UEFI/2.9_A/07_Services_Boot_Services.html#efi-boot-services-startimage

[۷] https://kb.cert.org/vuls/id/529659

[۸] https://apa.aut.ac.ir/?p=10928

[۹] https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-Secure-Boot-Customization-UOO168873-20.PDF

[۱۰] https://community.infineon.com/t5/Blogs/TPM-remote-attestation-How-can-I-trust-you/ba-p/452729#.

[۱۱] https://en.wikipedia.org/wiki/Trusted_Platform_Module

[۱۲] https://thehackernews.com/2025/01/new-uefi-secure-boot-vulnerability.html

[author title=”نویسنده” image=”https://soroosheamniyat.ir/wp-content/uploads/2025/01/bajalan.jpg”]سعید باجلان کارشناس ارشد نرم افزار وصاحب امتیاز پایگاه خبری سروش امنیت[/author]

منبع :
مرکز آپاي دانشگاه صنعتي امير کبير

پویش #دو_درجه_کمتر