Mechanizm UEFI Secure Boot od ponad dekady stanowi jedną z najważniejszych technologii chroniących komputery przed bootkitami i innym złośliwym oprogramowaniem działającym jeszcze przed uruchomieniem systemu operacyjnego. Jego zadaniem jest zapewnienie, że podczas startu komputera wykonywany jest wyłącznie kod podpisany przez zaufane podmioty.

Autor: 9 min czytania

Najnowsze badania specjalistów ds. bezpieczeństwa pokazują jednak, że zaufanie do podpisu cyfrowego nie zawsze oznacza bezpieczeństwo. Badacze zidentyfikowali jedenaście podpisanych przez Microsoft historycznych wersji programu shim, które zawierają znane podatności, umożliwiające obejście mechanizmu Secure Boot. Problem dotyczy praktycznie całego ekosystemu komputerów wykorzystujących UEFI i może mieć wpływ zarówno na stacje robocze z Linuksem, jak i wiele środowisk serwerowych oraz narzędzi ratunkowych uruchamianych z nośników USB.

Czym jest UEFI Secure Boot?

Secure Boot został wprowadzony wraz ze specyfikacją UEFI jako następca klasycznego BIOS-u. Mechanizm ma zapobiegać uruchamianiu nieautoryzowanego kodu podczas procesu startowego.

Typowa sekwencja uruchamiania wygląda następująco:

  1. Firmware UEFI inicjalizuje sprzęt.
  2. Weryfikowany jest podpis pierwszego programu EFI.
  3. Uruchamiany jest bootloader.
  4. Bootloader ładuje jądro systemu.
  5. Następuje start systemu operacyjnego.

Każdy kolejny etap musi zostać podpisany kluczem znajdującym się w bazie zaufanych certyfikatów firmware (Secure Boot Database – db). Jeżeli podpis jest nieprawidłowy lub certyfikat został unieważniony, proces uruchamiania zostaje zatrzymany.

Dzięki temu bootkity nie mogą łatwo podmienić bootloadera ani jądra systemu.

Dlaczego Linux korzysta z podpisów Microsoftu?

Większość komputerów sprzedawanych na rynku posiada fabrycznie zapisany certyfikat Microsoft UEFI CA, który umożliwia uruchamianie podpisanych aplikacji EFI.

Dystrybucje Linuksa nie podpisują bezpośrednio własnych bootloaderów tym certyfikatem. Zamiast tego wykorzystują niewielki program pośredniczący o nazwie shim.

Łańcuch zaufania wygląda następująco:

1. UEFI Firmware

2. Microsoft Signed shim

3. GRUB2

4. Linux Kernel

5. System operacyjny

Shim pełni rolę pomostu pomiędzy firmware komputera a właściwym bootloaderem Linuksa. Sam program jest podpisywany przez Microsoft, natomiast późniejsze elementy weryfikowane są już przy użyciu kluczy należących do producenta danej dystrybucji.

To rozwiązanie pozwala praktycznie każdej nowoczesnej dystrybucji działać z aktywnym Secure Boot bez konieczności wyłączania zabezpieczenia.

Na czym polega wykryty problem?

Badacze bezpieczeństwa odkryli jedenaście bardzo starych wersji programu shim (0.9 i wcześniejszych), które mimo podpisania przez Microsoft zawierają błędy umożliwiające obejście mechanizmu Secure Boot. Najgroźniejszy scenariusz zakłada wykorzystanie starego, legalnie podpisanego programu rozruchowego zamiast aktualnej wersji.

Firmware widzi poprawny podpis cyfrowy -> Uruchamia podatny shim -> Shim pozwala uruchomić niezweryfikowany bootloader -> Atakujący przejmuje kontrolę przed startem systemu.

Problem nie polega więc na złamaniu kryptografii ani podrobieniu podpisu Microsoftu. Wykorzystywany jest legalny, ale podatny komponent, nadal uznawany za zaufany przez firmware komputera.

Atak typu BYOVB

Eksperci porównują ten scenariusz do dobrze znanej techniki Bring Your Own Vulnerable Driver (BYOVD), stosowanej w systemie Windows. W tym przypadku mamy do czynienia z analogicznym podejściem – Bring Your Own Vulnerable Bootloader (BYOVB).

Atakujący nie tworzy własnego bootloadera. Zamiast tego wykorzystuje autentyczny komponent podpisany przez Microsoft, zawierający znaną podatność.

Znacznie utrudnia to wykrycie ataku, ponieważ firmware nie ma powodów, aby odrzucić poprawnie podpisany plik EFI.

Dlaczego to takie niebezpieczne?

Kod wykonywany podczas startu komputera działa jeszcze przed uruchomieniem systemu operacyjnego.

Oznacza to, że atakujący może:

  • ominąć mechanizmy ochrony systemu,
  • wyłączyć zabezpieczenia jądra,
  • ukryć własny kod przed systemem EDR,
  • zmodyfikować proces uruchamiania,
  • zainstalować trwałego bootkita,
  • przejąć kontrolę nad systemem, zanim uruchomi się Windows lub Linux.

