Исследователь словацкой компании ESET Мартин Смоларь обнаружил 11 старых UEFI-приложений, подписанных Microsoft, которые до сих пор считаются доверенными на подавляющем большинстве систем с современной прошивкой. Проблема не в новой дыре в защите — проблема в том, что старая дыра так и не была закрыта до конца. Эти файлы позволяют обойти Secure Boot и выполнить произвольный код ещё до старта операционной системы, а значит — развернуть буткит, который переживёт переустановку Windows или Linux.
Чтобы понять, почему это работает, нужно вспомнить, как вообще Linux грузится на компьютере с включённым Secure Boot. Между прошивкой материнской платы и ядром системы стоит посредник — shim, компактный open-source загрузчик. Прошивка проверяет подпись shim по сертификату Microsoft, зашитому в UEFI. Дальше shim сам проверяет следующий этап — обычно это GRUB 2 — уже по собственному встроенному сертификату вендора. А GRUB 2, в свою очередь, проверяет по тому же сертификату ядро. Цепочка доверия работает только если каждое звено честное.
В центре истории — сертификат "Microsoft Corporation UEFI CA 2011". Именно им годами подписывались сторонние загрузочные компоненты для Secure Boot. Срок его действия истекает 27 июня 2026 года, на смену приходят Microsoft UEFI CA 2023 и Microsoft Option ROM UEFI CA 2023. В ESET отдельно подчеркнули: сам факт истечения срока действия сертификата никак не влияет на проверку Secure Boot, пока подписанные им загрузчики не отозваны по хэшу. А вот это как раз и не произошло — по крайней мере, не для всех.
Список уязвимых shim-загрузчиков, собранных исследователями, выглядит так:
Механика атаки строится на принципе, знакомом по BYOVD ("bring your own vulnerable driver"): злоумышленник не ищет новую уязвимость, а приносит с собой старую, всё ещё доверенную. Через такие устаревшие shim-файлы теоретически можно развернуть уже известные буткиты — Bootkitty, HybridPetya или BlackLotus, — получив контроль над системой ещё до загрузки Windows Defender, антивируса или EDR-решения.
Отдельного внимания заслуживает обход механизма MOK — Machine Owner Key. Это список, позволяющий пользователю Linux вручную разрешить загрузку неподписанных драйверов при включённом Secure Boot. Начиная с версии shim 0.9 в системе появился MOK denylist — список отзыва старых сертификатов, привязанных к уязвимым UEFI-бинарникам, чтобы можно было перейти на пропатченные версии. Атака работает просто: злоумышленник подменяет обновлённый shim жертвы на старый, всё ещё подписанный Microsoft, — и denylist его попросту не видит, потому что allowlist по-прежнему доверяет старому сертификату. Итог — атакующий shim грузит уязвимые бинарники без ограничений и получает исполнение произвольного кода.
Похожим образом обходится и SBAT — Secure Boot Advanced Targeting, механизм, придуманный специально чтобы не городить огромные списки хэшей для отзыва. SBAT работает через понятие минимального допустимого поколения компонента: как только в цепочке загрузки находят уязвимость, эта планка поднимается, и старые версии при попытке загрузиться должны получать ошибку. Но и этот заслон, как показало исследование, можно обойти.
В прошлом месяце CERT Coordination Center выпустил официальное предупреждение по этому поводу. В центре заявили, что специфичные для вендоров загрузчики не обновлялись после того, как уязвимости в основном проекте shim были публично раскрыты и исправлены. Уязвимые загрузчики оставались подписанными и доверенными системами Secure Boot просто потому, что не были отозваны через список отзыва DBX, подписанный Microsoft. По формулировке CERT/CC, это создало долгосрочную брешь в цепочке поставок, позволяющую устаревшим и уязвимым загрузочным компонентам работать даже на полностью пропатченных системах.
Практические последствия очевидны: атакующий с административными привилегиями или возможностью подменить процесс загрузки получает код, выполняемый до старта ОС, устойчивое присутствие, переживающее перезагрузки и в ряде случаев даже переустановку системы, и полную невидимость для средств защиты, которые к моменту запуска буткита ещё не инициализированы. Проблеме присвоены идентификаторы CVE-2026-8863 и CVE-2026-10797 — второй описывает давно исправленную уязвимость в shim, позволявшую обойти механизм отзыва по сертификату через модификацию заголовка подписи второго этапа загрузчика.
В ESET ситуацию описали без обиняков: «Опасность этих старых shim-файлов не в новой уязвимости — новая уязвимость для обхода UEFI Secure Boot вообще не нужна. Атакующему не требуются сложные примитивы эксплуатации: достаточно копии старого, всё ещё доверенного, но не отозванного shim-бинарника и базового понимания того, как работают UEFI shim. Этого хватает, чтобы обойти такую фундаментальную функцию безопасности, как UEFI Secure Boot".
Чтобы понять, почему это работает, нужно вспомнить, как вообще Linux грузится на компьютере с включённым Secure Boot. Между прошивкой материнской платы и ядром системы стоит посредник — shim, компактный open-source загрузчик. Прошивка проверяет подпись shim по сертификату Microsoft, зашитому в UEFI. Дальше shim сам проверяет следующий этап — обычно это GRUB 2 — уже по собственному встроенному сертификату вендора. А GRUB 2, в свою очередь, проверяет по тому же сертификату ядро. Цепочка доверия работает только если каждое звено честное.
В центре истории — сертификат "Microsoft Corporation UEFI CA 2011". Именно им годами подписывались сторонние загрузочные компоненты для Secure Boot. Срок его действия истекает 27 июня 2026 года, на смену приходят Microsoft UEFI CA 2023 и Microsoft Option ROM UEFI CA 2023. В ESET отдельно подчеркнули: сам факт истечения срока действия сертификата никак не влияет на проверку Secure Boot, пока подписанные им загрузчики не отозваны по хэшу. А вот это как раз и не произошло — по крайней мере, не для всех.
Список уязвимых shim-загрузчиков, собранных исследователями, выглядит так:
- []Spyrus — WTGCreator, версия shim 0.7 или ниже
[]RedHat — Red Hat Enterprise Linux 7.2, shim 0.9
[]RedHat — CentOS 7.2, shim 0.9
[]Baramundi software — baramundi Management Suite до 2024R1, shim 0.8
[]WhiteCanyon/Blancco — WipeDrive 8.0.0–8.1.3, shim 0.7
[]Финский совет по матрикуляционным экзаменам — Abitti 1.0, shim 0.8
[]НТЦ ИТ РОСА — ROSA Linux R10 и R9, shim 0.9
[]Oracle America — OracleLinux 7.2, shim 0.9
[]PC-Doctor — PC Doctor Service Center 15 и 16, shim 0.9
[]OpenSuse, shim 0.9
[]OpenSuse Shim 2.1, shim 0.9
Механика атаки строится на принципе, знакомом по BYOVD ("bring your own vulnerable driver"): злоумышленник не ищет новую уязвимость, а приносит с собой старую, всё ещё доверенную. Через такие устаревшие shim-файлы теоретически можно развернуть уже известные буткиты — Bootkitty, HybridPetya или BlackLotus, — получив контроль над системой ещё до загрузки Windows Defender, антивируса или EDR-решения.
Отдельного внимания заслуживает обход механизма MOK — Machine Owner Key. Это список, позволяющий пользователю Linux вручную разрешить загрузку неподписанных драйверов при включённом Secure Boot. Начиная с версии shim 0.9 в системе появился MOK denylist — список отзыва старых сертификатов, привязанных к уязвимым UEFI-бинарникам, чтобы можно было перейти на пропатченные версии. Атака работает просто: злоумышленник подменяет обновлённый shim жертвы на старый, всё ещё подписанный Microsoft, — и denylist его попросту не видит, потому что allowlist по-прежнему доверяет старому сертификату. Итог — атакующий shim грузит уязвимые бинарники без ограничений и получает исполнение произвольного кода.
Похожим образом обходится и SBAT — Secure Boot Advanced Targeting, механизм, придуманный специально чтобы не городить огромные списки хэшей для отзыва. SBAT работает через понятие минимального допустимого поколения компонента: как только в цепочке загрузки находят уязвимость, эта планка поднимается, и старые версии при попытке загрузиться должны получать ошибку. Но и этот заслон, как показало исследование, можно обойти.
В прошлом месяце CERT Coordination Center выпустил официальное предупреждение по этому поводу. В центре заявили, что специфичные для вендоров загрузчики не обновлялись после того, как уязвимости в основном проекте shim были публично раскрыты и исправлены. Уязвимые загрузчики оставались подписанными и доверенными системами Secure Boot просто потому, что не были отозваны через список отзыва DBX, подписанный Microsoft. По формулировке CERT/CC, это создало долгосрочную брешь в цепочке поставок, позволяющую устаревшим и уязвимым загрузочным компонентам работать даже на полностью пропатченных системах.
Практические последствия очевидны: атакующий с административными привилегиями или возможностью подменить процесс загрузки получает код, выполняемый до старта ОС, устойчивое присутствие, переживающее перезагрузки и в ряде случаев даже переустановку системы, и полную невидимость для средств защиты, которые к моменту запуска буткита ещё не инициализированы. Проблеме присвоены идентификаторы CVE-2026-8863 и CVE-2026-10797 — второй описывает давно исправленную уязвимость в shim, позволявшую обойти механизм отзыва по сертификату через модификацию заголовка подписи второго этапа загрузчика.
В ESET ситуацию описали без обиняков: «Опасность этих старых shim-файлов не в новой уязвимости — новая уязвимость для обхода UEFI Secure Boot вообще не нужна. Атакующему не требуются сложные примитивы эксплуатации: достаточно копии старого, всё ещё доверенного, но не отозванного shim-бинарника и базового понимания того, как работают UEFI shim. Этого хватает, чтобы обойти такую фундаментальную функцию безопасности, как UEFI Secure Boot".