ESET Research opublikował we wtorek 14 lipca analizę 11 starych podpisanych shimów, które przy spełnieniu opisanych w niej warunków zaufania umożliwiają obejście Secure Boot. Według badaczy atakujący może sam przynieść podatny plik, więc sprawdzenie, czy dane narzędzie jest zainstalowane na komputerze, nie rozstrzyga sprawy. Dla osób zarządzających flotą komputerów i odbierających usługi utrzymania to pytanie o to, kto odpowiada za aktualność list unieważnień.

Wyobraź sobie biurowiec, w którym bramka wpuszcza każdego z ważną przepustką. Firma dawno zakończyła współpracę z kilkoma dostawcami, ale ich stare karty nadal otwierają drzwi, bo nikt nie sprawdził, czy trafiły na listę kart zablokowanych. Intruz nie musi przy tym szukać takiej karty w szufladzie konkretnego biura. Wystarczy, że przyniesie ją ze sobą. Tak w uproszczeniu można czytać wnioski z analizy ESET. Secure Boot jest bramką, podpis przepustką, a 11 starych shimów to karty, które według badaczy mogą otworzyć drzwi, jeśli spełnione są opisane warunki zaufania. Pytanie dla zarządu brzmi więc: kto w naszej organizacji prowadzi listę zablokowanych przepustek i skąd wiemy, że obowiązuje na każdym komputerze?

Podpisany shim może przejść kontrolę mimo podatności

Secure Boot opiera się na łańcuchu zaufania, a analiza ESET pokazuje, że podpisany plik może ten łańcuch podważyć. Podpis potwierdza pochodzenie pliku, ale sam w sobie nie mówi, czy wolno mu ufać po latach. ESET opisał 11 starych podpisanych shimów, które przy spełnieniu opisanych w analizie warunków zaufania umożliwiają obejście Secure Boot.

Dla praktyki ważniejsze jest drugie ustalenie. Według ESET Research badany system nie musi mieć oryginalnie zainstalowanego danego narzędzia, ponieważ atakujący może przynieść podatny plik ze sobą. Inwentaryzacja oprogramowania odpowiada zatem na inne pytanie niż to, które stawia ta analiza. Wykaz „czy mamy u siebie to narzędzie” nie mówi, czy komputer zaakceptuje stary podpisany plik dostarczony z zewnątrz.

Szczegółowe warunki zaufania, od których zależy, czy obejście zadziała, opisuje dokument źródłowy. Przed oceną własnej floty trzeba je przeczytać tam, bo streszczenie nie zastąpi porównania z konfiguracją konkretnych komputerów.

Podpis mówi, skąd plik pochodzi. Czy nadal zasługuje na zaufanie, rozstrzyga aktualna lista unieważnień i ktoś, kto za nią odpowiada.

Data analizy nie wyznacza daty poprawki

Analiza ESET ukazała się 14 lipca. Ta data łatwo trafia do notatek i raportów jako początek problemu, a to błąd: publikacja analizy w lipcu nie oznacza, że dopiero wtedy wydano poprawkę lub unieważniono podatne pliki. Daty unieważnień i poprawek dla poszczególnych plików trzeba sprawdzić w analizie źródłowej i potwierdzić u osoby lub dostawcy, którzy utrzymują komputery, razem ze stanem zweryfikowanym na urządzeniach.

Tu zaczyna się rozjazd między papierem a praktyką. Sprawdź własny miesięczny raport z utrzymania stacji roboczych. Czy obok odsetka komputerów z aktualnym systemem i aplikacjami ma osobną pozycję dotyczącą list unieważnień w UEFI? Jeżeli nie ma, organizacja może uważać Secure Boot za działającą kontrolę, choć nikt nie potwierdził, które stare podpisane pliki komputery nadal przyjmują.

Brakuje też danych o nasileniu ataków z użyciem opisanych shimów. To powód do spokojnego przeglądu i do odłożenia paniki. Brak danych o skali nie zwalnia jednak z ustalenia, czy flota odrzuca pliki, o których mowa w analizie.

