11 podatnych shimów UEFI umożliwia obejście Secure Boot

Wprowadzenie do problemu / definicja

UEFI Secure Boot to mechanizm bezpieczeństwa, którego celem jest dopuszczanie do uruchomienia wyłącznie zaufanych i kryptograficznie podpisanych komponentów rozruchowych. Najnowsze ustalenia badaczy pokazują jednak, że część starszych loaderów typu shim, nadal akceptowanych przez firmware UEFI, może zostać wykorzystana do obejścia tej ochrony.

Problem dotyczy 11 podatnych binariów shim podpisanych certyfikatem Microsoft, które przez lata pozostały w łańcuchu zaufania. W praktyce oznacza to, że napastnik może użyć legalnie podpisanego, lecz przestarzałego komponentu do uruchomienia nieautoryzowanego kodu jeszcze przed startem systemu operacyjnego.

W skrócie

• Badacze zidentyfikowali 11 podatnych shimów UEFI umożliwiających obejście Secure Boot.
• Zagrożenie dotyczy głównie starych wersji shim 0.9 i wcześniejszych.
• Podatne komponenty były podpisane przez Microsoft i nadal mogą być uznawane za zaufane.
• Atakujący może wykorzystać taki loader do uruchomienia niezweryfikowanego kodu na etapie pre-boot.
• Ryzyko obejmuje także systemy, które nigdy wcześniej nie korzystały z konkretnego podatnego shima, ale ufają odpowiedniemu certyfikatowi.

Kontekst / historia

Shim odgrywa ważną rolę w ekosystemie UEFI, szczególnie w środowiskach linuksowych oraz wszędzie tam, gdzie dostawcy chcą zachować zgodność z Secure Boot bez potrzeby ręcznego wgrywania własnych kluczy do firmware. W typowym scenariuszu niewielki loader podpisany przez Microsoft odpowiada za weryfikację kolejnych elementów łańcucha startowego, takich jak GRUB2.

Przez lata projekt shim był rozwijany i wzmacniany o kolejne mechanizmy ochronne, w tym obsługę revocation, list blokad MOK czy podejście oparte na SBAT. Problem polega na tym, że część producentów utrzymywała własne starsze kompilacje lub forki, które mimo znanych słabości pozostały podpisane i akceptowane przez platformy UEFI.

Brak skutecznego i szybkiego wycofania tych binariów z bazy DBX sprawił, że okno nadużycia utrzymywało się przez wiele lat. To klasyczny przykład sytuacji, w której bezpieczeństwo mechanizmu zależy nie tylko od projektu kryptograficznego, ale również od konsekwentnego zarządzania zaufaniem i unieważnieniami.

Analiza techniczna

Atak nie wymaga złamania podpisów cyfrowych ani kompromitacji kluczy. Napastnik wykorzystuje legalnie podpisany, ale podatny shim, który firmware nadal rozpoznaje jako zaufany. Po zaakceptowaniu takiego pliku przez UEFI możliwe staje się uruchomienie kolejnych komponentów rozruchowych w sposób omijający współczesne polityki ochronne.

Opisane scenariusze nadużycia obejmują dwa główne wektory. Pierwszy zakłada użycie starego shima do załadowania kolejnego etapu rozruchu, na przykład podatnego GRUB2, co może otworzyć drogę do uruchomienia zmodyfikowanego lub niepodpisanego kodu. Drugi dotyczy błędów w obsłudze struktur podpisu PE oraz mechanizmów kontroli unieważnień certyfikatów.

Szczególnie istotne jest to, że najstarsze wersje shim nie egzekwują nowoczesnych mechanizmów ochronnych w taki sposób jak nowsze wydania. Dotyczy to między innymi części polityk revocation, wpisów MokListX czy zabezpieczeń opartych na SBAT. W efekcie stary komponent może zignorować nowe zasady bezpieczeństwa, mimo że organizacja wdrożyła je na poziomie systemowym lub firmware.

