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

جزئیاتی در مورد یک آسیب‌پذیری امنیتی اصلاح‌شده که می‌تواند امکان دور زدن مکانیسم Secure Boot در سیستم‌های Unified Extensible Firmware Interface (UEFI) را فراهم کند، ظاهر شده است.

طبق گزارش جدیدی از ESET که با The Hacker News به اشتراک گذاشته شده است[۱]، این آسیب‌پذیری که شناسه CVE CVE-2024-7344 (امتیاز ۶٫۷ در CVSS) به آن اختصاص داده شده است[۲]، در یک برنامه UEFI با امضای گواهی UEFI شخص ثالث Microsoft “Microsoft Corporation UEFI CA 2011 قرار دارد.

بهره‌برداری موفقیت‌آمیز از این نقص می‌تواند منجر به اجرای کدهای نامعتبر در هنگام بوت شدن سیستم شود، درنتیجه مهاجمان را قادر می‌سازد تا بوت‌کیت‌های مخرب UEFI را بدون در نظر گرفتن سیستم‌عامل نصب‌شده، روی ماشین‌هایی که Secure Boot روشن دارند، مستقر کنند.

Secure Boot یک استاندارد امنیتی firmware است[۳] که با اطمینان از اینکه دستگاه فقط با استفاده از نرم‌افزار مورد اعتماد سازنده تجهیزات اصلی (OEM) بوت می‌شود، از بارگیری بدافزار هنگام راه‌اندازی رایانه جلوگیری می‌کند. این ویژگی از امضاهای دیجیتالی برای تأیید صحت، منبع و یکپارچگی کدی که بارگذاری شده است استفاده می‌کند[۴].

برنامه UEFI آسیب‌دیده بخشی از چندین مجموعه نرم‌افزار بازیابی سیستم در زمان واقعی است که توسط Howyar Technologies Inc.، Greenware Technologies، Radix Technologies Ltd.، SANFONG Inc.، Wasay Software Technology Inc.، Computer Education System Inc.، و Signal Computer GmbH توسعه یافته‌اند.

Howyar SysReturn قبل از نسخه ۱۰٫۲٫۰۲۳-۲۰۲۴۰۹۱۹
Greenware GreenGuard قبل از نسخه ۱۰٫۲٫۰۲۳-۲۰۲۴۰۹۲۷
Radix SmartRecovery قبل از نسخه ۱۱٫۲٫۰۲۳-۲۰۲۴۰۹۲۷
Sanfong EZ-back System قبل از نسخه ۱۰٫۳٫۰۲۴-۲۰۲۴۱۱۲۷
WASAY eRecoveryRX قبل از نسخه ۸٫۴٫۰۲۲-۲۰۲۴۱۱۲۷
CES NeoImpact قبل از نسخه ۱۰٫۱٫۰۲۴-۲۰۲۴۱۱۲۷
SignalComputer HDD King قبل از نسخه ۱۰٫۳٫۰۲۱-۲۰۲۴۱۱۲۷

مارتین اسمولار، محقق ESET، گفت: «این آسیب‌پذیری به دلیل استفاده از یک PE loader سفارشی به‌جای استفاده از توابع استاندارد و ایمن UEFI یعنی [۵]LoadImage و [۶]StartImage ایجاد می‌شود. درنتیجه، برنامه اجازه می‌دهد تا هر باینری UEFI – حتی بدون علامت – را از یک فایل ساخته‌شده خاص به نام cloak.dat، در هنگام شروع سیستم، بدون در نظر گرفتن وضعیت راه‌اندازی ایمن 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