Lista unieważnień potrzebuje właściciela tak samo jak aplikacja

Aktualność list unieważnień wymaga takiej samej odpowiedzialności jak aktualność aplikacji. Przy aplikacjach pytania są oczywiste: kto instaluje poprawki, w jakim terminie i jak raportuje wynik. Lista unieważnień w UEFI dotyczy powszechnych komputerów, więc zasługuje na te same trzy pytania. Sprawdź, czy wasza umowa utrzymania odpowiada na nie wprost i wskazuje odpowiedzialną osobę.

Ryzyko zarządcze jest konkretne. Podpisany plik może podważyć łańcuch zaufania, na którym opiera się Secure Boot. Jeżeli zarząd przyjmuje w raporcie, że Secure Boot jest włączony, a nikt nie weryfikuje aktualności list unieważnień, raport opisuje samo ustawienie. O faktycznym poziomie ochrony nic z niego nie wynika. Przy odbiorze usługi utrzymania żądajmy więc dowodu stanu na komputerach zamiast deklaracji, że „aktualizacje są wdrażane”.

Odpowiedzialność trzeba też rozdzielić. Dostawca utrzymania może wdrażać aktualizacje, ale decyzja o tym, jaki stan list unieważnień organizacja uznaje za wymagany i kto go odbiera, należy do właściciela floty. Bez tego podziału lekcja z analizy ESET o unieważnieniach i weryfikacji wdrożenia zostanie w skrzynce pocztowej.

Raport o włączonym Secure Boot odbierajmy razem ze sprawdzonym stanem list unieważnień na komputerach.

Polskie firmy nie mają danych, mają za to te same komputery

Dostępne informacje nie wskazują przypadków wykorzystania opisanych shimów w Polsce ani skali problemu w krajowych organizacjach. Mechanizm dotyczy jednak powszechnych komputerów z UEFI, więc polska flota stacji roboczych nie ma powodu uważać się za wyłączoną z tematu.

Źródłem ustaleń jest otwarta analiza ESET Research z 14 lipca. Na dzień publikacji tego tekstu nie znamy jej niezależnego potwierdzenia w mediach. Dla polskiego działu IT to argument za oparciem przeglądu na dokumencie pierwotnym i własnych pomiarach na komputerach. W organizacjach, które powierzają utrzymanie komputerów zewnętrznemu dostawcy, pytanie o listy unieważnień dopiszmy do najbliższego przeglądu usługi.

Co z tym zrobić w poniedziałek

  1. Przeczytaj analizę ESET z osobą odpowiedzialną za flotę. Zapiszcie, które z opisanych warunków zaufania dotyczą waszych komputerów. Czego nie da się ustalić od ręki, oznaczcie jako nieustalone i przypiszcie osobę z terminem odpowiedzi.
  2. Zapytaj dostawcę utrzymania o stan list unieważnień. Poproś o informację, jak sprawdza aktualność list unieważnień w UEFI na komputerach floty i kiedy zrobił to ostatnio. Poproś o wynik odczytany z urządzeń i nie zakładaj, że stan zmienił się dopiero po 14 lipca.
  3. Dopisz listy unieważnień do kryteriów odbioru usługi. W raporcie miesięcznym dodaj osobną pozycję obok aktualności systemu i aplikacji. Wskaż właściciela tej pozycji po stronie organizacji i osobę, która odbiera wynik od dostawcy.

Analiza 11 starych shimów przypomina, że zaufanie oparte na podpisie ma termin ważności, którego ktoś musi pilnować. Organizacja, która rozlicza dostawcę z aktualności aplikacji, a pomija listy unieważnień, zostawia otwartą bramkę, przez którą atakujący może wnieść własny plik. Zamykanie tej luki zaczyna się od decyzji o odpowiedzialności, zanim pojawią się dane o atakach.

Źródła

  1. ESET Research: Forgotten UEFI shims undermining Secure Boot, publikacja: 14 lipca 2026.

Redakcja cyberinsight.pl.