Вразливості подвоєного безпечного завантаження та часткове виправлення від Microsoft
Огляд
У червні 2025 року дослідники виявили два окремі експлойти Secure Boot, які активно використовуються і повністю обходять захисти UEFI. Secure Boot, що є основою сучасної безпеки прошивки, використовує ланцюг довіри для забезпечення виконання тільки криптографічно підписаного коду під час ініціалізації системи. Хоча Microsoft випустила патч для CVE-2025-3052, друга вразливість, CVE-2025-47827, досі не усунена, залишаючи відкритим шлях для атак.
Експлойт 1 CVE-2025-3052 Зловживання модулем DT Research
CVE-2025-3052 націлений на утиліту прошивки, розроблену компанією DT Research, призначену для міцних польових пристроїв. Дослідники з Binarly виявили, що цей модуль підписаний сертифікатом UEFI CA 2011 від Microsoft Corporation і постачається попередньо довіреним на понад 50 платформах виробників. Під час етапу завантаження UEFI модуль RT_FlashTool виконується безумовно, якщо він присутній у системному розділі EFI. Зловмисник, маючи фізичний або адміністративний доступ, може викликати цей інструмент, щоб вимкнути Secure Boot в NVRAM, а потім встановити шкідливий UEFI драйвер, який запускається до завантажувача ОС.
Ця вразливість стала відомою через VirusTotal у 2024 році та була цифрово підписана у 2022 році, що свідчить про її широке поширення. Оновлення Microsoft у червні додало криптографічні хеші для 14 варіантів інструмента до списку відкликання DBX, що запобігає завантаженню шиму. Red Hat, SUSE та інші постачальники Linux випустили паралельні патчі, оновлюючи списки блокування шиму на корпоративних ядрах.
Binarly оцінили цю вразливість на 8.2 з 10, на відміну від більш обережної оцінки Microsoft у 3.1. Алекс Матросов, генеральний директор Binarly, попереджає, що помилка одного постачальника може спричинити наслідки для всього ланцюга постачання UEFI, і закликає до постійного сканування бінарних файлів з оперативним впровадженням DBX замість річних оновлень BIOS.
Експлойт 2 CVE-2025-47827 Обхід драйвера IGEL Flash
Другий експлойт зосереджується на igel-flash-driver, модулі ядра Linux, що використовується тонкими клієнтами IGEL OS. Підписаний тим же сертифікатом UEFI CA від Microsoft, він не здатний належним чином перевіряти підписи образів прошивки. Дослідник Зак Дідкотт продемонстрував, як зловмисник з короткочасним фізичним доступом може завантажитися в режим відновлення IGEL, використати дефектний модуль для перезапису завантажувача та завантажити непідписані ядра або шкідливий initramfs.
Аналітики Eclypsium підкреслюють, що будь-яка система, яка довіряє Microsoft Third Party UEFI CA, є вразливою, поки підпис не буде відкликано. Джессі Майкл з Eclypsium зазначає, що вбудований ключ шиму затверджує скомпрометований rootfs, що дозволяє зловмисникам залишатися непоміченими. На сьогоднішній день Microsoft не оголосила про плани додати модуль IGEL до DBX і не відповіла на запити.
Вплив на безпеку підприємств
Ці експлойти підкреслюють системні ризики у ланцюзі довіри прошивки. Підприємства, які покладаються на сертифіковані тонкі клієнти або міцні мобільні пристрої, можуть не усвідомлювати, що довірені сертифікати поширюються на всі модулі UEFI. Урядові програми відповідності, такі як у сфері оборони та охорони здоров’я, вимагають використання Secure Boot, але часто не мають детального моніторингу відкликань сертифікатів.
Сценарії “злої домогосподарки” є особливо небезпечними у високовартісних середовищах. Як тільки Secure Boot вимкнено або обійдено, зловмисники отримують раннє виконання коду, уникаючи захисту на рівні ОС. У хмарних дата-центрах скомпрометовані управлінські вузли можуть розгортати атаки прошивки на десятки серверів.
Стратегії пом’якшення та найкращі практики
- Підтримуйте суворий контроль над процесом оновлення UEFI db та DBX за допомогою MDM або інструментів управління BIOS
- Впроваджуйте контрольовану атестацію на основі TPM для виявлення несанкціонованих змін прошивки
- Використовуйте токени апаратної довіри для обмеження доступу до змінних Secure Boot у NVRAM
- Проводьте періодичне сканування бінарних образів прошивки та перевірку цілісності в рамках CI/CD процесів
- Обмежте фізичний доступ до критичних систем і запровадьте системи виявлення вторгнень у шасі
Перспективи та рекомендації для галузі
Експерти з безпеки виступають за детальні механізми відкликання, які виходять за межі повного чорного списку сертифікатів. Пропозиції, що обговорюються в Linux Foundation, включають підписаний список матеріалів прошивки (SBOM) та автоматизовані журнали прозорості підписів шиму. Проект рекомендацій NIST щодо прошивки UEFI також пропонує вбудовувати метадані про відкликання в бази даних KEK для реального блокування.
Думки експертів
Вкрай важливо перейти від випадкових річних оновлень до безперервної гігієни безпеки прошивки, говорить Сандра Рівера, технічний директор великого постачальника хмарних послуг. Наявність автоматизованого процесу для перевірки кожного бінарного файлу UEFI може суттєво зменшити вікно уразливості перед новими загрозами.
Висновок
Хоча патч Microsoft для CVE-2025-3052 закриває один вектор атаки, CVE-2025-47827 залишається серйозною загрозою. Організаціям необхідно впроваджувати суворі процеси управління прошивкою, моніторити канали відкликань і забезпечувати апаратну атестацію для збереження цілісності ланцюга Secure Boot.