Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa ujawnili problem dotyczący 11 historycznych wersji linuxowych bootloaderów typu shim, które mimo upływu lat nadal pozostawały podpisane i akceptowane w łańcuchu zaufania UEFI Secure Boot. Oznacza to, że legalnie podpisany, ale podatny komponent rozruchowy może zostać użyty do uruchomienia nieautoryzowanego kodu jeszcze przed startem systemu operacyjnego.
W praktyce nie chodzi o nowy błąd w samym mechanizmie UEFI, lecz o słabość procesu wycofywania zaufania do starych binariów. To pokazuje, że integralność rozruchu zależy nie tylko od podpisów cyfrowych, ale również od skutecznej revokacji podatnych komponentów.
W skrócie
- Problem dotyczy 11 starych wersji bootloadera shim, głównie 0.9 i starszych.
- Podpisane binaria były nadal akceptowane przez wiele platform korzystających z Microsoft Corporation UEFI CA 2011.
- Atakujący może użyć takiego komponentu do uruchomienia złośliwego kodu we wczesnej fazie bootowania.
- Skutkiem może być obejście Secure Boot, instalacja trwałego bootkita UEFI i ukrycie aktywności przed systemem operacyjnym.
- Microsoft objął wskazane binaria revokacją w aktualizacji DBX z czerwca 2026 roku, ale poziom ochrony zależy od faktycznego wdrożenia tej aktualizacji.
Kontekst / historia
Shim to niewielki pośredni bootloader UEFI, powszechnie wykorzystywany przez dystrybucje Linuksa do pracy z włączonym Secure Boot. Firmware UEFI weryfikuje jego podpis względem zaufanego certyfikatu, a następnie shim sprawdza kolejny etap łańcucha rozruchowego, najczęściej GRUB2, przy użyciu osadzonego certyfikatu dostawcy.
Model ten od lat umożliwia dostawcom korzystanie z ekosystemu Secure Boot bez potrzeby posiadania własnych kluczy OEM. Problem pojawia się wtedy, gdy historyczne i podatne wersje takiego komponentu nadal pozostają zaufane, mimo że nie spełniają już współczesnych wymagań bezpieczeństwa.
Opisany przypadek został przedstawiony jako problem łańcucha dostaw i procesu revokacji. Podatne bootloadery mogły być wykonywane nawet na aktualnych systemach, ponieważ nie zostały odpowiednio wcześnie dopisane do bazy zablokowanych podpisów DBX.
Analiza techniczna
Technicznie atak polega na wykorzystaniu starego, ale nadal zaufanego shima jako legalnego punktu wejścia do uruchomienia dalszych podatnych lub złośliwych elementów rozruchowych. Jeśli platforma ufa podpisowi Microsoft dla zewnętrznych komponentów UEFI, firmware zaakceptuje taki plik podczas startu systemu.
Następnie napastnik może wykorzystać słabości dawnych implementacji mechanizmów revokacji i walidacji, aby załadować nieautoryzowany kod jeszcze przed inicjalizacją jądra. Opisane scenariusze obejmują obchodzenie mechanizmów takich jak MOK denylist oraz SBAT, które normalnie mają ograniczać użycie starych i podatnych komponentów rozruchowych.
Jeśli system nadal akceptuje dawny certyfikat lub konkretne binarium nie zostało skutecznie zablokowane na poziomie DBX, możliwa staje się podmiana aktualnego shima na starszy wariant. Taki model przypomina koncepcję BYOVD, ale przeniesioną do etapu pre-OS: zamiast podatnego sterownika do działającego systemu, atakujący wnosi podpisany, lecz podatny komponent rozruchowy do samego łańcucha bootowania.
Efektem może być uzyskanie egzekucji kodu przed uruchomieniem systemu operacyjnego, co znacząco zwiększa możliwości ukrycia aktywności, utrwalenia obecności oraz obchodzenia mechanizmów obronnych działających dopiero po starcie systemu.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest możliwość obejścia Secure Boot mimo formalnie poprawnej konfiguracji platformy. Organizacja może więc błędnie zakładać, że stacje robocze i serwery są chronione zgodnie z polityką bezpieczeństwa rozruchu, podczas gdy w rzeczywistości pozostają podatne na uruchomienie nieautoryzowanego kodu.
- instalacja trwałych bootkitów UEFI,
- ładowanie niepodpisanych lub złośliwych komponentów jądra,
- obchodzenie narzędzi EDR i mechanizmów telemetrycznych,
- utrzymanie persystencji po restarcie, a niekiedy także po reinstalacji systemu,
- zwiększenie skuteczności ataków na stacje administratorskie, środowiska recovery i nośniki serwisowe.
Warunkiem wykorzystania problemu jest zwykle posiadanie uprawnień administracyjnych albo możliwość modyfikacji procesu rozruchu i zawartości EFI System Partition. Nie jest to zatem prosty wektor masowego ataku, ale w scenariuszach post-exploitation ma bardzo wysoką wartość operacyjną.
Rekomendacje
Organizacje powinny potraktować ten problem jako element hardeningu firmware, zarządzania aktualizacjami rozruchu oraz kontroli zaufanych komponentów UEFI. Samo posiadanie włączonego Secure Boot nie gwarantuje pełnej ochrony, jeśli proces revokacji nie został właściwie wdrożony.
- wdrożyć aktualizacje Microsoft DBX oraz poprawki producentów systemów i sprzętu związane z Secure Boot,
- sprawdzić, czy nośniki recovery, obrazy PXE, narzędzia serwisowe i rozwiązania backupowe nie zawierają historycznych wersji shim,
- przeprowadzić inwentaryzację plików EFI na partycji ESP oraz w obrazach instalacyjnych i serwisowych,
- zweryfikować, czy platformy stosują aktualne polityki revokacji SBAT i DBX,
- ograniczyć możliwość modyfikowania ustawień firmware i partycji ESP do ściśle kontrolowanych ról administracyjnych,
- monitorować podmiany plików EFI, zmiany w NVRAM oraz nietypowe wpisy boot managera,
- testować procedury odzyskiwania po incydencie z uwzględnieniem kompromitacji pre-OS.
W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto dodatkowo rozważyć ograniczenie zaufania do certyfikatów third-party UEFI tam, gdzie jest to operacyjnie możliwe. Szczególną uwagę należy zwrócić na urządzenia korzystające z wielu narzędzi rozruchowych dostawców zewnętrznych.
Podsumowanie
Sprawa 11 starych shimów UEFI pokazuje, że bezpieczeństwo Secure Boot nie kończy się na samym podpisie cyfrowym. Równie ważne jest terminowe wycofywanie zaufania do historycznych binariów oraz kontrola komponentów obecnych na urządzeniu, w firmware i w używanych obrazach serwisowych.
To istotny sygnał dla zespołów bezpieczeństwa, że obrona łańcucha rozruchu musi obejmować nie tylko system operacyjny, ale również DBX, SBAT, partycję ESP oraz cały ekosystem bootowalnych narzędzi. W przeciwnym razie nawet poprawnie skonfigurowane środowisko może pozostawać podatne na ataki w fazie pre-OS.
Źródła
- The Hacker News — https://thehackernews.com/2026/07/11-old-microsoft-signed-linux-uefi.html
- CERT/CC Vulnerability Note VU#616257 — https://www.kb.cert.org/vuls/id/616257
- ESET Research: Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344 — https://www.welivesecurity.com/en/eset-research/under-cloak-uefi-secure-boot-introducing-cve-2024-7344/
- ESET Research: BlackLotus UEFI bootkit: Myth confirmed — https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/