UEFI Bootkit: від лабораторії до реальності, з акцентом на Bootkitty та BlackLotus

L Буткіти UEFI Всього за кілька років вони перетворилися з лабораторної концепції на справжній головний біль для захисників та виробників. У цій галузі межа між перевіркою концепції та операційною загрозою розмита, і такі випадки, як чорний лотос або нещодавнє відкриття Bootkitty на Linux Вони це переконливо доводять.

Ця стаття об'єднує та пояснює, з чітка мова та технічні деталі коли вони додають цінність, найбільш релевантні, опубліковані дослідниками та компаніями в цьому секторі: від першого PoC у 2012 році до сучасних кампаній, включаючи такі вразливості, як CVE-2024-7344 які дозволяють обійти Secure Boot, методи ухилення, IoC (Interface Components), а також заходи виявлення та пом'якшення наслідків, що дійсно працюють у реальному світі.

Що таке буткіт UEFI і чому він такий проблематичний?

Буткит UEFI — це імплантат, який працює перед операційною системою, з можливістю контролювати потік завантаження, вимикати перевірки та завантажувати компоненти з високими привілеями. Працюючи на такому низькому рівні, можна уникнути традиційний антивірус і навіть певні «заходи безпечного старту» якщо він використовує недоліки або дозвільні конфігурації.

У реальному світі вже спостерігалися стійкі імпланти та методи UEFI, такі як LoJax, MosaicRegressor o MoonBounceвіхи, що показують, як актор може зайняти прошивку та опанувати критичні фази завантаження, що ускладнює судово-медичний аналіз та відновлення.

Захищати Windows, Microsoft об'єднує кілька рівнів: безпечне завантаження (UEFI перевіряє завантажувач за допомогою довірених сертифікатів), Довірене завантаження (ядро перевіряє решту компонентів), ЕЛАМ (Захист від шкідливих програм раннього запуску, який перевіряє драйвери завантаження) та Виміряне завантаження (Вимірювання TPM та дистанційна атестація). Це корисні, але не безпомилкові перешкоди для вразливості самої екосистеми UEFI або надмірно широкі налаштування довіри. Крім того, можливо щит Windows за допомогою Credential Guard, BitLocker та WDAC для зменшення ризику довгострокового збереження даних.

Від PoC до реального життя: хронологія та ключові гравці

Подорож починається у 2012 році з PoC Андреа Аллієві для Windows на UEFI, а потім такі проекти, як EfiGuard, Boot Backdoor або UEFI-bootkit. Знадобилися роки, перш ніж були задокументовані реальні випадки, такі як ESPecter (ESET, 2021) або Буткіт FinSpy (Kaspersky, 2021), а у 2023 році він увірвався на сцену чорний лотос, перший буткіт UEFI, здатний Обхід безпечного завантаження на повністю оновлених системахУ лабораторних умовах це поширене явище тестування шкідливого програмного забезпечення на віртуальній машині оцінювати PoC (показники дії) та виявлення, не наражаючи на ризик продуктивну інфраструктуру.

Щось було незмінним досі: метою було виключно комп'ютери WindowsЦе припущення було спростовано, коли в листопаді 2024 року на VirusTotal з'явився додаток UEFI під назвою VirusTotal. bootkit.efiАналіз виявив буткіт, який його автори назвали Буткітті, призначений для Linux (Ubuntu)Згідно з телеметричними даними, підтвердженого фактичного розгортання немає; а самі автори, пов'язані з корейською навчальною програмою Найкращі з найкращих (BoB), вони уточнили, що це було доказ концепції з метою підвищення обізнаності.

Бінарний файл Bootkitty підписано за допомогою самопідписаний сертифікатЦе означає, що він не працюватиме з увімкненим безпечним завантаженням, якщо встановити сертифікати зловмисникаТим не менш, його логіка ілюструє, як актор може виправити в пам'яті компоненти завантажувач (GRUB) і ядро Linux обійти перевірки.

Bootkitty детально: артефакти, сумісність та що він змінює

Буткіт містить невикористані функції, які друкують ASCII-зображення з назвою Буткітті і список можливих авторів. Також відображається текстовий рядок при кожному запуску та посилання на BlackCat у його виводі та у пов’язаному модулі ядра, не пов’язаному з програмою-вимагачем ALPHV/BlackCat; частково тому, що Bootkitty написано на C, тоді як ALPHV розвивається в Rust.

