Ważny podpis przestał oznaczać bezpieczny kod

Secure Boot zrobił dokładnie to, do czego został zbudowany, i na tym polegał problem. 14 lipca firma bezpieczeństwa ESET opublikowała badanie, kierowane przez Martina Smolara, ukazujące jedenaście podpisanych przez Microsoft bootloaderów, wszystkie w wersji 0.9 lub niższej, które maszyna chętnie uruchamia, ponieważ podpis jest prawdziwy. Kod stojący za tym podpisem ma dekadę i jest wadliwy, ale Secure Boot sprawdza podpisującego, a nie bezpieczeństwo tego, co podpisano.

Skutkiem jest napastnik zdolny wykonać niezweryfikowany kod przy rozruchu na niemal każdym komputerze UEFI. ESET zgłosił znalezisko centrum koordynacyjnemu CERT/CC w lutym, a Microsoft dodał wszystkie jedenaście plików do swojej listy wycofań 9 czerwca. Przepaść między zaufanym podpisem a godnym zaufania kodem to cała historia, i sama łatka jej nie zamyka.

Jak działa obejście

Napastnik niczego nie wyłamuje; dostarcza coś, czemu już się ufa. Większość systemów UEFI nosi certyfikat innej firmy Microsoftu, Microsoft Corporation UEFI CA 2011, na swojej liście dozwolonych podpisujących. Napastnik kopiuje jeden ze starych podpisanych bootloaderów na partycję systemową EFI, mały obszar rozruchowy dysku, a oprogramowanie układowe go przyjmuje, ponieważ podpis prowadzi do tego zaufanego certyfikatu. Nie są potrzebne uprawnienia administratora, jedynie możliwość zapisania tego pliku.

Stamtąd trzy stare luki wykonują pracę. Bootloadery ufają przestarzałemu kodowi GRUB 2 z błędem z 2015 roku, który uruchamia niezweryfikowane moduły; wersje poniżej 0.9 nie mają listy wycofań, która zablokowałaby znane złe certyfikaty; a wersje sprzed 15.3 ignorują SBAT, nowszy mechanizm mający wycofywać podatne pliki binarne. Zarejestrowany jako CVE-2026-8863 i CVE-2026-10797 łańcuch kończy się tym, że kod napastnika działa, zanim załaduje się system operacyjny, w idealnym miejscu do ukrycia.

Dlaczego łatka to łatwa część

Wycofanie chroni tylko tę maszynę, która naprawdę je otrzymała. Poprawka Microsoftu z 9 czerwca dodaje jedenaście plików do dbx, listy wykluczeń oprogramowania układowego, a w zarządzanych flotach Windows ta aktualizacja płynie normalnymi kanałami. Haczyk polega na tym, że wiele organizacji celowo wstrzymuje zmiany w liście oprogramowania układowego, ponieważ błędny wpis dbx może pozostawić urządzenie niezdolne do rozruchu, a to ryzyko jest wyższe na starszym lub podwójnie rozruchowym sprzęcie. Wycofanie istnieje; czy dotarło do twoich maszyn, to osobne pytanie.

Głębszy problem to liczenie. Publiczny rejestr przeglądu bootloaderów ruszył dopiero w 2017 roku i nie ma porównywalnej listy tego, co podpisano wcześniej, więc nikt nie potrafi z pewnością powiedzieć, ile starych, wciąż zaufanych bootloaderów krąży. Jedenaście to liczba, którą ESET mógł nazwać, a nie liczba, która istnieje. Zabezpieczenie zależne od znajomości każdego zaufanego podpisującego jest słabe dokładnie tam, gdzie kończy się inwentarz.

Co naprawdę sprawdzić w tym tygodniu

Potraktuj to jako zadanie higieny wycofań, a nie pojedynczą łatkę. Potwierdź, że aktualizacja dbx z 9 czerwca rzeczywiście objęła cały park, zamiast to zakładać; ESET wskazuje narzędzia audytu i sprawdzenia w PowerShell, które raportują bieżący stan wycofań. Rozszerz kontrolę poza Windows, ponieważ serwery Linux i urządzenia otrzymują tę samą poprawkę przez Linux Vendor Firmware Service, a laptopy z podwójnym rozruchem to klasyczny martwy punkt.

Dla europejskich operatorów ramy są teraz zarówno regulacyjne, jak i techniczne. Zgodnie z NIS2 integralność łańcucha rozruchowego wchodzi w zakres środków bezpieczeństwa, które podmiot kluczowy ma wykazać, a bootkit w oprogramowaniu układowym to dokładnie taka trwałość, o którą organ nadzoru zapyta po incydencie. Działanie właściciela łatwo wypowiedzieć i łatwo pominąć: sprawdź, czemu twoje oprogramowanie układowe wciąż ufa, i udowodnij, że blokada dotarła.

Czytaj dalej: 570 poprawek Windows w jeden dzień, dwie już wykorzystywane  |  Osiemnastoletnia luka Cisco ma teraz 3 dni na łatkę