Стаття розповідає про перший відомий випадок UEFI bootkit, який здатен обійти захист UEFI Secure Boot. Дослідники з ESET вперше опублікували аналіз цього bootkit, здатного працювати навіть на останніх повністю оновлених системах Windows 11 з увімкненим UEFI Secure Boot. BlackLotus, який продавався на хакерських форумах за $5,000 з жовтня 2022 року, є потужною загрозою, оскільки він має повний контроль над процесом завантаження ОС, може вимкнути різні механізми безпеки ОС і розгортати свої власні навантаження на ранніх етапах запуску ОС. Це дозволяє йому діяти дуже приховано і з високими привілеями.
Дисклеймер: Ця стаття створена з ознайомлювальною метою. У ній описано принцип роботи UEFI bootkit BlackLotus, щоб показати, як подібні загрози можуть обходити захист Secure Boot, і допомогти зрозуміти, як ефективніше захищатися від таких атак.
Кількість уразливостей UEFI, виявлених за останні роки, і збої в їх виправленні або відкликанні вразливих двійкових файлів протягом розумного періоду часу не залишилися непоміченими суб’єктами загроз. У результаті перший загальновідомий буткіт UEFI, який обходить важливу функцію безпеки платформи – UEFI Secure Boot – став реальністю. У цій публікації в блозі ми представляємо перший публічний аналіз цього буткіта UEFI, який може працювати навіть на повністю оновлених системах Windows 11 із увімкненим безпечним завантаженням UEFI. Функціональність буткіта та його окремі функції змушують нас вважати, що ми маємо справу з буткітом, відомим як BlackLotus, буткіт UEFI, який продається на хакерських форумах за 5000 доларів США принаймні з жовтня 2022 року.
Буткіти UEFI — це дуже потужні загрози, які мають повний контроль над процесом завантаження ОС і, таким чином, здатні відключати різні механізми безпеки ОС і розгортати власні корисні навантаження в режимі ядра або режимі користувача на ранніх етапах запуску ОС. Це дозволяє їм працювати дуже непомітно та з високими привілеями. Наразі лише деякі з них були виявлені в природі та публічно описані (наприклад, численні шкідливі зразки EFI, які ми виявили у 2020 році, або повнофункціональні буткіти UEFI, такі як наше відкриття минулого року – буткіт ESPecter – або буткіт FinSpy, виявлений дослідниками від Касперського).
Буткіти UEFI можуть втратити прихованість порівняно з імплантатами мікропрограми, такими як LoJax; перший імплантат прошивки UEFI у дикій природі, виявлений нашою командою в 2018 році, оскільки буткіти розташовані на легкодоступному розділі диска FAT32. Однак запуск у якості завантажувача надає їм майже ті ж можливості, що й імплантати вбудованого програмного забезпечення, але без необхідності долати багаторівневий захист флеш-пам’яті SPI, наприклад біти захисту BWE, BLE та PRx, або захист, наданий апаратним забезпеченням (наприклад, Intel Boot Guard). ). Безумовно, UEFI Secure Boot стоїть на заваді буткітам UEFI, але є незначна кількість відомих уразливостей, які дозволяють обійти цей важливий механізм безпеки. І найгірше те, що деякі з них все ще легко використовувати в оновлених системах навіть на момент написання цієї статті, включаючи той, який використовує BlackLotus.
Наше розслідування почалося з кількох звернень до того, що виявилося компонентом режиму користувача BlackLotus – HTTP-завантажувачем – у нашій телеметрії наприкінці 2022 року. Після початкової оцінки шаблони коду, знайдені у зразках, привели нас до відкриття шести BlackLotus інсталятори (як на VirusTotal, так і в нашій власній телеметрії). Це дозволило нам дослідити весь ланцюжок виконання та зрозуміти, що ми маємо справу не звичайним шкідливим програмним забезпеченням.
Нижче наведено ключові моменти про BlackLotus і хронологію серії подій, пов’язаних з ним:
Він здатний працювати на останніх, повністю виправлених системах Windows 11 з увімкненим UEFI Secure Boot.
Він використовує вразливість понад рік тому (CVE-2022-21894), щоб обійти UEFI Secure Boot і налаштувати постійність для буткіта. Це перше публічно відоме зловживання цією вразливістю в дикій природі.
Незважаючи на те, що вразливість було виправлено в оновленні Microsoft від січня 2022 року, її використання все ще можливе, оскільки уражені правильно підписані двійкові файли ще не додано до списку відкликаних UEFI. BlackLotus користується цим, доставляючи власні копії легітимних, але вразливих, двійкових файлів у систему, щоб використовувати вразливість.
Він здатний відключати механізми безпеки ОС, такі як BitLocker, HVCI та Windows Defender.
Після встановлення основною метою буткіта є розгортання драйвера ядра (який, серед іншого, захищає буткіт від видалення) і HTTP-завантажувача, відповідального за зв’язок із C&C і здатного завантажувати додаткові корисні навантаження в режимі користувача або режимі ядра. .
BlackLotus рекламується та продається на підпільних форумах принаймні з 6 жовтня 2022 року. У цій публікації в блозі ми надаємо докази того, що буткіт справжній, а реклама не є просто шахрайством.
Цікаво, що деякі інсталятори BlackLotus, які ми проаналізували, не продовжують встановлення буткіта, якщо скомпрометований хост використовує одну з таких локалей:
Romanian (Moldova), ro-MD
Russian (Moldova), ru-MD
Russian (Russia), ru-RU
Ukrainian (Ukraine) , uk-UA
Belarusian (Belarus), be-BY
Armenian (Armenia), hy-AM
Kazakh (Kazakhstan), kk-KZ
Хронологія окремих подій, пов’язаних із BlackLotus, показана на малюнку 1.
Як уже зазначалося, буткіт продається на підпільних форумах принаймні з 6 жовтня 2022 року. На даний момент ми не можемо визначити за нашими телеметричними даними точний канал розповсюдження, використаний для розгортання буткіта жертвам. Невелика кількість зразків BlackLotus, які ми змогли отримати як із загальнодоступних джерел, так і з нашої телеметрії, змушує нас вважати, що ще не так багато загрозників почали використовувати його. Але поки не відбудеться відкликання вразливих завантажувачів, від яких залежить BlackLotus, ми стурбовані тим, що ситуація швидко зміниться, якщо цей буткіт потрапить до рук відомих груп злочинного програмного забезпечення, ґрунтуючись на легкому розгортанні буткіта та можливостях груп злочинного програмного забезпечення для поширення зловмисне програмне забезпечення, що використовує їхні ботнети.
Є кілька статей або дописів, у яких підсумовується інформація про BlackLotus ( тут, тут і тут і багато іншого…), усі вони базуються на інформації, наданій розробником буткіта на підпільних хакерських форумах. Поки що ніхто не підтвердив і не спростував ці заяви.
Ось наш короткий виклад тверджень із доступних публікацій у порівнянні з тим, що ми виявили під час зворотного проектування зразків буткітів:
У рекламі BlackLotus на хакерських форумах стверджується, що він має вбудований обхід безпечного завантаження . Додавання вразливих драйверів до списку відкликаних UEFI наразі неможливо, оскільки вразливість впливає на сотні завантажувачів, які використовуються досі. ✅
Правда: він використовує CVE-2022-21894, щоб зламати Secure Boot і досягти стійкості в системах із підтримкою UEFI-Secure-Boot. Уразливі драйвери, які він використовує, все ще не скасовані в останній версії dbx на момент написання.
Реклама BlackLotus на хакерських форумах стверджує, що буткіт має вбудований захист Ring0/Kernel від видалення. ✅
Правда: його драйвер ядра захищає дескриптори, що належать його файлам у системному розділі EFI (ESP), від закриття. Як додатковий рівень захисту, ці дескриптори постійно відстежуються та запускається синій екран смерті (BSOD), якщо будь-який із цих дескрипторів закрито, як описано в розділі «Захист файлів завантажувального пакету на ESP від видалення ».
У рекламі BlackLotus на хакерських форумах стверджується, що він оснащений функціями захисту від віртуальної машини (анти-ВМ), захисту від налагодження та функції обфускації коду для блокування спроб аналізу зловмисного програмного забезпечення. ✅
Правда: він містить різні методи захисту від віртуальної машини, захисту від налагодження та обфускації, щоб ускладнити копіювання чи аналіз. Однак ми точно не говоримо про будь-які проривні чи передові методи антианалізу, оскільки їх можна легко подолати з невеликими зусиллями.
У рекламі BlackLotus на хакерських форумах стверджується, що його призначення — діяти як завантажувач HTTP. ✅
Правда: його останній компонент діє як завантажувач HTTP, як описано в розділі про завантажувач HTTP
У рекламі BlackLotus на хакерських форумах стверджується, що HTTP-завантажувач працює під обліковим записом SYSTEM у законному процесі. ✅
Правда: його HTTP-завантажувач працює в контексті процесу winlogon.exe .
У рекламі BlackLotus на хакерських форумах стверджується, що це крихітний буткіт із розміром на диску лише 80 Кб. ✅
Правда: Зразки, які нам вдалося отримати, справді становлять близько 80 КБ.
У рекламі BlackLotus на хакерських форумах стверджується, що він може вимкнути вбудовані засоби захисту Windows, такі як HVCI, Bitlocker, Windows Defender, і обійти контроль облікових записів користувачів (UAC). ✅
Правда: він може вимкнути HVCI , Windows Defender, BitLocker і обійти UAC .
Базуючись на цих фактах, ми з високою впевненістю вважаємо, що буткіт, який ми виявили в дикій природі, є буткітом BlackLotus UEFI.
Спрощена схема компромісного ланцюга BlackLotus показана на малюнку 2. Вона складається з трьох основних частин:
Він починається із виконання інсталятора (крок 1 на малюнку 2), який відповідає за розгортання файлів завантажувального пакета в системний розділ EFI, відключення HVCI та BitLocker, а потім перезавантаження машини.
Після першого перезавантаження відбувається використання CVE-2022-21894 і подальша реєстрація ключа власника машини (MOK) зловмисників, щоб досягти стійкості навіть у системах з увімкненим UEFI Secure Boot. Після цього комп’ютер знову перезавантажується (кроки 2–4 на малюнку 2).
Під час усіх наступних завантажень самопідписаний буткіт UEFI виконується та розгортає як драйвер ядра, так і корисне навантаження режиму користувача, завантажувач HTTP. Разом ці компоненти можуть завантажувати та виконувати додаткові компоненти режиму користувача та драйвера з C&C сервера та захищати буткіт від видалення (кроки 5–9 на малюнку 2).
Незважаючи на те, що ми вважаємо, що це буткіт BlackLotus UEFI, ми не знайшли жодного посилання на це ім’я в проаналізованих зразках. Натомість код повний посилань на аніме-серіал Higurashi When They Cry, наприклад, у назвах окремих компонентів, таких як higurashi_installer_uac_module.dll і higurashi_kernel.sys , а також у самопідписаному сертифікаті, який використовується для підпису двійкового файлу буткіта (показано на малюнку 3).
Крім того, код розшифровує, але ніколи не використовує різні рядки, що містять повідомлення від автора BlackLotus (як показано на малюнку 4 – зауважте, що Хашерезада є відомим дослідником і автором різноманітних інструментів аналізу зловмисного програмного забезпечення), або просто деякі випадкові цитати з різних пісні, ігри чи серіали.
Почнемо з аналізу інсталяторів BlackLotus. Схоже, що буткіт поширюється у формі інсталяторів, які доступні в двох версіях – офлайн і онлайн. Різниця між ними полягає в тому, як вони отримують законні (але вразливі) двійкові файли Windows, які пізніше використовуються для обходу безпечного завантаження.
В офлайн-версіях двійкові файли Windows вбудовані в інсталятор
В онлайн-версіях двійкові файли Windows завантажуються безпосередньо з магазину символів Microsoft. Наразі ми спостерігали такі двійкові файли Windows, які зловживали завантажувальним пакетом BlackLotus:
https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi
Мета інсталятора зрозуміла – він відповідає за вимикання функцій безпеки Windows, таких як шифрування диска BitLocker і HVCI, а також за розгортання кількох файлів, у тому числі шкідливого завантажувального пакета, до ESP. Після завершення він перезавантажує скомпрометовану машину, щоб дозволити видаленим файлам виконувати свою роботу – щоб переконатися, що самопідписаний завантажувальний пакет UEFI буде тихо виконуватися під час кожного запуску системи, незалежно від статусу захисту UEFI Secure Boot.
Коли інсталятор виконується, він перевіряє, чи має він достатньо привілеїв (потрібно принаймні права адміністратора) для розгортання решти файлів у ESP та виконання інших дій, які вимагають процесу з підвищеними правами, наприклад вимкнення HVCI або BitLocker. Якщо це не так, він намагається підвищити рівень, повторно запустивши програму встановлення за допомогою методу обходу UAC, детально описаного тут: Обхід UAC через помічника сумісності програм.
З необхідними привілеями він продовжує, перевіряючи стан безпечного завантаження UEFI, зчитуючи значення змінної SecureBoot UEFI за допомогою доступної функції Windows API, і визначаючи версію Windows, безпосередньо звертаючись до полів структури KUSER_SHARED_DATA NtMajorVersion і NtMinorVersion у пам’яті. Це робиться для того, щоб вирішити, чи потрібен обхід безпечного завантаження UEFI для розгортання буткіта в системі жертви (оскільки підтримка безпечного завантаження була вперше додана в Windows 8 і може бути не ввімкнена на жодній машині).
Перш ніж перейти до наступних кроків, він перейменовує законний двійковий файл Windows Boot Manager ( bootmgfw.efi ), розташований у каталозі ESP:\EFI\Microsoft\Boot\ на winload.efi . Цю перейменовану резервну копію bootmgfw.efi пізніше використовує bootkit для запуску ОС або для відновлення оригінального ланцюжка завантаження, якщо команду «видалити» отримано від C&C-сервера – докладніше в розділі зв’язку C&C .
Якщо UEFI Secure Boot увімкнено, інсталятор продовжує переміщення кількох файлів у каталоги ESP:/EFI/Microsoft/Boot/ і ESP:/system32/ . У той час як перший є стандартним каталогом, який використовується Windows, другий є спеціальною папкою, створеною інсталятором.
Список файлів, видалених інсталятором, із коротким поясненням ролі кожного файлу в ланцюжку виконання наведено в таблиці 1. Ми пояснимо докладно, як працює ланцюжок виконання пізніше; тепер лише зауважте, що кілька легітимних файлів, підписаних Microsoft, видаляються разом із шкідливими.
Файли, розгорнуті інсталятором BlackLotus у системах із увімкненим UEFI Secure Boot
ESP:\EFI\Microsoft\Bootgrubx64.efi — Буткіт BlackLotus, зловмисна самопідписана програма UEFI.
bootload.efi — Законний файл shim, підписаний Microsoft, замінює
bootmgfw.efiпісля використання CVE-2022-21894.
bootmgfw.efi — Вразливий файл завантажувача Windows (
CVE-2022-21894).
BCD — Спеціальне сховище зловмисників для CVE-2022-21894.
BCDR — Резервне копіювання оригінального BCD жертви.
ESP:\system32hvloader.efi — Вразливий файл завантажувача Windows Hypervisor (
CVE-2022-21894).
bootmgr.efi — Вразливий файл диспетчера завантаження Windows (
CVE-2022-21894).
mcupdate_AuthenticAMD.dll — Шкідливий файл для CVE-2022-21894 (AMD).
mcupdate_GenuineIntel.dll — Шкідливий файл для CVE-2022-21894 (Intel).
BCD — Спеціальний BCD зловмисників для CVE-2022-21894.
У випадках, коли жертва використовує версію Windows, яка не підтримує UEFI Secure Boot, або якщо вона вимкнена, розгортання є досить простим. Єдине, що потрібно для розгортання зловмисного буткіта, це замінити наявний бінарний файл Windows Boot Manager ( bootmgfw.efi ) у каталозі ESP:\EFI\Microsoft\Boot\ власною самопідписаною шкідливою програмою UEFI зловмисників. Оскільки UEFI Secure Boot вимкнено (і, таким чином, під час завантаження не виконується перевірка цілісності), експлуатація не потрібна, і мікропрограма UEFI просто запускає шкідливий менеджер завантаження, не викликаючи жодних порушень безпеки.
Щоб пізніше можна було запускати власний непідписаний код ядра, інсталятор має переконатися, що HVCI вимкнено в системі. Один із наших колег з ESET написав дуже інформативний допис у блозі на цю тему у 2022 році ( Підписані драйвери ядра – незахищений шлюз до ядра Windows ):
Безпека на основі віртуалізації (VBS) пропонує кілька функцій захисту, найпомітнішою з яких є Hypervisor-Protected Code Integrity (HVCI), яка також постачається як окрема функція. HVCI забезпечує цілісність коду в ядрі та дозволяє виконувати лише підписаний код. Це ефективно запобігає зловживанню вразливими драйверами для виконання непідписаного коду ядра або завантаження шкідливих драйверів (незалежно від використовуваного методу експлуатації), і, схоже, зловмисне програмне забезпечення, яке зловживає вразливими драйверами для завантаження шкідливого коду, було однією з головних мотивацій Microsoft для впровадження цієї функції.
Як показано на малюнку 5, щоб вимкнути цю функцію, інсталятор встановлює значення реєстру Enabled у розділі реєстру HypervisorEnforcedCodeIntegrity на нуль.
Наступною функцією, яку дезактивує інсталятор, є BitLocker Drive Encryption. Причиною цього є те, що BitLocker можна використовувати в поєднанні з модулем довіреної платформи (TPM), щоб гарантувати, що різні завантажувальні файли та конфігурації, включаючи Secure Boot, не були підроблені, оскільки шифрування диска BitLocker було налаштовано в системі. Враховуючи, що інсталятор змінює ланцюжок завантаження Windows на скомпрометованій машині, увімкнення BitLocker для систем із підтримкою TPM призведе до появи екрану відновлення BitLocker під час наступного завантаження та повідомить жертві, що систему зламано.
Щоб вимкнути цей захист, інсталятор BlackLotus:
переглядає всі томи в просторі імен WMI Root\CIMV2\Security\MicrosoftVolumeEncryption і перевіряє їхній статус захисту, викликаючи метод GetProtectionStatus класу WMI Win32_EncryptableVolume
для тих, хто захищений BitLocker, він викликає метод DisableKeyProtectors із параметром DisableCount, встановленим на нуль, що означає, що захист буде призупинено, доки його не буде ввімкнено вручну
Коли необхідний захист вимкнено та всі файли розгорнуті, інсталятор реєструється для видалення під час наступного перезавантаження системи та перезавантажує машину, щоб перейти до використання CVE-2022-21894.
У цій частині ми докладніше розглянемо, як BlackLotus досягає стійкості в системах з увімкненим UEFI Secure Boot. Оскільки ланцюжок виконання, який ми збираємося описати, досить складний, ми спочатку пояснимо основні принципи, а потім заглибимося в технічні деталі.
У двох словах цей процес складається з двох ключових кроків:
Використання CVE-2022-21894 для обходу функції безпечного завантаження та встановлення буткіта. Це дозволяє виконувати довільний код на ранніх етапах завантаження, коли платформа все ще належить мікропрограмі, а функції UEFI Boot Services все ще доступні. Це дозволяє зловмисникам робити багато речей, які вони не повинні мати на комп’ютері з увімкненим UEFI Secure Boot, не маючи до нього фізичного доступу, наприклад, змінювати змінні NVRAM лише для служб завантаження. І це те, чим зловмисники користуються, щоб налаштувати постійність для буткіта на наступному кроці. Додаткову інформацію про використання можна знайти в розділі Використання CVE-2022-21894 .
Налаштування постійності шляхом запису власного MOK до MokList , змінної NVRAM лише для служб завантаження. Роблячи це, він може використовувати законну прокладку , підписану Microsoft , для завантаження свого самопідписаного (підписаного закритим ключем, що належить до ключа, записаного в MokList ) буткіта UEFI замість використання вразливості під час кожного завантаження. Докладніше про це в розділі збереження Bootkit.
Щоб полегшити детальний аналіз у наступних двох розділах, ми виконаємо кроки, показані на схемі виконання, малюнок 6.
Щоб обійти Secure Boot, BlackLotus використовує батон (CVE-2022-21894): Secure Boot Security Feature Bypass Vulnerability. Незважаючи на великий вплив на безпеку системи, ця вразливість не привернула такої уваги громадськості, як вона заслуговувала. Хоча вразливість було виправлено в оновленні Microsoft за січень 2022 року, її використання все ще можливо, оскільки уражені двійкові файли ще не додано до списку відкликаних файлів UEFI. У результаті зловмисники можуть перенести власні копії вразливих двійкових файлів на комп’ютери своїх жертв, щоб скористатися цією вразливістю та обійти Secure Boot в найновіших системах UEFI.
Крім того, експлойт Proof of Concept (PoC) для цієї вразливості був загальнодоступним із серпня 2022 року. Беручи до уваги дату першого подання BlackLotus VirusTotal (див. рисунок 1), розробник зловмисного ПЗ, ймовірно, щойно адаптував доступний PoC до своїх потреб без будь-яка потреба в глибокому розумінні того, як працює цей експлойт.
Давайте почнемо з короткого ознайомлення з уразливістю, здебільшого підсумовуючи ключові моменти з опису, опублікованого разом із PoC на GitHub:
Уражені завантажувальні програми Windows (наприклад, bootmgr.efi , hvloader.efi , winload.efi …) дозволяють видаляти серіалізовану політику безпечного завантаження з пам’яті – до того, як її завантажить програма – за допомогою параметра завантаження truncatememory BCD.
Це дозволяє зловмисникам використовувати інші небезпечні параметри BCD, такі як bootdebug , testsigning або nointegritychecks , таким чином порушуючи Secure Boot.
Існують різні способи використання цієї вразливості – три з них опубліковано в репозиторії PoC.
Як приклад, один із PoCs показує, як це можна використати, щоб змусити законний hvloader.efi завантажувати довільний самопідписаний двійковий файл mcupdate_<platform>.dll (де <platform> може бути GenuineIntel або AuthenticAMD , на основі комп’ютера ЦП.).
Тепер ми продовжуємо з описом того, як BlackLotus використовує цю вразливість (цифри в списку нижче описують відповідні кроки на малюнку 6):
Після того, як інсталятор перезавантажить машину, мікропрограма UEFI завантажить перший параметр завантаження. Для систем Windows першим варіантом завантаження за замовчуванням є bootmgfw.efi, розташований у папці ESP:/EFI/Microsoft/Boot на ESP. Цього разу замість виконання початкового bootmgfw.efi жертви (який раніше інсталятор перейменував на winload.efi ), мікропрограма виконує вразливий файл – розгорнутий інсталятором.
Після виконання bootmgfw.efi завантажуються параметри завантаження BCD, попередньо змінені інсталятором. На рисунку 7 показано порівняння законного BCD і модифікованого.
Як ви бачите на малюнку 7 (шлях підкреслено зеленим), законний диспетчер завантаження Windows зазвичай завантажує завантажувач ОС Windows ( \WINDOWS\system32\winload.efi ) як програму завантаження за замовчуванням. Але цього разу, із зміненим BCD, він продовжує завантаження вразливого ESP:\system32\bootmgr.efi , із значенням BCD-элемента Avoidlowmemory 0x10000000 і custom:22000023 BCD-елемента, що вказує на BCD іншого зловмисника, що зберігається в ESP: \system32\bcd . Пояснення використання цих елементів можна знайти в опублікованому PoC:
Зловмисник повинен переконатися, що серіалізована політика безпечного завантаження розміщена над відомою фізичною адресою. […] Елемент Avoidlowmemory можна використовувати, щоб гарантувати, що всі виділення фізичної пам’яті перевищують вказану фізичну адресу .
Починаючи з Windows 10, цей елемент заборонено, якщо ввімкнено VBS, але оскільки він використовується під час ініціалізації програми завантаження, перед тим, як серіалізована політика безпечного завантаження буде зчитана з пам’яті, завантажує bootmgr і вказує настроюваний шлях BCD (використовуючи елемент bcdfilepath , також відомий як custom: 22000023 ) можна використовувати, щоб обійти це.
На наступному кроці виконаний ESP:\system32\bootmgr.efi завантажує додатковий BCD, розташований у ESP:\system32\bcd . Проаналізований вміст цього додаткового BCD показано на рисунку 8.
Через параметри, завантажені з файлу BCD, показаного на малюнку 8, bootmgr.efi продовжує завантажувати іншу вразливу програму завантаження Windows, розгорнуту інсталятором – ESP:\system32\hvloader.efi – яка є завантажувачем гіпервізора Windows. Що ще важливіше, додаткові параметри BCD вказані в тому самому файлі BCD (див. Малюнок 8):
truncatememory зі значенням 0x10000000
nointegritychecks встановлено на Так
і testsigning , також встановлено на Так
І тут відбувається магія. Оскільки серіалізована політика безпечного завантаження має бути завантажена на фізичні адреси, вищі за 0x10000000 (через застосований у попередніх кроках параметр Avoidlowmemory ), вказівка елемента truncatememory ефективно видалить його – таким чином, безпечне завантаження буде розірвано та дозволено використання небезпечних параметрів BCD, таких як nointegritychecks або testsigning . Використовуючи ці параметри, зловмисники можуть змусити hvloader.efi виконувати свій власний самопідписаний код.
Для цього використовується той самий трюк, що описаний у PoC: під час його виконання законний hvloader.efi завантажує та виконує mcupdate_{GenuineIntel| Двійковий файл AuthenticAMD}.dll із каталогу <device>:\<SystemRoot>\system32\ . Декомпільований код Hex-Rays із коментарями функції з hvloader.efi , відповідальної за завантаження цього двійкового файлу mcupdate*.dll, показано на рисунку 9. Зауважте, що hvloader.efi зазвичай завантажує цей законний двійковий файл mcupdate*.dll із <OS_partition> :\ Windows\system32 , але цього разу самопідписана mcupdate*.dll зловмисників виконується зі спеціального каталогу ESP, попередньо створеного інсталятором ( ESP:\system32 ). Це спричинено тим, що пристрій параметрів BCD і системний корень , які використовуються в BCD на малюнку 8, вказують поточний пристрій як завантажувальний – тобто ESP – і також вказують, що SystemRoot є кореневим ( \ ) каталогом на цьому пристрої.
Тепер, коли власний самопідписаний файл mcupdate*.dll зловмисників завантажується та виконується, він продовжує виконання останнього компонента в цьому ланцюжку – вбудованого MokInstaller (додаток UEFI) – див. Малюнок 10, щоб дізнатися, як це робиться.
Тепер MokInstaller може продовжити налаштування збереження, зареєструвавши MOK зловмисників у змінну NVRAM і налаштувавши законний двійковий файл прокладки з підписом Microsoft як завантажувач за замовчуванням. Перш ніж перейти до деталей, трохи теорії про прокладку та MOK.
shim — це завантажувач UEFI першого етапу, розроблений розробниками Linux для того, щоб різні дистрибутиви Linux працювали з UEFI Secure Boot. Це проста програма, яка має на меті завантажити, перевірити та запустити іншу програму – у випадку систем Linux це зазвичай завантажувач GRUB. Це працює таким чином, що Microsoft підписує лише прокладку , а прокладка подбає про решту – вона може перевірити цілісність завантажувача другого етапу за допомогою ключів зі змінної db UEFI, а також вставляє власний список «дозволених» або «відкликані» ключі чи хеші, щоб переконатися, що компоненти, яким довіряють як платформи, так і розробники shim (наприклад, Canonical, RedHat тощо), дозволено виконуватися. На додаток до цих списків, shim також дозволяє використовувати зовнішню базу даних ключів, якою керує користувач, відому як список MOK. Малюнок 11 добре ілюструє, як працює UEFI Secure Boot з MOK.
Ця база даних MOK зберігається в змінній NVRAM лише для завантаження під назвою MokList . Без використання вразливості, подібної до описаної вище, потрібен фізичний доступ, щоб змінити її в системі з увімкненим UEFI Secure Boot (вона доступна лише під час завантаження, перш ніж завантажувач ОС викличе функцію UEFI Boot Services ExitBootServices ). Однак, використовуючи цю вразливість, зловмисники можуть обійти UEFI Secure Boot і виконати свій власний самопідписаний код перед викликом ExitBootServices , тож вони можуть легко зареєструвати свій власний ключ (шляхом зміни змінної MokList NVRAM), щоб виконати прокладку. будь-яку програму, підписану цим зареєстрованим ключем, без порушення безпеки.
Продовжуючи опис потоку з рисунка 6 – крок 8… Програма MokInstaller UEFI продовжує налаштування збереження для буткіта BlackLotus UEFI і покриває шляхи експлуатації, виконавши:
Відновлення оригінального сховища BCD жертви з резервної копії, створеної інсталятором, і заміна efi на законну прокладку з підписом Microsoft, попередньо перекинуту інсталятором до ESP:\system32\bootload.efi .
Створення змінної MokList NVRAM, що містить самопідписаний сертифікат відкритого ключа зловмисника. Зауважте, що ця змінна відформатована так само, як і будь-які інші змінні бази даних підписів UEFI (наприклад, db або dbx), і вона може складатися з нуля або більше списків підписів типу EFI_SIGNATURE_LIST , як визначено в Специфікації UEFI.
Видалення всіх файлів, залучених до експлуатації, з папки зловмисників ESP:\system32\ .
Зрештою, він перезавантажує машину, щоб змусити розгорнуту прокладку виконати самопідписаний буткіт, який інсталятор перекинув до \EFI\Microsoft\Boot\grubx64.efi ( grubx64.efi зазвичай є завантажувачем другого етапу за замовчуванням, який виконує прокладка на системах x86-64).
Код, який виконує дії, описані в останніх двох кроках, показаний на малюнку 12.
Після налаштування збереження завантажувальний пакет BlackLotus запускається під час кожного запуску системи. Метою буткіта є розгортання драйвера ядра та кінцевого компонента режиму користувача – завантажувача HTTP. Під час виконання він намагається вимкнути додаткові функції безпеки Windows – безпеку на основі віртуалізації (VBS) і Windows Defender – щоб підвищити ймовірність успішного розгортання та прихованої роботи. Перш ніж перейти до деталей того, як це робиться, давайте підсумуємо основи драйвера ядра та завантажувача HTTP:
Розгортаємо наступний компонент ланцюжка – завантажувач HTTP.
Збереження вантажника живим у разі припинення.
Захист файлів буткіта від видалення з ESP.
Виконання додаткових корисних навантажень ядра, якщо це вказано завантажувачем HTTP.
Видалення буткіта, якщо це вказує HTTP-завантажувач.
Спілкування зі своїм C&C.
Виконання команд, отриманих від C&C.
Завантаження та виконання корисних навантажень, отриманих від C&C (підтримує як корисні навантаження ядра, так і корисні навантаження в режимі користувача).
Повний потік виконання (спрощений) від інсталятора до HTTP-завантажувача показаний на малюнку 13. Ми описуємо ці окремі кроки більш детально в наступному розділі.
Етапи виконання такі (ці кроки показано на малюнку 13):
На першому етапі мікропрограма UEFI виконує параметр завантаження Windows за замовчуванням, який зазвичай зберігається в папці \EFI\Microsoft\Boot\bootmgfw.efi . Як ми описали раніше ( розділ збереження Bootkit, 8 .a ), двійковий файл MokInstaller замінив цей файл законною підписаною прокладкою .
Коли shim виконується, він зчитує змінну MokList NVRAM і використовує сертифікат, який раніше зберігали зловмисники, щоб перевірити завантажувач другого етапу – самопідписаний завантажувальний пакет BlackLotus UEFI, розташований у \EFI\Microsoft\Boot\grubx64.efi .
Після перевірки прокладка виконує буткіт.
Буткіт починається зі створення змінної Boot-only VbsPolicyDisable NVRAM. Як описано тут, ця змінна оцінюється завантажувачем ОС Windows під час завантаження, і якщо її визначено, основні функції VBS, такі як HVCI та Credential Guard, не будуть ініціалізовані.
У наступних кроках (5. a–e) буткіт продовжується за загальним шаблоном, який використовується буткітами UEFI. Він перехоплює виконання компонентів, включених до типового потоку завантаження Windows, таких як диспетчер завантаження Windows, завантажувач ОС Windows і ядро ОС Windows, і перехоплює деякі з їхніх функцій у пам’яті. Як бонус, він також намагається вимкнути Windows Defender, виправивши деякі з його драйверів. Усе це для того, щоб забезпечити виконання корисного навантаження на ранніх етапах процесу запуску ОС і уникнути виявлення. Наступні функції підключені або виправлені:
ImgArchStartBootApplication у bootmgfw.efi або bootmgr.efi :цю функцію зазвичай підхоплюють буткіти, щоб уловити момент, коли завантажувач ОС Windows ( winload.efi ) завантажується в пам’ять, але все ще не виконується – це правильний момент для виконувати більше виправлень у пам’яті.
BlImgAllocateImageBuffer у winload.efi :використовується для виділення додаткового буфера пам’яті для шкідливого драйвера ядра.
OslArchTransferToKernel у winload.efi :підключено, щоб уловити момент, коли ядро ОС і деякі системні драйвери вже завантажено в пам’ять, але ще не виконано – це ідеальний момент для виконання додаткових виправлень у пам’яті. Драйвери, згадані нижче, виправлені в цьому хуку. Код цього хука, що відповідає за пошук відповідних драйверів у пам’яті, показано на малюнку 14.
WdBoot.sys і WdFilter.sys :BlackLotus виправляє точку входу WdBoot.sys і WdFilter.sys – драйвер ELAM Захисника Windows і драйвер фільтра файлової системи Захисника Windows відповідно – для негайного повернення.
disk.sys :Буткіт перехоплює точку входу драйвера disk.sys для виконання драйвера ядра BlackLotus на ранніх етапах ініціалізації системи.
Потім, коли ядро ОС виконує точку входу драйвера disk.sys , встановлений хук переходить до точки входу шкідливого драйвера ядра. Шкідливий код, у свою чергу, відновлює оригінальний disk.sys , щоб забезпечити належну роботу системи, і чекає, доки не запуститься процес winlogon.exe .
Коли зловмисний драйвер виявляє, що процес winlogon.exe почався, він впроваджує та виконує останній компонент режиму користувача – завантажувач HTTP – у нього.
Драйвер ядра відповідає за чотири основні завдання:
Впровадження завантажувача HTTP у winlogon.exe та повторне його введення, якщо потік завершився.
Захист файлів буткіта, розгорнутих на ESP, від видалення.
Вимкнення процесу Windows Defender у режимі користувача MsMpEngine.exe .
Спілкування з HTTP-завантажувачем і, якщо необхідно, виконання будь-яких команд.
Драйвер ядра відповідає за розгортання завантажувача HTTP. Коли драйвер запускається, він очікує, поки не запуститься процес під назвою winlogon.exe , перш ніж виконувати будь-які інші дії. Після початку процесу драйвер розшифровує двійковий файл завантажувача HTTP, вставляє його в адресний простір winlogon.exe та виконує його в новому потоці. Потім драйвер продовжує періодично перевіряти, чи потік все ще працює, і повторює введення, якщо це необхідно. Завантажувач HTTP не буде розгорнуто, якщо драйвер виявить налагоджувач ядра.
Щоб захистити файли буткіта, розташовані на ESP, драйвер ядра використовує простий прийом. Він відкриває всі файли, які хоче захистити, дублює та зберігає їхні дескриптори, а також використовує функцію ядра ObSetHandleAttributes , вказуючи прапорець ProtectFromClose всередині параметра HandleFlags ( OBJECT_HANDLE_FLAG_INFORMATION ) на 1 – таким чином захищаючи дескриптори від закриття будь-якими іншими процесами. Це завадить будь-яким спробам видалити чи змінити захищені файли. Захищено такі файли:
ESP:\EFI\Microsoft\Boot\winload.efi
ESP:\EFI\Microsoft\Boot\bootmgfw.efi
ESP:\EFI\Microsoft\Boot\grubx64.efi
Якщо користувач спробує видалити ці захищені файли, станеться щось подібне до того, що показано на малюнку 15.
Як інший рівень захисту, якщо користувач або програмне забезпечення безпеки зможе зняти прапор захисту та закрити маркери, драйвер ядра постійно відстежує їх і викликає BSOD, викликаючи функцію KeBugCheck( INVALID_KERNEL_HANDLE), якщо будь-який із маркерів більше не існують.
Драйвер ядра також намагається вимкнути головний процес Windows Defender – MsMpEng.exe . Це робиться шляхом видалення всіх привілеїв маркерів процесу, установивши атрибут SE_PRIVILEGE_REMOVED для кожного з них. Як наслідок, процес Defender не зможе належним чином виконувати свою роботу, наприклад сканувати файли. Однак, оскільки ця функція реалізована погано, її можна зробити неефективною, перезапустивши процес MsMpEng.exe .
Драйвер ядра здатний спілкуватися із завантажувачем HTTP за допомогою іменованої події та розділу. Імена використовуваних іменованих об’єктів генеруються на основі MAC-адреси мережевого адаптера жертви (ethernet). Якщо значення октету менше 16, то до нього додається 16. Формат імен згенерованих об’єктів може відрізнятися в різних зразках. Як приклад, в одному із зразків, які ми проаналізували, для MAC-адреси 00-1c-0b-cd-ef-34 згенеровані імена будуть такими:
\BaseNamedObjects\101c1b : для названого розділу (використовуються лише перші три октети MAC)
\BaseNamedObjects\ Z 01c1b : для іменованої події – так само, як і для розділу, але перша цифра MAC-адреси замінюється на Z
Якщо HTTP-завантажувач хоче передати якусь команду драйверу ядра, він просто створює іменований розділ, записує команду з пов’язаними даними всередині та чекає, поки команда буде оброблена драйвером, створюючи іменовану подію та чекаючи, поки драйвер запускає (або сигналізує) про це.
Драйвер підтримує такі зрозумілі команди:
Встановити драйвер ядра
Видаліть BlackLotus
Уважний читач може помітити тут слабке місце BlackLotus — навіть якщо буткіт захищає свої компоненти від видалення, драйвер ядра можна обманом змусити повністю видалити буткіт, створивши вищезгадані іменовані об’єкти та надіславши йому команду видалення.
Останній компонент відповідає за зв’язок з C&C сервером і виконання будь-яких команд C&C, отриманих від нього. Усі корисні навантаження, які ми змогли виявити, містять три команди. Ці команди дуже прості, і, як випливає з назви розділу, вони здебільшого стосуються завантаження та виконання додаткових корисних навантажень за допомогою різних технік.
Для зв’язку зі своїм C&C завантажувач HTTP використовує протокол HTTPS. Уся інформація, необхідна для зв’язку, вбудована безпосередньо у двійковий файл завантажувача, включаючи використовувані домени C&C і шляхи ресурсів HTTP. Інтервал за замовчуванням для зв’язку з сервером C&C встановлено на одну хвилину, але його можна змінити на основі даних з C&C. Кожен сеанс зв’язку з C&C починається з надсилання до нього маякового повідомлення HTTP POST. У зразках, які ми проаналізували, такі шляхи до ресурсів HTTP можна вказати в заголовках HTTP POST:
/network/API/hpb_gate[.]php
/API/hpb_gate[.]php
/gate[.]php
/hpb_gate[.]php
Перед даними маякового повідомлення додається рядок checkin =, що містить основну інформацію про скомпрометовану машину, включаючи спеціальний ідентифікатор машини (іменований як HWID ), стан безпечного завантаження UEFI, різноманітну інформацію про апаратне забезпечення та значення, яке виглядає як BlackLotus номер збірки. HWID генерується з MAC-адреси машини (ethernet) і серійного номера системного тому. Формат повідомлення перед шифруванням такий, як показано на малюнку 16.
Перед надсиланням повідомлення до C&C дані спочатку шифруються за допомогою вбудованого ключа RSA, а потім закодовані за допомогою безпечного URL-адреси base64. Під час аналізу ми виявили, що в зразках використовуються два різні ключі RSA. Приклад такого запиту HTTP-маяка показано на малюнку 17.
Дані, отримані від C&C як відповідь на повідомлення маяка, повинні починатися з двобайтового магічного значення HP; інакше відповідь не обробляється далі. Якщо магічне значення правильне, дані, наступні за магічним значенням, розшифровуються за допомогою 256-бітного AES у режимі CBC з використанням вищезазначеного рядка HWID як ключа.
Після розшифровки повідомлення схоже на маяк, рядок у форматі JSON, і визначає ідентифікатор команди (який згадується як Type ) і різні додаткові параметри, такі як:
Інтервал зв’язку C&C
Використовувати спосіб виконання
Ім’я файлу корисного навантаження
Тип корисного навантаження на основі розширення файлу ( підтримуються .sys , .exe або .dll )
Маркер автентифікації, який має використовуватися для запиту завантаження корисних даних
Ключ AES, який використовується для розшифровки корисних даних
Усі підтримувані команди та їхні описи наведено в таблиці 2.
Команди C&C
Тип команди 1 — Завантажте та запустіть драйвер ядра, DLL або звичайний виконуваний файл.
Тип команди 2 — Завантажте корисне навантаження, видаліть буткіт і запустіть корисне навантаження (ймовірно, використовується для оновлення буткіта).
Тип команди 3 — Видаліть буткіт і вийдіть.
У цих командах C&C може вказати, чи має корисне навантаження спочатку бути скинуто на диск перед його виконанням, чи виконуватися безпосередньо в пам’яті. У випадках, коли файл переміщується на диск, папка ProgramData на томі ОС використовується як папка призначення, а ім’я та розширення файлу вказуються сервером C&C. У разі виконання файлів безпосередньо в пам’яті svchost.exe використовується як мета ін’єкції. Коли C&C надсилає команду, що вимагає взаємодії драйвера ядра, або оператор хоче виконати код у режимі ядра, використовується механізм, описаний у розділі «Зв’язок із завантажувачем HTTP» .
Щоб ускладнити виявлення та аналіз цього зловмисного програмного забезпечення, його автор намагався мінімально обмежити видимість стандартних файлових артефактів, таких як текстові рядки, імпорт або інші незашифровані вбудовані дані. Нижче наведено короткий перелік використаних методів.
Шифрування рядків і даних
Усі рядки, які використовуються у зразках, зашифровано за допомогою простого шифру.
Усі вбудовані файли зашифровано за допомогою 256-бітного AES у режимі CBC.
Ключі шифрування для окремих файлів можуть відрізнятися від зразка до зразка.
Окрім шифрування AES, деякі файли також стискаються за допомогою LZMS.
Роздільна здатність API лише під час виконання
У всіх зразках (якщо застосовно) Windows API завжди вирішуються виключно під час виконання, а хеші функцій замість імен функцій використовуються для пошуку потрібних адрес функцій API у пам’яті.
У деяких випадках для виклику потрібної системної функції використовується прямий виклик інструкції системного виклику .
Мережевий зв’язок
Спілкується за допомогою HTTPS.
Усі повідомлення, надіслані до C&C завантажувачем HTTP, шифруються за допомогою вбудованого відкритого ключа RSA.
Усі повідомлення, надіслані з C&C до завантажувача HTTP, шифруються за допомогою ключа, отриманого з машинного середовища жертви, або за допомогою ключа AES, наданого C&C.
Трюки проти налагодження та захисту від віртуальної машини – якщо використовуються, зазвичай розміщуються прямо на початку точки входу. Використовуються лише звичайні трюки виявлення пісочниці або налагоджувача.
Перш за все, звичайно, необхідно підтримувати свою систему та її продукт безпеки в актуальному стані, щоб збільшити ймовірність того, що загрозу буде зупинено на самому початку, перш ніж вона зможе досягти стійкості до ОС.
Потім ключовим кроком, який потрібно зробити, щоб запобігти використанню відомих уразливих двійкових файлів UEFI для обходу безпечного завантаження UEFI, є їх відкликання в базі даних відкликань UEFI ( dbx ) – у системах Windows оновлення dbx слід поширювати за допомогою оновлень Windows.
Проблема полягає в тому, що відкликання широко використовуваних двійкових файлів Windows UEFI може призвести до того, що тисячі застарілих систем, образів відновлення або резервних копій стануть неможливими для завантаження, і тому відкликання часто триває надто довго.
Зауважте, що відкликання програм Windows, які використовує BlackLotus, запобіжить інсталяції буткіта, але оскільки інсталятор замінить завантажувач жертви на відкликаний, це може призвести до неможливості завантаження системи. Щоб відновити в цьому випадку, перевстановіть ОС або просто відновіть ESP.
Якщо відкликання станеться після встановлення збереження BlackLotus, буткіт залишатиметься функціональним, оскільки він використовує законну прокладку зі спеціальним ключем MOK для збереження. У цьому випадку найбезпечнішим рішенням пом’якшення буде перевстановлення Windows і видалення зареєстрованого зловмисниками ключа MOK за допомогою утиліти mokutil (для виконання цієї операції необхідна фізична присутність через необхідну взаємодію користувача з диспетчером MOK під час завантаження).
За останні кілька років було виявлено багато критичних уразливостей, що впливають на безпеку систем UEFI. На жаль, через складність усієї екосистеми UEFI та пов’язаних з нею проблем ланцюга постачання багато з цих вразливостей зробили багато систем уразливими навіть через тривалий час після того, як уразливості було виправлено – або принаймні після того, як нам сказали, що їх усунули. Для кращого зображення ось кілька прикладів помилок виправлення або відкликання, що дозволяють обходити UEFI Secure Boot лише за останній рік:
Перш за все, звичайно, CVE-2022-21894 – уразливість, яку використовує BlackLotus. Через рік після усунення вразливості вразливі двійкові файли UEFI досі не відкликано, що дозволяє таким загрозам, як BlackLotus, непомітно працювати на системах із увімкненим безпечним завантаженням UEFI, таким чином створюючи у жертв помилкове відчуття безпеки.
На початку 2022 року ми оприлюднили кілька вразливостей UEFI, які дозволяють, серед іншого, вимкнути безпечне завантаження UEFI. Багато пристроїв, які постраждали, більше не підтримуються OEM, тому не виправлено (хоча ці пристрої були не такими вже й старими – приблизно 3-5 років на момент розкриття вразливості). Докладніше читайте в нашому блозі: Коли «захищений» зовсім не безпечний: у споживчих ноутбуках Lenovo виявлено серйозні вразливості UEFI.
Пізніше у 2022 році ми виявили кілька інших уразливостей UEFI, використання яких також дозволить зловмисникам дуже легко вимкнути безпечне завантаження UEFI. Як зазначили колеги-дослідники з Binarly, кілька пристроїв, перелічених у консультації, залишилися без виправлень або не були виправлені належним чином навіть через кілька місяців після консультації, через що пристрої стали вразливими. Зайве говорити, що, як і в попередньому випадку, деякі пристрої залишаться вразливими назавжди, оскільки їхня дата припинення підтримки.
Було лише питанням часу, коли хтось скористається цими збоями та створить завантажувальний пакет UEFI, здатний працювати на системах із увімкненим UEFI Secure Boot. Як ми запропонували минулого року в нашій презентації RSA, усе це робить перехід на ESP більш здійсненним для зловмисників і можливим шляхом уперед для загроз UEFI – існування BlackLotus це підтверджує.
ESET Research пропонує приватні звіти APT та канали даних. Якщо у вас є запитання щодо цієї служби, відвідайте сторінку ESET Threat Intelligence .
912 
1354 
542