Його сумісність обмежена. Щоб знайти функції, які потрібно торкнутися, скористайтеся закодовані байтові шаблони (класична техніка буткіту), але обрані шаблони не охоплюють кілька версій ядра або GRUB. В результаті імплантат функціональний лише в дуже обмеженому наборі конфігурацій, і, крім того, виправлення фіксованих зміщень після розпакування ядра: якщо зміщення не відповідають версії, це може перезаписати випадкові дані та спричинити покласти слухавку замість зобов'язання.

Черевик починається з шим запуск Bootkitty, який спочатку запитує стан SecureBoot і розміщує перехоплювачі у двох протоколах автентифікації UEFI: EFI_SECURITY2_ARCH_PROTOCOL.Автентифікація файлів y EFI_SECURITY_ARCH_PROTOCOL.Стан автентифікації файлуВ обох випадках встановіть вивід на повернення EFI_УСПІХ, що фактично скасовує перевірку цілісності PE-образу під час передопераційного періоду.

Потім Bootkitty завантажує легітимний GRUB з жорстко закодованого шляху на ESP (/EFI/ubuntu/grubx64-real.efi), виправляє його в пам'яті та ключові функції гачків перш ніж його буде виконано.

Підключення до GRUB та розпакування ядра Linux

Імплантат змінює функцію початкове_зображення модуля зображення GRUB, що відповідає за запуск уже завантажених бінарних файлів PE (таких як Заглушка ядра EFI, vmlinuz.efi/vmlinuz). Скористайтеся тим фактом, що ядро ​​вже знаходиться в пам'яті, і додайте в підпрограму перехоплювач, який розпакує фактичний образ ядра (ймовірно zstd_decompress_dctx залежно від збірки), тому після розпакування ви можете гарячий патч.

Це також змінює функцію grub_verifiers_open, який вирішує, чи перевіряти цілісність кожного завантаженого файлу (модулів, ядра, конфігурації тощо). Хук повертає результат негайно, і таким чином, уникає будь-якої перевірки підписуЗі свого боку, коригування в ініціалізація_перевірки_блокування_прокладки Це заплутує: воно змушує використовувати суворіший прапор верифікації (GRUB_VERIFY_FLAGS_SINGLE_CHUNK), але ця функція навіть не викликається іншим гачком, залишаючи Не має значення.

Після розпакування ядра код Bootkitty застосовує три модифікації пам'яті: він перезаписує рядок версії/банера з ядра з текстом "BoB13"; примусово це зробити перевірка_підпису_модуля() повернути 0 для завантаження ядра непідписані модулі; та замінює першу змінну середовища процесу ініціалізації вводити LD_PRELOAD=/opt/injector.so /init на початку простору користувача.

Ін'єкція через LD_PRELOAD Це класична тактика для визначення пріоритету спільного об'єкта ELF та перевизначення функцій. Тут ланцюжок має особливість (він містить "/init" поруч з LD_PRELOAD), деталь, яка підкреслює характер Незавершений PoC а не відшліфовану операцію. Нібито введені бінарні файли не були помічені, хоча в наступному третьому документі вказувалося, що вони використовуються лише для завантажити додатковий етап.

Ознаки, симптоми та просте лікування

Якщо Bootkitty присутній, можна побачити видимі підказки. Команда uname -v відобразить версію ядра зі зміненим текстом та в dmesg Банер також може виглядати зміненим. Крім того, можна виявити, що процес PID 1 (init) було випущено разом із LD_PRELOAD інспектування /proc/1/середовище, аномальний сигнал у легітимних системах.

У лабораторних дослідженнях ядро ​​з'являється заплямований після завантаження за допомогою Bootkitty, а також ще одна емпірична перевірка на комп'ютерах з увімкненим Secure Boot — спробувати завантажити непідписаний модульЯкщо дозволено гаряче навантаження, це означає, що перевірка_підпису_модуля було виправлено.

Якщо буткіт було встановлено шляхом заміни бінарного файлу GRUB на посередника (спостережувана поведінка), простий спосіб відновлення — перемістити Легітимний GRUB від /EFI/ubuntu/grubx64-real.efi до свого початкового маршруту /EFI/ubuntu/grubx64.efi для чого шим запустіть його, і ланцюжок завантаження продовжиться без імплантати.

BCDropper та BCObserver: пов'язані фрагменти чи просто збіг?

Поряд з Bootkitty було знайдено непідписаний модуль ядра під назвою Bootkitty. BCDropper, який має спільні підказки з буткітом: рядки Чорний кіт/чорний кіт у метаданих та шляхах налагодження, а також функція приховування файлів префікси яких містять "інжектор" (відповідно до змінної LD_PRELOAD вказуючи на /opt/injector.so).