W praktyce większość narzędzi bezpieczeństwa zaczyna działać dopiero po załadowaniu systemu operacyjnego. Kod wykonany wcześniej pozostaje praktycznie niewidoczny.

Czym jest baza DBX?

UEFI posiada dwie najważniejsze bazy danych:

  • db – lista podpisów uznawanych za zaufane
  • -dbx (Forbidden Signature Database) – lista podpisów oraz hashy, które zostały oficjalnie zablokowane

Jeżeli podatny bootloader zostanie wpisany do DBX, firmware odmówi jego uruchomienia nawet wtedy, gdy posiada prawidłowy podpis Microsoft.

To właśnie aktualizacja DBX stanowi główny sposób eliminacji podobnych zagrożeń.

Dlaczego aktualizacja DBX jest taka ważna?

Wiele organizacji regularnie aktualizuje system operacyjny, lecz zapomina o aktualizacjach firmware UEFI. To poważny problem.

Jeżeli komputer posiada nieaktualną bazę DBX, nadal ufa historycznym komponentom, które zostały już uznane za niebezpieczne. Oznacza to, że nawet nowoczesny system Linux lub Windows może zostać uruchomiony z wykorzystaniem starego, podatnego programu rozruchowego.

Rola SBAT

Po serii wcześniejszych incydentów społeczność Linuksa opracowała mechanizm SBAT (Secure Boot Advanced Targeting).

SBAT dodaje do programu shim dodatkowe metadane, opisujące:

  • producenta,
  • wersję,
  • generację programu,
  • numer wydania.

Pozwala to na blokowanie pojedynczych wersji programu bez konieczności unieważniania całego certyfikatu Microsoft.

Dzięki temu możliwe jest znacznie bardziej precyzyjne wycofywanie podatnych komponentów z użycia.

Czy problem dotyczy tylko Linuksa?

Nie. Choć podatne programy są wykorzystywane głównie przez dystrybucje Linuksa, zaufanie do nich wynika z certyfikatów zapisanych w firmware UEFI. Możliwe jest więc wykorzystanie ich na praktycznie każdym komputerze obsługującym Microsoft UEFI CA, niezależnie od tego, jaki system operacyjny jest zainstalowany.

Zagrożone mogą być również:

  • nośniki ratunkowe,
  • środowiska PXE,
  • instalatory systemów,
  • narzędzia diagnostyczne,
  • obrazy Live USB.

Jak zareagowali producenci?

Microsoft rozpoczął proces dodawania podatnych wersji programu shim do bazy DBX, dzięki czemu firmware będzie automatycznie odrzucał ich uruchomienie po zainstalowaniu odpowiednich aktualizacji. CERT/CC również zalecił producentom sprzętu oraz dystrybucjom Linuksa wycofanie podatnych wersji i wdrożenie zaktualizowanych komponentów rozruchowych.

Jednocześnie Microsoft przypomina, że wygasanie certyfikatu Microsoft UEFI CA 2011 nie oznacza automatycznego zaprzestania działania już podpisanych komponentów. Kluczowe znaczenie ma jednak przygotowanie firmware do korzystania z nowszego certyfikatu UEFI CA 2023 oraz regularne aktualizowanie baz zaufania i unieważnionych podpisów.

Jak administratorzy mogą ograniczyć ryzyko?

Eksperci zalecają przede wszystkim:

  • instalowanie aktualizacji firmware UEFI,
  • aktualizację bazy DBX,
  • korzystanie z najnowszych wersji shim,
  • monitorowanie komunikatów producentów sprzętu,
  • usuwanie starych nośników instalacyjnych, zawierających podatne bootloadery,
  • regularną kontrolę konfiguracji Secure Boot w środowiskach firmowych.

W organizacjach wykorzystujących setki lub tysiące komputerów szczególnie istotne jest zautomatyzowanie procesu dystrybucji aktualizacji firmware oraz okresowa weryfikacja zawartości baz Secure Boot.

Podsumowanie

Opisana podatność pokazuje, że cyfrowy podpis nie gwarantuje bezpieczeństwa przez cały okres życia oprogramowania. Komponent, który w momencie publikacji był w pełni zaufany, po latach może stać się skutecznym narzędziem do omijania mechanizmów ochronnych. W przypadku Secure Boot największym zagrożeniem okazują się nie nowe exploity, lecz historyczne, legalnie podpisane komponenty, które nadal pozostają akceptowane przez firmware milionów komputerów. W związku z tym bezpieczeństwo procesu uruchamiania systemu wymaga nie tylko aktualizacji systemu operacyjnego, ale również regularnego utrzymywania aktualnych baz certyfikatów, list unieważnień (DBX) oraz komponentów rozruchowych. Tylko wtedy łańcuch zaufania, od firmware UEFI aż po jądro systemu, zachowuje swoją integralność i skutecznie chroni przed nowoczesnymi bootkitami.