Z perspektywy operacyjnej problem jest jeszcze poważniejszy, ponieważ podatny shim nie musi pochodzić z oryginalnej instalacji systemu ofiary. Może zostać dostarczony przez napastnika i użyty jako własny, legalnie podpisany element łańcucha rozruchowego. To znacząco rozszerza powierzchnię ataku i przypomina model BYOVD, ale przeniesiony na etap pre-boot.

Konsekwencje / ryzyko

Najgroźniejszym skutkiem jest możliwość wykonania kodu przed uruchomieniem systemu operacyjnego. Taki poziom dostępu pozwala na instalację bootkitów UEFI, obchodzenie mechanizmów ochronnych systemu, ładowanie niepodpisanych komponentów jądra oraz utrzymywanie trwałości po restarcie urządzenia.

W wybranych scenariuszach złośliwa modyfikacja może przetrwać nawet reinstalację systemu, jeśli komponent pozostanie na partycji EFI lub w łańcuchu startowym. Dla zespołów SOC i IR to szczególnie trudny obszar, ponieważ działania wykonywane przed startem systemu są zwykle niewidoczne dla klasycznych narzędzi EDR, AV i standardowego logowania zdarzeń.

Ryzyko jest szczególnie wysokie w środowiskach o podwyższonych wymaganiach bezpieczeństwa, takich jak stacje administracyjne, serwery, systemy przetwarzające dane wrażliwe czy urządzenia terenowe. Tam sama informacja, że Secure Boot jest włączony, nie daje jeszcze pewności, że łańcuch rozruchu rzeczywiście pozostaje odporny na nadużycia.

Rekomendacje

Organizacje powinny potraktować ten problem jako zagadnienie z obszaru firmware security oraz zarządzania łańcuchem zaufania. Skuteczna reakcja wymaga nie tylko aktualizacji systemu, ale również przeglądu komponentów rozruchowych i polityk unieważnień.

• Przeprowadzić inwentaryzację partycji EFI oraz komponentów shim obecnych w środowisku.
• Zweryfikować, które systemy ufają starszym binariom podpisanym certyfikatem Microsoft UEFI CA 2011.
• Wdrożyć najnowsze wersje bootloaderów dostarczane przez producentów systemów i narzędzi rozruchowych.
• Zaktualizować bazę DBX, aby podatne shimy zostały formalnie unieważnione.
• Przetestować kompatybilność zmian przed masowym wdrożeniem, aby uniknąć problemów z uruchamianiem systemów.
• Ograniczyć możliwość modyfikacji partycji EFI, rozruchu z zewnętrznych nośników oraz niekontrolowanego dostępu administracyjnego.
• Rozszerzyć threat hunting o analizę integralności ESP, loaderów UEFI i zmian w łańcuchu startowym.

Warto również potwierdzić, czy środowisko korzysta z nowocześniejszych mechanizmów revocation, takich jak SBAT, oraz czy narzędzia do zarządzania firmware faktycznie dostarczają aktualne polityki DBX. Sam komunikat o aktywnym Secure Boot nie powinien być traktowany jako pełny dowód bezpieczeństwa.

Podsumowanie

Wykrycie 11 podatnych shimów UEFI pokazuje, że nawet dobrze zaprojektowany mechanizm bezpieczeństwa może zostać osłabiony przez stare, nadal zaufane komponenty. W tym przypadku problemem nie jest sama kryptografia, lecz wieloletnie utrzymywanie w łańcuchu zaufania binariów, które powinny zostać wcześniej unieważnione.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona pre-boot musi być traktowana jako integralna część strategii hardeningu. Secure Boot pozostaje ważnym zabezpieczeniem, ale jego skuteczność zależy od aktualności bootloaderów, właściwego zarządzania DBX oraz pełnej widoczności zasobów firmware.

Źródła

1. CERT/CC Vulnerability Note VU#616257
2. Infosecurity Magazine — Eleven Vulnerable UEFI Shims Enable Secure Boot Bypass
3. Help Net Security — No one knows how many old shims can still bypass UEFI Secure Boot
4. GlobeNewswire — ESET Research discovers vulnerable UEFI shims undermining devices’ Secure Boot
5. WeLiveSecurity — Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344