BCDropper залишає /opt/спостерігач вбудований ELF (так званий BCSobserver) і запускає його через / bin / bashЦей досить простий компонент чекає gdm3 активний, а потім завантажує модуль ядра з /opt/rootkit_loader.ko використання кінцевий_модуль, обов’язково зробіть це після повного завантаження системи.

Хоча є ознаки взаємозв'язку, неможливо гарантувати, що обидва елементи походять від одного автора або що вони розроблені для спільної роботи. Ситуацію погіршує те, що версія ядра, згадана в його метаданих (6.8.0-48-generic) навіть не входить до списку тих, що підтримуються буткіт.

Пов'язані IoC

Наступні артефакти пов'язані з обговорюваними знахідками. Їхня цінність полягає головним чином Referencia та лабораторія:

BlackLotus та CVE-2022-21894: віха, яка відкрила шлюзи

BlackLotus представлений на ринку з 2022 року за ціною близько 5.000 USD (плюс додаткові послуги за кожне оновлення) та включає методи для обхід захисту від віртуальних машин/налагодження, геозонування, щоб уникнути певних країн (Вірменії, Білорусі, Казахстану, Молдови, Румунії, Росії та України) та, що найважливіше, експлуатація CVE-2022-21894 (Падіння жезла) для обійти безпечне завантаження та досягти надійної роботи на повністю виправлених машинах з Windows 10/11.

Потік, описаний спільнотою безпеки, включає першу фазу з деактивація захисних механізмів операційної системи, використання застарілої вразливості в Secure Boot та реєстрація ключа власника машини контрольований зловмисником. Після подальших перезавантажень імплантат розгортає драйвер ядра та тип компонента користувацького режиму завантажувач керувати зв'язком командування та управління, а також додаткові збори.

Для проактивного захисту спільнота опублікувала операційні правила. Наприклад, SOC Prime пропонує детектори Sigma, які шукають підозріле створення файлів прошивки у System32 несистемними процесами або Деактивація HVCI через реєстрацію. Ці типи сигналів, що відображаються на MITRE ATT&CK (наприклад, T0857, T1562, T1112), допомагають полювання на аномальну активність який зазвичай супроводжує буткіти; також є практичні посібники для Виявлення шкідливих процесів за допомогою Process Explorer у середовищах Windows.

CVE-2024-7344: Завантаження ненадійних бінарних файлів UEFI через "reloader.efi"

Особливо чутливу вразливість було виявлено у 2024 році, CVE-2024-7344, що впливає на кілька пакетів відновлення, підписаних сертифікатом Сертифікат сертифікації UEFI 2011 корпорації MicrosoftКорінь проблеми полягає у використанні користувацький PE-завантажувач у застосунку UEFI reloader.efi, замість безпечних API Завантажити зображення/Почати зображенняБінарний файл розшифровує та виконує вміст файлу. cloak.dat без перевірки підписів відповідно до політики безпечне завантаження.

Вектор поширення не обмежується комп'ютерами з встановленим програмним забезпеченням, оскільки зловмисник з підвищеними привілеями може розгорнути вразливий бінарний файл в ESP (розділ EFI) будь-якої системи, яка довіряє сторонньому центру сертифікації UEFI від Microsoft, і спричинити виконання UEFI не підписано під час запуску. Серед продуктів, на які це вплинуло, були пакети від Howyar, Greenware, Radix, SANFONG, Wasay, CES та Signal Computer, а також виправлено та скасовано 14 січня 2025 року.

Для перевірки захисту en PowerShell з підвищеними привілеями і Linux (LVFS/dbxtool):

# ¿El sistema confía en la UEFI CA 2011 de Microsoft? (posible exposición)
::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Corporation UEFI CA 2011'

# Revocación instalada (64 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'

# Revocación instalada (32 bits)
::ToString((Get-SecureBootUEFI dbx).bytes) -replace '-' -match 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

# Linux (dbxtool)
dbxtool --list | grep 'cdb7c90d3ab8833d5324f5d8516d41fa990b9ca721fe643fffaef9057d9f9e48'
dbxtool --list | grep 'e9e4b5a51f6a5575b9f5bfab1852b0cb2795c66ff4b28135097cba671a5491b9'

Ця справа знову відкриває дискусію щодо ланцюг довіриMicrosoft підтримує два сертифікати, широко поширені на споживчих та корпоративних комп’ютерах UEFI (Windows Production CA 2011 y UEFI CA 2011 для третіх сторін). План полягає в переході на сертифікати 2023, після таких інцидентів, як BlackLotus та поширення вразливих завантажувачів, підписаних роками раніше. На комп'ютерах Захищене ядро, сторонній UEFI CA зазвичай постачається вимкнено за замовчуванням.

Практичний захист та налаштування Secure Boot

