CERT/CC опублікував вразливість VU#718077, яка описує спосіб обходу UEFI Secure Boot через оболонку UEFI Shell, вбудовану в SPI-флеш-пам’ять платформи. Зловмисник, який здатен створювати додаткові завантажувальні записи UEFI, може запустити UEFI Shell навіть за увімкненого Secure Boot і використати її команди прямого доступу до пам’яті для модифікації передзавантажувального середовища та виконання довільного коду до старту операційної системи. Проблема зачіпає продукти кількох вендорів — Cisco, AMI (GIGABYTE) та Insyde — і потребує оновлення прошивки від конкретного виробника платформи.
Суть вразливості та механізм атаки
UEFI Shell — командна оболонка, що входить до специфікації UEFI й реалізована в проєкті TianoCore EDK II. Багато OEM-виробників і незалежних постачальників BIOS (IBV) вбудовують UEFI Shell до SPI-флеш-пам’яті для сервісних та діагностичних цілей. Оболонка надає команди dmem (читання пам’яті) та mm (модифікація пам’яті), які дають прямий доступ до фізичної пам’яті системи на етапі до завантаження ОС.
Стандартний захист передбачає видалення або придушення завантажувального запису UEFI Shell за активного Secure Boot. Втім, дослідник Стас Ляхов з Eclypsium виявив, що зловмисник, який має можливість створювати додаткові завантажувальні записи UEFI, може обійти цей контроль, створивши надлишкові записи, що посилаються на вбудовану оболонку. Після запуску UEFI Shell зловмисник може використати її скриптові можливості (автозавантажувальні скрипти) та команди модифікації пам’яті для перезапису значень, пов’язаних із Secure Boot, і виконання неавторизованого коду.
Зачеплені продукти та CVE
Вразливість охоплює кілька вендорських реалізацій, кожна з яких отримала окремий ідентифікатор CVE. Це не єдина універсальна проблема, а набір конфігураційно-залежних вразливостей:
- CVE-2026-20293 — за даними CERT/CC, зачіпає сервери Cisco UCS і пристрої на базі UCS. Cisco опублікувала окремий бюлетень безпеки. Раніше ми вже писали про вразливості у продуктах Cisco.
- CVE-2026-33197 — згідно із заявою GIGABYTE через CERT/CC, пов’язана з логічною помилкою в модулі AMI Aptio UEFI BDS. Помилка в процесі видалення завантажувального запису Shell дає змогу створювати дублювальні записи, обходячи перевірку Secure Boot і отримуючи доступ до довільного читання та запису фізичної пам’яті.
- CVE-2026-6485 — за заявою Insyde, більшість систем з Insyde BIOS не зачеплені. Уразливі лише ті конфігурації, у яких UEFI Shell увімкнена в областях системного коду, дозволених для виконання за активного Secure Boot. Insyde оцінює цю вразливість у 8.2 за CVSS. Ця оцінка стосується виключно CVE-2026-6485 і не має поширюватися на інші CVE чи на зонтичний бюлетень VU#718077.
Ключова умова експлуатації: UEFI Shell має фізично бути присутньою в прошивці або в дозволеній до виконання області системного коду, а зловмисник має мати можливість модифікувати завантажувальні записи UEFI. Саме по собі ввімкнення Secure Boot не є достатнім захистом, якщо ці умови виконані.
Наслідки експлуатації
Код, що виконується на передзавантажувальному етапі, діє до ініціалізації операційної системи та її захисних механізмів. Згідно з CERT/CC, успішна експлуатація може призвести до:
- Завантаження зловмисних компонентів на рівні ядра, які переживають перезавантаження і в низці випадків — перевстановлення ОС
- Зниження ефективності засобів захисту на рівні ОС, включно з рішеннями класу EDR
- Встановлення постійного доступу до системи через модифікацію передзавантажувального середовища
Факт активної експлуатації VU#718077 у реальних атаках на момент публікації не підтверджений жодним із розглянутих джерел.
Рекомендації щодо захисту
Усунення вразливості потребує оновлення прошивки UEFI від конкретного виробника платформи. Це не стандартне оновлення ОС — процес може вимагати OEM-специфічних інструментів та окремих процедур розгортання. CERT/CC рекомендує:
- Застосувати оновлення прошивки від вендора платформи, дотримуючись його інструкцій щодо розгортання
- Провести інвентаризацію — визначити, чи присутня UEFI Shell у прошивці ваших систем. Наявність вбудованої оболонки — необхідна умова експлуатації
- Налаштувати моніторинг завантажувальних записів UEFI — відстежувати та аудіювати зміни в конфігурації завантаження, де це технічно можливо
- Переглянути політики Secure Boot — переконатися, що конфігурація платформи не допускає несанкціонованого створення завантажувальних записів
Увімкнений індикатор Secure Boot сам по собі не гарантує захисту від цієї вразливості. Пріоритет слід надати перевірці наявності UEFI Shell у прошивці та контролю над завантажувальними записами. Організації, які використовують сервери Cisco UCS, платформи на базі AMI Aptio або системи з Insyde BIOS, мають звернутися до відповідних вендорів по оновлення прошивки та інтегрувати їх у наявні процеси управління життєвим циклом firmware.
