bezpieczny rozruch
| Po angielsku | secure boot |
|---|---|
| Którą formą pisać | obie formy Obie formy są w obiegu. Przy pierwszym wystąpieniu pisz „polski termin (english term)”, dalej sam polski. |
| Inne formy | Secure Boot · UEFI Secure Boot · bezpieczne uruchamianie |
| Kategoria | Złośliwe oprogramowanie |
Bezpieczny rozruch (Secure Boot) to funkcja interfejsu UEFI, która przed załadowaniem sprawdza wszystkie niskopoziomowe składniki oprogramowania układowego i systemu [1]. Podczas startu weryfikuje podpis cyfrowy każdego elementu łańcucha rozruchu: sterowników UEFI, aplikacji EFI, programu rozruchowego i składników systemu operacyjnego [1]. Jeśli podpisy są ważne, maszyna się uruchamia, a firmware przekazuje kontrolę systemowi [1]. Mechanizm ma blokować bootkity i rootkity, które ładują się przed systemem operacyjnym.
Jak działa
Bezpieczny rozruch opiera się na czterech magazynach kluczy i skrótów zapisanych w pamięci nieulotnej płyty głównej [1]. Tabela zestawia ich role według dokumentacji Microsoftu.
| Składnik | Rola |
|---|---|
| PK (klucz platformy) | zaufanie między właścicielem platformy a firmware; pozwala podpisywać zmiany KEK albo wyłączyć mechanizm [1] |
| KEK (klucze wymiany kluczy) | zaufanie między systemem a firmware; podpisuje aktualizacje db i dbx [1] |
| db (baza sygnatur) | zaufani wystawcy i skróty dozwolonych modułów [1] |
| dbx (baza unieważnień) | skróty modułów uznanych za złośliwe lub podatne; ma pierwszeństwo przed db [1] |
Na każdym etapie startu system oblicza skróty kolejnych elementów, porównuje je z wartościami dozwolonymi i nie ładuje tego, co uznano za niezaufane [1]. Każdy klucz kryptograficzny w tym łańcuchu pochodzi od konkretnego wystawcy, więc całość działa jak mała infrastruktura certyfikatów z Microsoftem w roli urzędu certyfikacji (certificate authority).
W Linuksie łańcuch zaczyna się od programu shim. Debian opisuje go jako pierwszy stopień rozruchu: Microsoft podpisuje shim, shim zawiera klucz CA Debiana, a Debian tym kluczem podpisuje GRUB-a i jądro [5]. Dzięki temu dystrybucje same odpowiadają za podpisywanie swoich pakietów, a Microsoft nie musi sprawdzać każdego z nich [5]. Debian obsługuje bezpieczny rozruch od wersji 10 „Buster” [5]. Przy włączonym mechanizmie jądro przechodzi w tryb lockdown [5]. Odmawia wtedy ładowania modułów bez zaufanego podpisu, blokuje kexec z niepodpisanym jądrem, hibernację oraz bezpośredni dostęp procesów użytkownika do pamięci i portów wejścia-wyjścia [5].
Microsoft opisuje też, co sprawdza się na maszynach w chmurze Azure: czy program rozruchowy jest wpisany do bazy db, czy jego podpis jest ważny i czy host startuje z zaufanym oprogramowaniem [1]. Weryfikacja podpisów KEK i PK potwierdza, że definicje zaufanego oprogramowania mogą zmieniać tylko uprawnione podmioty [1].
W WordPressie
Bezpieczny rozruch nie dotyczy samego WordPressa, jego wtyczek ani motywów. Dotyczy maszyny, na której działa serwer strony: fizycznego serwera albo maszyny wirtualnej u dostawcy hostingu. Microsoft podaje, że każda maszyna we flocie obliczeniowej Azure dla obciążeń klientów ma włączony bezpieczny rozruch od etapu produkcji [1]. AWS oferuje UEFI Secure Boot dla instancji EC2: instancja uruchamia tylko oprogramowanie podpisane kluczami zapisanymi w magazynie zmiennych UEFI [6].
Na hostingu współdzielonym za warstwę sprzętu i wirtualizacji odpowiada dostawca, zgodnie z modelem współdzielonej odpowiedzialności (shared responsibility model). Na własnym serwerze VPS z Debianem lub pochodnym systemem stan mechanizmu można sprawdzić poleceniem podanym w dokumentacji Debiana [5].
sudo mokutil --sb-state
Bootkit na serwerze działa poniżej systemu, więc może przetrwać przeinstalowanie aplikacji i ukrywać się przed narzędziami uruchamianymi w systemie. Czyszczenie samych plików WordPressa nie usuwa takiego zagrożenia; zob. czyszczenie przejętej strony.
Ograniczenia
Bezpieczny rozruch chroni tylko przed tym, co nie jest podpisane albo zostało unieważnione. Podpisany, ale podatny program rozruchowy pozostaje zaufany, dopóki jego skrót nie trafi do dbx. Tę lukę wykorzystał BlackLotus: Microsoft załatał podatność CVE-2022-21894 w styczniu 2022 roku, ale podatne, poprawnie podpisane pliki nie zostały dodane do listy unieważnień [3]. Bootkit przynosił więc własne kopie legalnych, podatnych plików [4]. ESET wyjaśnia, że unieważnienie szeroko używanych plików rozruchowych Windows może sprawić, że tysiące starszych systemów przestaną się uruchamiać [3].
Drugim ograniczeniem jest wymóg uprawnień. Według Sekuraka BlackLotus do pierwszego uruchomienia potrzebował uprawnień administratora Windows [4]. Bezpieczny rozruch nie zastępuje więc ochrony przed eskalacją uprawnień, tylko utrudnia utrwalenie się atakującego w najniższej warstwie.
Dobre praktyki
- Utrzymywać włączony bezpieczny rozruch tam, gdzie sprzęt lub platforma wirtualizacji go obsługuje [6].
- Instalować aktualizacje firmware i aktualizacje baz db oraz dbx, bo to nimi dystrybuuje się unieważnienia [1].
- Przed wymianą certyfikatów sprawdzić, czy system i dostawca maszyny wirtualnej obsługują nowe certyfikaty z 2023 roku [2].
- W Linuksie nie wyłączać mechanizmu tylko po to, żeby załadować niepodpisany moduł; Debian przewiduje podpisywanie własnych modułów kluczem właściciela maszyny (MOK) [5].
Historia i przykłady
- Październik 2022. BlackLotus był oferowany na forach przestępczych co najmniej od 6 października 2022 roku za 5000 USD [3].
- 1 marca 2023. ESET opisał BlackLotus jako pierwszy publicznie znany bootkit UEFI, który w praktyce omija bezpieczny rozruch na w pełni zaktualizowanym Windows 11 [3]. Bootkit potrafił wyłączyć m.in. BitLocker, HVCI i Windows Defender [3]. Sekurak omówił odkrycie 2 marca 2023 roku [4].
- 2026. Wygasają certyfikaty Microsoftu z 2011 roku używane przez bezpieczny rozruch: Microsoft Corporation KEK CA 2011 (24 czerwca), Microsoft UEFI CA 2011 (27 czerwca) i Microsoft Windows Production PCA 2011 (19 października) [2]. Zastępują je certyfikaty z 2023 roku [2]. Urządzenia bez nowych certyfikatów działają dalej, ale nie dostaną nowych aktualizacji wczesnego etapu rozruchu, w tym baz bezpiecznego rozruchu i list unieważnień [2].
Przypisy
6- [1] Bezpieczny rozruch oprogramowania układowego — zabezpieczenia platformy Azure · Microsoft Learn
- [2] Wygaśnięcie certyfikatu bezpiecznego rozruchu systemu Windows i aktualizacje urzędu certyfikacji · Microsoft
- [3] BlackLotus UEFI bootkit: Myth confirmed · ESET WeLiveSecurity
- [4] Odkryto prawdopodobnie pierwszy, aktywny w Internecie UEFI bootkit, potrafiący omijać mechanizm UEFI Secure Boot · Sekurak
- [5] SecureBoot · Debian Wiki
- [6] UEFI Secure Boot for Amazon EC2 instances · Amazon Web Services