Окрім застосування Відкликання UEFI та оновлюйте прошивку/ОС (Служба Microsoft Windows та LVFS), існують заходи, що зменшують поверхню атаки: контроль доступ до ESP з правилами безпеки, налаштуйте безпечне завантаження обмежити довіру тим, що необхідно (дотримуючись таких вказівок, як NSA) та розгорнути атестація за допомогою TPM для дистанційної перевірки стану завантаження порівняно з еталонними значеннями.

У Windows комбінація Безпечне завантаження + Довірене завантаження + ELAM + Виміряне завантаження Він пропонує багаторівневі бар'єри: перевірку завантажувача, перевірку контролерів завантаження перед рештою та запис, підписаний TPM що дозволяє брандмауеру відокремлювати «чисті» комп’ютери від тих, що мають відхилення. У керованих середовищах це зменшує el tiempo de виявлення та стримування.

У Linux, окрім відкликань та контролю ESP, варто стежити за такими сигналами, як LD_PRELOAD в процесі ініціалізації, держава заплямований ядра та співвідносити події завантаження модулів (наприклад, кінцевий_модуль) з незвичайними маршрутами (/opt/*.ko) для виявлення спроб наполегливість рано.

Інструменти, покриття та MITRE ATT&CK

За даними ESET, це єдиний постачальник із 20 найкращих кінцевих точок за доходом, який інтегрує... Сканер прошивки UEFI у своїх рішеннях для захисту обладнання. Хоча інші виробники пропонують технології, пов'язані з UEFI, їхнє призначення не завжди збігається з пряма перевірка прошивкиОскільки атаки UEFI, хоча й спорадичні, надають повний контроль та наполегливість майже абсолютне, інвестування в цей шар може мати вирішальне значення.

Щодо MITRE ATT&CK, спостережувана поведінка відповідає кільком методикам: Завантаження перед ОС: Bootkit (T1542.003), Спільні модулі/LD_PRELOAD (T1129), розвиток Malware (NUMNUMX) і використання сертифікати (T1587.002), Plus Руткіт (T1014), Послаблення захисту (T1562) y Приховати артефакти (T1564) у випадку модулів ядра, які вони ховаються самі.

• T1542.003Буткіт на ESP для збереження до встановлення ОС.
• T1129Попереднє завантаження за допомогою LD_PRELOAD у процесі ініціалізації.
• T1014Модулі ядра з функціональністю руткітів.
• T1562 / T1564Вимкнути перевірки та приховати від системи.

Linux не невразливий: справа Bootkitty та нові імена на радарі

Роками популярна думка протиставляла зростаючу популярність Windows нібито "непроникність" macOS або LinuxРеальність більш тонка: їхня модель та частка роблять їх різними цілями, але не імунними. Поява Буткітті у Linux показує, що знання для створення буткітів також існують для цієї екосистеми, хоча в цьому конкретному випадку ми говоримо про Академічний PoC з обмеженою підтримкою.

Навіть згадувалися варіанти програми-вимагача, ГібридПетя, який би інтегрував можливості буткіту UEFI. Зразки, завантажені до VirusTotal у 2025 році з Польщі свідчать про нещодавній розвиток подій, хоча до них слід ставитися з обережністю. обережність доки не буде незалежного аналізу та надійної атрибуції.

Важливо усвідомити, що захист має охоплювати весь ланцюжок завантаження, мінімізувати довіру за замовчуванням до підписи третіх сторін які не використовуються, моніторити розділ EFI та консолідувати корисна телеметрія (заражене ядро, події модулів, зміни в засобах перевірки GRUB або чутливі змінні UEFI) для своєчасного виявлення.

Поточна картина ризику UEFI поєднує Посвідчення поєднання (PoC) для освітніх цілей, буткіти, що рекламуються як послуга, та вразливості в підписаних компонентах, які, якщо їх вчасно не скасувати, відкривають двері для ненадійне виконання до встановлення ОСПідтримка актуального програмного забезпечення та списків відкликаних програм, зменшення кола довіри та моніторинг ESP – це заходи, які разом ставлять захисників у набагато сильнішу позицію проти цього сімейства загроз.

Пов'язана стаття:

Як захистити Windows за допомогою Credential Guard, BitLocker, AppLocker, Device Guard та WDAC

Ісаак

Пристрасний письменник про світ байтів і технологій загалом. Я люблю ділитися своїми знаннями, пишучи, і саме це я буду робити в цьому блозі, показуватиму вам все найцікавіше про гаджети, програмне забезпечення, апаратне забезпечення, технологічні тренди тощо. Моя мета — допомогти вам орієнтуватися в цифровому світі в простий і цікавий спосіб.