Nowe podatności w firmware: dlaczego aktualizacje BIOS i UEFI stają się krytyczne

Czym jest BIOS i UEFI – fundament bezpieczeństwa sprzętu

Firmware, BIOS, UEFI – o co w ogóle chodzi

Firmware to oprogramowanie zapisane w pamięci nieulotnej urządzenia, które uruchamia się jeszcze przed systemem operacyjnym. Działa na płytach głównych komputerów, kartach sieciowych, kontrolerach RAID, drukarkach, routerach, a nawet w myszkach i klawiaturach. Bez niego sprzęt nie wiedziałby, jak wystartować, skomunikować się z dyskiem czy kartą graficzną.

Kluczowa różnica między firmware a systemem operacyjnym polega na tym, że:

• system operacyjny (Windows, Linux, macOS) ładuje się z dysku/SSD i można go łatwo przeinstalować,
• firmware zapisany jest w pamięci flash na płycie głównej lub urządzeniu i wymaga specjalnego procesu aktualizacji (flashowania).

BIOS (Basic Input/Output System) to klasyczna, starsza forma firmware’u, która inicjuje sprzęt i przekazuje sterowanie systemowi. UEFI (Unified Extensible Firmware Interface) to jego następca – bardziej rozbudowany, z obsługą dużych dysków, graficznego interfejsu, sieci, skryptów, a często także funkcji bezpieczeństwa takich jak Secure Boot.

Mit: „Firmware to coś stałego, fabrycznego, czego się nie rusza”. Rzeczywistość: firmware zawiera błędy, podatności i luki bezpieczeństwa tak samo jak systemy operacyjne i aplikacje. Różnica jest taka, że błędy w firmware są trudniejsze do wykrycia i naprawienia, a skutki ich wykorzystania bywają dużo poważniejsze.

BIOS vs UEFI w realnym świecie użytkownika

W praktyce użytkownik styka się z firmware przy starcie komputera (ekran z logo producenta) oraz w trakcie wchodzenia do ustawień (zwykle klawisze Del, F2, F10, Esc). Różnice odczuje w kilku obszarach.

• BIOS – najczęściej:

• tekstowy, prosty interfejs,
• obsługa starszych trybów startu (MBR, Legacy Boot),
• brak zaawansowanych mechanizmów bezpieczeństwa startu (lub w bardzo szczątkowej formie),
• ograniczenia co do pojemności dysku (przy klasycznym MBR).

• graficzne menu, obsługa myszki, często język polski,
• rozbudowane opcje rozruchu (GPT, Secure Boot, Boot Manager),
• możliwości sieciowe (aktualizacja firmware z internetu, bootowanie po sieci),
• funkcje skryptowe i rozszerzenia (sterowniki UEFI, moduły bezpieczeństwa).

UEFI to w praktyce mini system operacyjny działający przed „właściwym” systemem. Może ładować sterowniki, uruchamiać aplikacje diagnostyczne, łączyć się z siecią, weryfikować podpisy cyfrowe modułów startowych. To duży skok funkcjonalności, ale też ogromny wzrost powierzchni ataku.

Jak sprawdzić, czy korzystasz z BIOS czy UEFI

Szybka diagnostyka nie wymaga specjalistycznej wiedzy. Wystarczą podstawowe narzędzia systemowe.

Windows

• Wciśnij Win + R, wpisz msinfo32 i zatwierdź.
• W oknie „Informacje o systemie” znajdź pozycję Tryb BIOS.
• Zobaczysz wartość typu UEFI lub Starszy (Legacy) / BIOS.

Alternatywnie w PowerShellu możesz użyć:

Get-CimInstance -ClassName Win32_ComputerSystem | Select-Object BootupState

Linux

• Sprawdź istnienie katalogu: ls /sys/firmware/efi
• Jeśli katalog istnieje – system uruchomiony jest w trybie UEFI.
• Jeśli nie – prawdopodobnie korzystasz z tradycyjnego BIOS/Legacy.

Panel startowy

Wielu producentów na pierwszym ekranie startowym wyświetla informacje typu „Press F2 for UEFI settings” albo „Enter BIOS Setup”. Nazewnictwo bywa mylące – często to, co jest nazywane „BIOS Setup”, jest tak naprawdę interfejsem konfiguracyjnym UEFI. Dla bezpieczeństwa kluczowe jest nie tyle słowo na ekranie, co faktyczny tryb pracy (sprawdzony w systemie).

Przykład: mała firma na starym BIOS-ie i nowe laptopy z UEFI

Typowy scenariusz z praktyki wdrożeniowej: w małej firmie działa stary serwer z klasycznym BIOS-em, systemem plików na MBR i brakiem jakichkolwiek mechanizmów typu Secure Boot. Obok trafiają do firmy nowe laptopy z UEFI, TPM i domyślnie włączonym Secure Boot.

Na serwerze nadal funkcjonuje aplikacja księgowa i baza klientów. Nikt nie aktualizuje firmware, bo „działa od lat”. Na laptopach użytkownicy korzystają z bankowości internetowej, poczty, systemów chmurowych. Jeśli padnie ofiarą ataku firmware stary serwer, konsekwencją może być wyciek danych wszystkich klientów. Jeśli zainfekowany zostanie UEFI jednego z nowych laptopów, trudno będzie wykryć, że problem leży poniżej systemu – formatowanie dysku nic nie da.

Ten rozdźwięk technologiczny – stare BIOS-y i nowe UEFI w jednym środowisku – sprawia, że polityka aktualizacji firmware przestaje być „tematem dla fanów sprzętu”, a staje się koniecznością w zarządzaniu ryzykiem IT.

Dlaczego firmware stał się atrakcyjnym celem ataków

Co daje atakującemu przejęcie BIOS/UEFI

Atak na firmware jest dla cyberprzestępcy czymś w rodzaju „złotego graala”. Przejmuje on kontrolę nad komputerem na najniższym możliwym poziomie, jeszcze zanim wystartuje system operacyjny.

• Pełna kontrola nad uruchamianiem systemu – złośliwy kod w UEFI może wstrzykiwać własne moduły do procesu startu, podmieniać bootloader, omijać zabezpieczenia.
• Trwałość – malware zapisany w firmware potrafi przetrwać:

• formatowanie dysków,
• reinstalację systemu operacyjnego,
• zmiany partycji.

• odłączyć TPM od procesu weryfikacji,
• wstrzykiwać zaufane (z punktu widzenia systemu) sterowniki,
• modyfikować struktury pamięci odpowiedzialne za integrację Secure Boot.

Mit: „gdyby ktoś przejął mój BIOS, to komputer przestałby działać i od razu bym zauważył”. Rzeczywistość: profesjonalny atak na firmware stara się być niewidoczny – komputer startuje normalnie, system działa, a różnica polega na tym, że każda czynność jest podsłuchiwana lub modyfikowana.

Trwałość i trudność wykrycia zagrożeń firmware

Malware w firmware działa na podobnej zasadzie jak klasyczne rootkity, ale na niższym, trudniej dostępnym poziomie. Standardowe skanery antywirusowe nie mają uprawnień ani funkcji do analizy i porównywania obrazów UEFI z oryginalnym firmware producenta. Nawet jeśli niektóre produkty security posiadają moduły kontroli integralności UEFI, to:

• często trzeba je osobno włączyć i skonfigurować,
• działają głównie na wybranych platformach i modelach sprzętu,
• nie obejmują całego łańcucha: płyta główna, karty rozszerzeń, kontrolery.

Do tego dochodzi problem aktualizacji BIOS/UEFI – użytkownicy unikają ich z obawy przed „ucegleniem” sprzętu. Cyberprzestępcy doskonale to wykorzystują: podatności w firmware pozostają niezałatane przez lata, nawet jeśli producent dawno wydał poprawkę.

Głośne kampanie i realne przykłady ataków niskopoziomowych

Historia ataków na niskim poziomie zaczęła się szerzej przebijać do mediów przy okazji Stuxneta – sprytnego malware’u atakującego m.in. systemy przemysłowe. Co prawda Stuxnet koncentrował się bardziej na sterownikach PLC i oprogramowaniu sterującym, ale dla wielu ekspertów był sygnałem, że „warstwa poniżej systemu” jest atrakcyjnym celem.

Od tego czasu producenci oprogramowania AV i niezależni badacze regularnie ujawniają kampanie wykorzystujące:

• rootkity UEFI – złośliwe komponenty osadzone w firmware płyty głównej,
• modyfikację bootloaderów obejmujących lub wykorzystujących luki w Secure Boot,
• ataki na Intel ME (Management Engine) lub inne mikro-kontrolery osadzone w sprzęcie.

W wielu przypadkach ofiarami są nie tylko instytucje rządowe czy korporacje, ale także zwykli użytkownicy, którzy stają się częścią infrastruktury do dalszych ataków (botnety, proxy, magazyny danych). Różnica polega jedynie na skali skutków, nie na samej technice ataku.

Skala problemu – jak szybko rośnie liczba podatności w BIOS/UEFI

Trend CVE związanych z firmware – po ludzku

Rejestr podatności CVE (Common Vulnerabilities and Exposures) pokazuje wyraźny trend: z roku na rok przybywa zgłoszeń dotyczących:

• modułów UEFI,
• firmware płyt głównych i laptopów,
• mikrokodu procesorów (microcode update),
• komponentów takich jak Intel ME/AMT, AMD PSP, kontrolery RAID, karty sieciowe.

Nie chodzi o pojedyncze incydenty. Coraz częściej publikowane są całe serie podatności, obejmujące całe rodziny urządzeń. Zdarza się, że jedna luka w kodzie UEFI od konkretnego dostawcy trafia do dziesiątek lub setek modeli płyt różnych producentów, bo korzystają oni z tego samego „klocka” programistycznego.

Rola dużych dostawców: Intel, AMD, OEM-y

Kluczowym elementem układanki jest łańcuch dostaw. Producenci procesorów i chipsetów (Intel, AMD) dostarczają tzw. reference code, czyli fragmenty kodu, które integrują później producenci płyt głównych i OEM-ów (Dell, HP, Lenovo, Asus, itp.) w swoich firmware’ach. Dodatkowo firmy specjalizujące się w firmware (np. AMI, Insyde) dostarczają gotowe implementacje UEFI.

Jeśli na którymś etapie tej układanki pojawi się błąd bezpieczeństwa, potencjalnie zagrożone są:

• setki modeli laptopów i komputerów biurkowych w różnych krajach,
• serwery w centrach danych i chmurach prywatnych,
• urządzenia specjalizowane (terminalne, przemysłowe).

Dla użytkownika końcowego oznacza to tyle, że „błąd w UEFI od producenta X” może jednocześnie dotyczyć jego domowego laptopa, biurowego komputera i serwera w małej firmie – choć wszystkie pochodzą od różnych marek.

Rodziny podatności: BootHole, Intel ME, problemy Secure Boot

W ostatnich latach głośno było o kilku rodzinach podatności w ekosystemie firmware:

• BootHole – luki w sposobie, w jaki bootloader GRUB2 (często wykorzystywany w systemach Linux) współpracował z Secure Boot. Pozwalało to na wstrzyknięcie złośliwego kodu przy zachowaniu pozorów zaufanego rozruchu.
• Błędy w Intel ME/AMT – Management Engine oraz Active Management Technology to wbudowane w platformy Intela mechanizmy zdalnego zarządzania. Błędy w nich potencjalnie umożliwiały zdalne przejęcie kontroli na bardzo niskim poziomie.
• Podatności w implementacjach Secure Boot – błędnie wdrożone listy zaufanych kluczy, brak weryfikacji części łańcucha rozruchowego, możliwość obejścia weryfikacji podpisów.

Te podatności nie były „abstrakcyjnymi problemami akademickimi”. W wielu przypadkach wymusiły szerokie akcje aktualizacji firmware, aktualizacji list podpisów Secure Boot, a czasem nawet wyłączenie określonych funkcji do czasu załatania luk.

Mit: „to tylko problem wielkich korporacji”

Często można usłyszeć, że ataki na firmware to „broń państwowa” i interesują tylko służby specjalne oraz wielkie koncerny. Prawda jest bardziej prozaiczna. Te same podatności występują w:

• laptopach kupionych w sieciowym sklepie RTV,
• komputerach składanych z popularnych płyt głównych,
• serwerach stojących w szafie w małej firmie.

Różnica leży głównie w motywacji atakującego. Duże organizacje bywają celem precyzyjnych, ukierunkowanych ataków. Użytkownicy domowi częściej padają ofiarą masowych kampanii – automatyczne narzędzia skanują internet w poszukiwaniu podatnych urządzeń, niezależnie od tego, czy na komputerze jest „coś cennego”, czy nie.

Jak atakuje się firmware w praktyce – scenariusze i wektory wejścia

Zainfekowany system aktualizuje firmware „oficjalnym” narzędziem

Najbardziej oczywisty scenariusz nie wymaga żadnych „haków” na poziomie sprzętu. Wystarczy, że atakujący przejmie kontrolę nad działającym już systemem operacyjnym – przez phishing, podatną przeglądarkę, dziurawy serwer RDP czy starą wersję oprogramowania. Gdy ma już uprawnienia administratora, sięga po to, z czego korzysta każdy serwis: oficjalne narzędzia do aktualizacji BIOS/UEFI.

Mechanizm jest prosty: złośliwy kod:

• pobiera obraz firmware (lub podszywa się pod proces jego pobierania),
• modyfikuje go w pamięci lub na dysku, dodając swoje moduły,
• uruchamia oficjalne narzędzie producenta płyty głównej / laptopa,
• aktualizuje BIOS/UEFI „zgodnie z procedurą”, tyle że obraz jest już zainfekowany.

Dla użytkownika wszystko wygląda normalnie: okno z logo producenta, pasek postępu, restart. Nie ma żadnych ostrzeżeń, bo narzędzie nie ma pojęcia, że zapisuje zmodyfikowany obraz. Jeśli producent nie zaimplementował kryptograficznej weryfikacji integralności firmware (lub zrobił to powierzchownie), system przyjmuje złośliwą aktualizację jak każdą inną.

Mit w tym miejscu brzmi: „skoro używam oficjalnego programu do aktualizacji, to jestem bezpieczny”. Rzeczywistość jest taka, że bezpieczeństwo zależy od całego łańcucha: od sposobu pobrania obrazu, przez kontrolę jego integralności, aż po zabezpieczenia procesu flashowania.

Wykorzystanie podatnych sterowników trybu kernel

Druga popularna ścieżka to nadużycie sterowników działających w jądrze systemu operacyjnego. Producenci sprzętu często dostarczają sterowniki, które mają dostęp do:

• rejestrów chipsetu,
• mechanizmów programowania SPI flash (gdzie siedzi firmware),
• specjalnych interfejsów zarządzających energią i inicjalizacją platformy.

Jeśli taki sterownik jest podatny, nieprawidłowo weryfikuje parametry wywołań lub pozwala na zbyt szerokie operacje, malware może użyć go jako „tunelu” do zapisu bezpośrednio w pamięci, w której znajduje się BIOS/UEFI. Dla systemu to nadal „legalne działanie podpisanego sterownika”. Problem w tym, że wykorzystywane w zupełnie innym celu niż planował producent.

Takie ataki wielokrotnie opisywali badacze – popularny schemat to:

1. Załadowanie podatnego, ale podpisanego cyfrowo sterownika (często starszej wersji).
2. Wywołanie jego funkcji z odpowiednio spreparowanymi parametrami.
3. Uzyskanie możliwości odczytu/zapisu w obszarze pamięci SPI flash.

To przykład, jak luka w standardowym sterowniku urządzenia, często latami ignorowana, nagle staje się bramą do trwałego przejęcia całej platformy.

Łańcuch dostaw i „fabryczne” infekcje

Firmware można zaatakować zanim komputer trafi na biurko. Nie chodzi tylko o spektakularne operacje służb, ale także o znacznie bardziej przyziemne sytuacje: nieautoryzowany serwis, ingerencje pośredników, a czasem błędy samych producentów.

Przykładowe scenariusze:

• Przejęcie środowiska buildującego firmware u producenta (CI/CD dla BIOS/UEFI) i „wstrzyknięcie” modułu backdoora do obrazu udostępnianego klientom.
• Modyfikacja firmware w nieautoryzowanym serwisie, który zapisuje obraz z niepewnego źródła, np. z forów lub „nieoficjalnych repozytoriów modowanych BIOS-ów”.
• Zastąpienie oryginalnych chipów z firmware w łańcuchu dostaw (np. w hurtowni lub montowni) tańszymi zamiennikami z już zmodyfikowaną zawartością.

Część osób nadal wierzy, że ryzyko „fabrycznej” infekcji dotyczy wyłącznie krajów o niestabilnej sytuacji politycznej. Omyłkowe umieszczenie złośliwego oprogramowania w firmware przez podwykonawcę albo przejęte środowisko developerskie może jednak dotknąć także znane, globalne marki – a użytkownik nie ma praktycznie żadnych szans, by sam to wychwycić.

Ataki fizyczne: dostęp do wnętrza komputera

Bezpośredni dostęp do sprzętu znacząco zwiększa możliwości atakującego. Wbrew temu, co się często powtarza, nie zawsze oznacza to potrzebę „lutowania” czy zaawansowanej elektroniki. W wielu przypadkach wystarcza:

• dostęp do wewnętrznego gniazda programatora (np. SPI header na płycie głównej),
• wyjęcie kości flash i przeprogramowanie jej w zewnętrznym programatorze,
• wykorzystanie serwisowego trybu aktualizacji firmware, który omija część zabezpieczeń.

Takie ataki są typowe w scenariuszach przemysłowych, w małych serwerowniach bez stałej ochrony fizycznej, a także w środowiskach, gdzie sprzęt jest pozostawiany bez nadzoru (sale konferencyjne, komputery „współdzielone”). Z punktu widzenia śledczego późniejsze rozróżnienie, czy modyfikacja została wykonana fizycznie czy z poziomu systemu, bywa bardzo trudne.

Firmware urządzeń peryferyjnych jako wektor pośredni

Bios/UEFI to nie jedyne miejsce, gdzie siedzi firmware zdolny do wyrządzenia szkód. Coraz częściej analizowane są:

• kontrolery dysków SSD i HDD,
• karty sieciowe,
• kontrolery Thunderbolt/USB-C,
• zewnętrzne stacje dokujące, KVM-y, inteligentne zasilacze.

Część z tych urządzeń ładuje swój firmware podczas startu systemu lub w czasie działania, korzystając z mechanizmów udostępnianych przez UEFI. Jeśli uda się zainfekować taki komponent, może on:

• podsłuchiwać ruch sieciowy niezależnie od systemu operacyjnego,
• podszywać się pod klawiaturę/mysz i wstrzykiwać komendy,
• modyfikować dane na dysku „pod spodem”, zanim system je zobaczy.

Mit brzmi: „zasilacz czy stacja dokująca są pasywne”. W praktyce wiele z tych urządzeń posiada własne procesory i pamięć flash, a ich firmware rzadko jest aktualizowany i prawie nigdy nie jest monitorowany.

Konsekwencje zignorowania aktualizacji firmware – techniczne i biznesowe

Ryzyko techniczne: od drobnych anomalii po pełne przejęcie systemu

Nieuaktualniony BIOS/UEFI to nie tylko egzotyczne ryzyko „wywiadowcze”. W praktyce brak aktualizacji może oznaczać:

• łatwiejszą eskalację uprawnień – podatności w UEFI mogą umożliwiać przejście z poziomu zwykłego użytkownika na pełnego administratora, omijając mechanizmy systemowe,
• brak możliwości wiarygodnego rozruchu – dziury w Secure Boot skutkują tym, że system nie może ufać własnemu procesowi startu,
• stabilność na granicy przypadku – poprawki w mikrokodzie procesora często usuwają błędy objawiające się rzadkimi zawieszkami czy nieoczywistymi błędami pamięci.

Część administratorów przyzwyczaiła się traktować „losowe bluescreeny” czy sporadyczne restarty jako „urok konkretnego modelu laptopa”. Tymczasem nowszy firmware bywa jedynym realnym rozwiązaniem – zwłaszcza gdy aktualizacja mikrokodu procesora łata błąd wykrywany dopiero w specyficznych obciążeniach.

Uderzenie w zaufanie do całego środowiska

Z perspektywy bezpieczeństwa najgroźniejszy aspekt infekcji firmware polega na tym, że unieważnia zaufanie do całej platformy. Jeśli istnieje uzasadnione podejrzenie, że BIOS/UEFI został zmodyfikowany, pojawiają się pytania:

• czy można ufać logom systemowym,
• czy narzędzia forensyczne widzą pełen obraz,
• czy mechanizmy szyfrowania dysków bazujące na TPM działają zgodnie z założeniami.

W skrajnych przypadkach jedynym sensownym krokiem jest całkowita wymiana sprzętu lub fizyczne przeprogramowanie kości z wykorzystaniem zaufanego obrazu. To kosztuje i przestoje, ale też wymaga kompetencji, których często brakuje w mniejszych organizacjach.

Konsekwencje biznesowe: przestoje, kary, utrata danych

Ignorowanie aktualizacji firmware często wydaje się oszczędnością czasu. Do momentu, gdy:

• dochodzi do incydentu ransomware, który wykorzystuje podatności w UEFI do utrzymania się w środowisku mimo „udanej” reinstalacji systemów,
• wdrożenie nowego systemu szyfrowania dysków lub platformy do zdalnego zarządzania nie działa poprawnie przez stary BIOS na setkach laptopów,
• audyt bezpieczeństwa lub klient z branży regulowanej pyta o politykę aktualizacji firmware – i nie ma co pokazać.

W sektorach objętych regulacjami (finanse, zdrowie, energetyka) zaniedbania w obszarze aktualizacji mogą zostać zakwalifikowane jako brak „należytej staranności”. Konsekwencją bywają nie tylko kary finansowe, ale także utrata kontraktów czy certyfikacji wymaganych do prowadzenia działalności.

SCADA, OT i urządzenia specjalistyczne

Szczególnie wrażliwą kategorią są systemy przemysłowe (OT/SCADA), urządzenia medyczne i rozwiązania specjalistyczne, które działają latami na niezmienianej platformie sprzętowej. Tam argument „działa, nie ruszać” jest normą.

Nieuaktualnione firmware w tego typu środowiskach skutkuje m.in.:

• niewidocznymi dla operatorów zmianami konfiguracji lub parametrów pracy,
• możliwością trwałego uszkodzenia sprzętu (np. przez zmianę krzywych sterowania),
• brakiem zgodności z nowszymi systemami monitoringu i bezpieczeństwa.

Mit, że „system przemysłowy jest odizolowany i bezpieczny”, już wielokrotnie został obalony. Nawet częściowo odseparowane sieci OT mają punkty styku z IT, a stare firmware to idealny punkt zaczepienia dla atakującego, który raz się tam dostanie.

Jak sprawdzić wersję BIOS/UEFI i dostępność aktualizacji

Identyfikacja platformy: model płyty, laptopa, wersja firmware

Zanim cokolwiek się zaktualizuje, trzeba wiedzieć, co w ogóle jest zainstalowane. Pierwszy krok to identyfikacja:

• modelu urządzenia (laptop, komputer biurkowy, serwer),
• producenta i modelu płyty głównej,
• aktualnej wersji BIOS/UEFI.

Najprostsze metody:

• Ekran startowy – podczas uruchamiania komputera często wyświetlana jest wersja BIOS/UEFI w dolnej części ekranu (np. „BIOS Version F.23”).
• Menu UEFI – po wejściu do ustawień (zwykle klawisz Del, F2, F10, F12) w sekcji „Main” lub „Information” widoczna jest wersja firmware.
• System operacyjny – w Windows: wmic bios get smbiosbiosversion, releasedate lub w PowerShellu: Get-CimInstance -ClassName Win32_BIOS.
• W systemach Linux: sudo dmidecode -t bios albo informacje w /sys/firmware/efi w przypadku UEFI.

Te informacje trzeba zanotować lub zebrać automatycznie (w środowiskach firmowych) – przydadzą się przy porównywaniu z wersjami dostępnymi na stronach producentów.

Źródła aktualizacji: gdzie szukać oficjalnych obrazów

Bezpieczeństwo aktualizacji zaczyna się od źródła pliku. Obraz firmware powinien pochodzić tylko z:

• oficjalnej strony producenta sprzętu (OEM – Dell, HP, Lenovo, itd.),
• strony producenta płyty głównej w komputerach składanych,
• platformy zarządzania serwerami (np. iDRAC, iLO, IPMI) w środowiskach serwerowych.

Od czasu do czasu pojawia się pokusa wykorzystania „modowanych BIOS-ów”, które odblokowują ukryte opcje albo podnoszą limity. Z perspektywy bezpieczeństwa to ruletka: nie ma możliwości zweryfikowania, czy poza dodatkowymi parametrami ktoś nie dodał także backdoora.

W środowiskach korporacyjnych producenci oferują często centralne repozytoria aktualizacji firmware (katalogi offline, obrazy CAB, integracje z narzędziami typu SCCM). Tam również obowiązuje ta sama zasada – pliki powinny być podpisane i pobrane przez kanał umożliwiający weryfikację ich integralności (HTTPS, podpisy cyfrowe).

Weryfikacja wersji i changelogów

Po znalezieniu aktualizacji trzeba sprawdzić, czy faktycznie jest nowsza od zainstalowanej i jakie problemy rozwiązuje. Nie każdy producent wyraża się jasno w changelogach, ale typowe wpisy to:

• „Improved system stability” – często w praktyce oznacza poprawki błędów mikrokodu procesora lub obsługi pamięci.
• „Security updates” – ogólnik, za którym mogą stać konkretne CVE, nie zawsze wymienione z nazwy.
• „Update Intel ME firmware” lub podobne – wskazuje na aktualizację komponentów zarządzających platformą.

Automatyzacja sprawdzania wersji w środowiskach firmowych

Ręczne sprawdzanie wersji BIOS/UEFI ma sens na kilku komputerach, ale nie w sieci z setkami czy tysiącami urządzeń. Tam potrzebne są dane zebrane centralnie. Typowe podejścia to:

• rozszerzenie istniejącego inwentaryzatora – systemy klasy MDM, EDR, SCCM/XM, Ansible czy Salt potrafią zebrać informacje z wmic, PowerShella lub dmidecode i wysłać je do bazy,
• skrypty logon/startup – prosty skrypt PowerShell/Bash zapisujący wersję BIOS/UEFI i model urządzenia do centralnego logu lub API,
• funkcje producenta – Dell Command | Monitor, HP Image Assistant, Lenovo System Update CLI potrafią raportować do centralnych narzędzi, jakie wersje firmware są obecne.

Mit w IT brzmi: „nie mamy problemu z firmware, bo nikt nie zgłasza usterek”. Rzeczywistość jest taka, że bez inwentaryzacji nie wiadomo nawet, ile urządzeń ma BIOS sprzed pięciu czy dziesięciu lat. Dopiero zestawienie model–wersja–data wydania pokazuje realną skalę długu technicznego.

Mapowanie wersji na podatności

Sam numer wersji niewiele mówi, dopóki nie zostanie powiązany z informacjami o podatnościach. W praktyce proces wygląda tak:

• zestawienie listy modeli i wersji BIOS/UEFI z inwentaryzatora,
• sprawdzenie biuletynów bezpieczeństwa producenta sprzętu (security advisory),
• odszukanie powiązanych identyfikatorów CVE i minimalnych wersji firmware, które je łatają,
• oznaczenie urządzeń „poniżej bezpiecznej wersji” jako priorytetowych do aktualizacji.

Część producentów publikuje matryce typu „model – podatność – wersja naprawcza”, inni ograniczają się do lakonicznego „security fixes”. Wtedy pomagają niezależne bazy i raporty (np. z CERT-ów, projektów eksplorujących firmware), które przypisują konkretne CVE do zakresów wersji.

W większych środowiskach taki mapping warto utrzymywać w CMDB lub arkuszu kontrolnym i aktualizować przy każdej nowej publikacji producenta. Ciągłe poleganie na ręcznym „szukaniu po Google” kończy się pominięciem części podatności.

Ocena krytyczności: nie każda aktualizacja jest „na już”

Aktualizacje firmware często kojarzą się z operacją wysokiego ryzyka, więc część zespołów reaguje alergicznie na każde „jest nowy BIOS”. Pomaga sensowna klasyfikacja. Przydatny podział to m.in.:

• poprawki krytycznych podatności z możliwością zdalnego ataku – np. luki w Intel ME/AMT, BMC lub modułach sieciowych,
• luki umożliwiające trwałą eskalację z poziomu systemu – wymagają dostępu lokalnego lub złośliwego sterownika, ale pozwalają „zakotwiczyć się” w firmware,
• aktualizacje stabilności i kompatybilności – usuwają problemy z losowymi restartami, obsługą nowszych pamięci, kart, urządzeń.

Dla pierwszej kategorii priorytet powinien być porównywalny z krytycznymi łatami systemów operacyjnych. Druga kategoria jest kluczowa w środowiskach o podwyższonym ryzyku (admini, systemy wrażliwe, stacje inżynierskie). Trzecia – może zostać zaplanowana w regularnych oknach serwisowych, ale odkładanie jej „na zawsze” kumuluje problemy, które później objawiają się jako trudne do diagnozy awarie.

Przygotowanie do aktualizacji BIOS/UEFI – minimalizacja ryzyka

Ocena ryzyka i wybór strategii wdrożenia

Aktualizacja firmware nie jest operacją zero-jedynkową. Zanim zostanie uruchomiony pierwszy instalator, trzeba ustalić zasady:

• gdzie testujemy – wybór reprezentatywnej grupy urządzeń (różne modele, różne roczniki) do pilotażu,
• jakie są scenariusze awaryjne – co robimy przy nieudanym flashu: recovery przez UEFI, zewnętrzny programator, wymiana płyty,
• jakie są okna serwisowe – czy aktualizujemy tylko poza godzinami pracy, czy dopuszczamy restart w trakcie (np. dla maszyn VDI),
• jak informujemy użytkowników – komunikat przed, po, prosta instrukcja „nie wyłączaj zasilania, nie zamykaj pokrywy”.

Przekonanie, że „BIOS aktualizuje się raz na cały sprzęt i po sprawie”, zwykle pada przy pierwszej większej kampanii. W praktyce proces jest cykliczny, a dobra strategia wdrożenia ratuje przed chaosem przy każdej nowej luce.

Wymagania zasilania i środowiska

Najprostsze błędy podczas aktualizacji wynikają z ignorowania banałów. Kilka zasad minimalizujących ryzyko „uceglenia” sprzętu:

• stałe zasilanie – komputery stacjonarne na UPS-ie, laptopy z podłączonym zasilaczem i naładowaną baterią (część instalatorów wręcz odmawia startu, jeśli poziom naładowania jest zbyt niski),
• stabilne środowisko pracy – unikanie aktualizacji w miejscach o wysokiej temperaturze, wibracjach, niestabilnym zasilaniu,
• odłączenie zbędnych urządzeń – dyski USB, adaptery, stacje dokujące, które potrafią wprowadzać zamieszanie w proces wykrywania nośników lub w sekwencji rozruchu po aktualizacji.

W przypadku serwerów dodatkowo liczy się korelacja z zasilaniem w szafie i w całej serwerowni – aktualizacja kilku krytycznych hostów na raz w czasie przewidywanych prac energetycznych to proszenie się o kłopoty.

Kopia zapasowa konfiguracji i dokumentacja ustawień

Aktualizacja BIOS/UEFI potrafi:

• przywrócić część ustawień do wartości domyślnych,
• zmienić sposób prezentacji niektórych opcji,
• dodać nowe parametry, które wpływają na bezpieczeństwo (np. nowe tryby Secure Boot, kontrola interfejsów peryferyjnych).

Dlatego przed aktualizacją warto zrzucić konfigurację. Niektórzy producenci oferują:

• eksport ustawień UEFI do pliku (np. w formie tekstowej lub binarnej),
• profile konfiguracyjne możliwe do zastosowania z pendrive’a lub z poziomu narzędzi zarządzających,
• komendy CLI do pobrania bieżącej konfiguracji (częste w serwerach).

Jeśli takiej funkcji brakuje, pozostaje manualna dokumentacja: zdjęcia ekranu, arkusz z kluczowymi ustawieniami (tryb SATA, kolejność rozruchu, konfiguracja Secure Boot, VT-x/AMD-V, IOMMU, TPM). To mało efektowna praca, ale złe wartości po aktualizacji potrafią zablokować rozruch systemu, szyfrowanie dysku lub integrację z systemami zarządzania.

Zabezpieczenie danych i scenariusz powrotu

Aktualizacja BIOS/UEFI z definicji nie powinna ruszać danych na dyskach, ale błędy się zdarzają: znikające wpisy w tablicy partycji, zmieniony tryb kontrolera, z którym system nie potrafi wystartować, uszkodzony bootloader. Rozsądne minimum przed masową kampanią obejmuje:

• sprawdzenie, czy działają standardowe mechanizmy backupu i można szybko odzyskać krytyczne systemy,
• przetestowanie odtworzenia jednej–dwóch maszyn po symulowanym „bricku” sprzętu (wirtualizacja lub sprzęt zastępczy),
• ustanowienie kanału eskalacji – kto decyduje o wymianie sprzętu, jeśli proces recovery firmware się nie powiedzie.

Mit „BIOS jest poza dyskiem, więc dane są bezpieczne” brzmi dobrze tylko na papierze. Każda operacja, która może unieruchomić platformę startową, pośrednio wpływa na dostępność danych – nawet, jeśli nie narusza ich integralności.

Dobór narzędzia aktualizacyjnego

Ten sam obraz firmware może być instalowany kilkoma metodami. Wybór narzędzia ma znaczenie dla stabilności i możliwości automatyzacji:

• aktualizacja z poziomu UEFI – wbudowane moduły typu „EZ Flash”, „M-Flash”, „Q-Flash”: proste, mało zależnych warstw, dobre do pojedynczych maszyn i serwerów poza domeną,
• instalatory systemowe – pliki EXE/MSI (Windows) lub narzędzia CLI (Linux) od OEM-ów: wygodne w korporacjach, dają możliwość orkiestracji, ale zależą od sterowników i stanu systemu operacyjnego,
• narzędzia zarządzania out-of-band – BMC/iDRAC/iLO, Intel AMT/ME: aktualizacja zdalna, często bez potrzeby wchodzenia w system, kluczowa dla serwerów i urządzeń w trudno dostępnych lokalizacjach,
• nośniki rozruchowe – bootowalne pendrive’y z minimalnym systemem i flasherem: opcja ratunkowa lub standard przy starszych platformach.

W środowiskach mieszanych (różni producenci, różne generacje) kończy się zwykle na kombinacji tych metod. Zwyczaj „jedno narzędzie do wszystkiego” nie wytrzymuje zderzenia z praktyką – lepiej świadomie dobrać minimum dwóch–trzech sprawdzonych sposobów i opisać je w procedurach.

Testy pilotażowe i obserwacja po aktualizacji

Przed masowym wdrożeniem jedna z grup maszyn powinna pełnić rolę „kanarka w kopalni”. Typowy scenariusz pilotażu to:

1. wybór kilku–kilkunastu urządzeń na model/rodzinę,
2. aktualizacja przy udziale doświadczonego administratora,
3. obserwacja przez kilka dni: logi systemowe, stabilność, zachowanie przy zimnym starcie, współpraca z EDR/antywirusami i narzędziami szyfrującymi.

Jeżeli pojawiają się anomalia (wydłużony czas POST, błędy sterowników chipsetu, problemy z TPM lub Secure Boot), aktualizację dla reszty floty lepiej zatrzymać i przeanalizować konflikt. W praktyce często wymaga to dodatkowych łatek sterowników lub aktualizacji systemu – firmware bywa tylko pierwszym elementem łańcucha.

Specyfika środowisk z pełnym szyfrowaniem dysków

Systemy z FDE (BitLocker, LUKS, rozwiązania komercyjne) są szczególnie wrażliwe na zmiany w firmware. Typowe problemy po aktualizacji to:

• przejście mechanizmu szyfrowania w tryb „recovery” z powodu zmiany kluczy TPM lub ustawień Secure Boot,
• konieczność ponownego zatwierdzenia konfiguracji TPM w UEFI (np. fizyczna akceptacja zmiany),
• niekompatybilne tryby rozruchu (Legacy vs UEFI) powodujące brak możliwości startu z zaszyfrowanego dysku.

Przed aktualizacją trzeba sprawdzić, jak dany produkt szyfrujący reaguje na zmiany w firmware oraz czy są zalecane konkretne procedury (np. czasowe wyłączenie ochrony, zapisanie kluczy awaryjnych, aktualizacja agenta przed firmware). Ignorowanie tej specyfiki kończy się lawiną zgłoszeń: „po restarcie żąda ode mnie jakiegoś dziwnego klucza”.

Rola polityk bezpieczeństwa i procedur operacyjnych

Firmware często wypada poza radar formalnych polityk – są zasady łatania systemów, są wytyczne dla aplikacji, ale BIOS/UEFI żyje w szarej strefie. To ułatwia odkładanie decyzji w nieskończoność. Żeby wyjść z tego stanu, w dokumentacji bezpieczeństwa powinny się pojawić m.in.:

• definicja odpowiedzialności – kto decyduje o aktualizacji firmware (IT, bezpieczeństwo, właściciele systemów),
• progi czasowe – w jakim czasie od publikacji krytycznej poprawki firmware musi zostać wdrożony dla określonych klas urządzeń,
• zasady klasyfikacji – jak rozróżniane są aktualizacje krytyczne, ważne, rutynowe,
• procedura awaryjna – co się dzieje przy nieudanej aktualizacji: tryb pracy na sprzęcie zastępczym, czas na diagnozę, decyzja o wymianie.

Mit brzmi: „spiszemy procedurę, to będzie porządek”. Bez realnej, cyklicznej praktyki (np. kwartalne przeglądy wersji firmware, przegląd biuletynów OEM) dokument pozostaje papierową tarczą – dobrze wygląda na audycie, ale nie zatrzymuje żadnego realnego ataku.

Komunikacja z użytkownikami końcowymi

Ostatni, często ignorowany element to ludzie, którzy faktycznie korzystają z urządzeń. Nawet najlepiej zaplanowana kampania potknie się, jeśli użytkownicy w połowie procesu:

• zamkną pokrywę laptopa, bo „za długo się restartuje”,
• odłączą zasilacz, gdy zobaczą kilka „dziwnych” restartów z logo producenta,
• zresetują maszynę „na twardo”, bo ekran stoi na 70% postępu.

Pomaga kilka prostych elementów:

• krótki komunikat w języku zwykłego użytkownika, co się będzie działo i jak długo może potrwać,
• jasne polecenia: nie wyłączać zasilania, nie zamykać pokrywy, cierpliwie czekać do pełnego startu systemu,
• kanał zgłoszeń „po aktualizacji” – specjalna kategoria w Service Desk, żeby problemy nie mieszały się z innymi incydentami.

Najczęściej zadawane pytania (FAQ)

Czy naprawdę muszę aktualizować BIOS/UEFI, skoro komputer działa poprawnie?

Mit mówi: „jak działa, to nie ruszaj”. Rzeczywistość jest taka, że w BIOS/UEFI regularnie odkrywane są luki bezpieczeństwa, które pozwalają przejąć kontrolę nad komputerem jeszcze przed startem systemu. Jeśli producent wypuszcza poprawki firmware’u, to bardzo często właśnie po to, by załatać krytyczne podatności – nie tylko „dodać obsługę nowego procesora”.

Brak aktualizacji przez lata oznacza, że korzystasz z urządzenia z dziurami znanymi przestępcom i szczegółowo opisanymi w raportach bezpieczeństwa. Przy zwykłym oprogramowaniu pomaga formatowanie lub reinstalacja. Przy zainfekowanym firmware – nie. Dlatego w środowisku firmowym polityka aktualizacji BIOS/UEFI staje się elementem zarządzania ryzykiem, a nie „fanaberią admina”.

Jak sprawdzić, czy mam BIOS czy UEFI w swoim komputerze?

W Windows wciśnij Win + R, wpisz msinfo32 i potwierdź. W oknie „Informacje o systemie” znajdź pozycję „Tryb BIOS”. Jeśli widzisz UEFI, pracujesz w nowym trybie. Jeśli widnieje Starszy (Legacy) lub BIOS, system startuje w starym, klasycznym trybie.

W Linuksie otwórz terminal i użyj komendy ls /sys/firmware/efi. Jeśli katalog istnieje, system został uruchomiony w trybie UEFI. Jeśli go nie ma, najpewniej korzystasz z BIOS/Legacy. Ekran startowy z napisem „Enter BIOS Setup” bywa mylący – wielu producentów dalej używa słowa „BIOS” dla interfejsu, który faktycznie jest UEFI.

Czy malware w BIOS/UEFI można usunąć formatowaniem dysku lub reinstalacją systemu?

Nie. Zainfekowane firmware działa poniżej systemu operacyjnego. System możesz przeinstalować, dysk możesz wyczyścić do zera – złośliwy kod w pamięci flash płyty głównej nadal będzie się uruchamiał przy każdym starcie komputera. To właśnie czyni ataki na BIOS/UEFI tak atrakcyjnymi z perspektywy przestępców.

Usunięcie tego typu infekcji zwykle wymaga:

• ponownego wgrania (flashowania) oryginalnego obrazu BIOS/UEFI,
• lub w skrajnym przypadku – interwencji serwisu z programatorem sprzętowym.

Mit, że „w razie czego po prostu przeinstaluję Windowsa i będzie po problemie”, w przypadku firmware jest zwyczajnie fałszywy.

Jak bezpiecznie zaktualizować BIOS/UEFI, żeby nie „uceglić” komputera?

Najważniejsza zasada: aktualizuj tylko z oficjalnych źródeł i zgodnie z instrukcją producenta płyty głównej lub laptopa. Zwykle wygląda to tak, że pobierasz konkretną wersję firmware dla swojego modelu, kopiujesz ją na pendrive i uruchamiasz wbudowane narzędzie aktualizacji (w menu UEFI lub z poziomu systemu, jeśli producent udostępnia aplikację).

Kilka praktycznych kroków:

• sprawdź dokładnie model płyty/laptopa i numer wersji BIOS/UEFI,
• podłącz zasilacz (w laptopach) i nie przerywaj procesu aktualizacji,
• wyłącz „ulepszacze” typu overclocking na czas aktualizacji,
• w środowisku firmowym – przetestuj najpierw aktualizację na 1–2 identycznych maszynach.

Ryzyko „uceglenia” jest dziś dużo mniejsze niż kiedyś, bo wielu producentów stosuje podwójne kości BIOS (Dual BIOS) lub mechanizmy awaryjnego odzyskiwania. O wiele realniejszym problemem jest latami niełatanne, dziurawe firmware.

Czym różni się bezpieczeństwo BIOS od UEFI? Czy UEFI jest bezpieczniejsze?

UEFI ma wbudowane mechanizmy, których klasyczny BIOS po prostu nie posiadał. Przykładami są Secure Boot, obsługa podpisów cyfrowych modułów startowych, lepsza współpraca z TPM oraz możliwość bardziej rozbudowanej kontroli integralności łańcucha rozruchu. Z tego powodu, przy poprawnej konfiguracji, UEFI daje większy potencjał bezpieczeństwa niż stary BIOS.

Z drugiej strony UEFI jest znacznie bardziej złożone – to w praktyce mini system operacyjny: obsługuje sieć, skrypty, sterowniki. Więcej funkcji to też większa powierzchnia ataku. Różnica nie polega więc na tym, że „UEFI jest z natury bezpieczne”, ale na tym, że:

• BIOS ma mniej funkcji, ale praktycznie żadnych nowoczesnych zabezpieczeń startu,
• UEFI ma więcej zabezpieczeń, ale wymaga aktualizacji i poprawnej konfiguracji (np. włączony i sensownie ustawiony Secure Boot).

Jakie są objawy ataku na BIOS/UEFI? Skąd wiedzieć, że firmware jest zainfekowane?

Profesjonalne ataki na firmware są projektowane tak, aby nie zdradzać swojej obecności. Komputer może startować normalnie, system działać szybko, a użytkownik nie zobaczy żadnego oczywistego błędu. Zdarza się, że jedyną wskazówką jest to, że infekcja „magicznie wraca” po kolejnych reinstalacjach systemu i formatowaniu dysku.

W firmach, gdzie jest monitoring bezpieczeństwa, podejrzenia budzi zwykle:

• niewyjaśniona obecność złośliwych procesów tuż po świeżej instalacji systemu,
• nietypowe wpisy w logach rozruchu,
• różnice między obrazem firmware a referencyjnym obrazem producenta (wykrywane przez specjalistyczne narzędzia).

Domowy użytkownik bez dedykowanych narzędzi ma małe szanse, by samodzielnie potwierdzić infekcję BIOS/UEFI. To kolejny argument za regularnym aktualizowaniem firmware z zaufanego źródła, zanim ktoś wykorzysta znane luki.

Czy małe firmy naprawdę muszą przejmować się aktualizacją firmware, czy to problem „korporacji”?

Ataki na firmware nie dotyczą wyłącznie wielkich korporacji i instytucji rządowych. Typowy scenariusz z małej firmy: stary serwer z nieaktualizowanym BIOS-em trzyma bazę klientów i księgowość, a obok pracują nowe laptopy z UEFI, które też nigdy nie dostały aktualizacji. Wystarczy jedno skuteczne włamanie na poziomie firmware serwera, aby wyciekły dane wszystkich kontrahentów.

Duże organizacje zwykle mają procedury i narzędzia do zarządzania aktualizacjami sprzętu. Małe firmy często żyją mitem „od lat działa, więc jest bezpieczne”. W praktyce to one bywają łatwiejszym celem – właśnie dlatego, że nikt nie dotyka BIOS/UEFI i nie myśli o nim w kategoriach bezpieczeństwa, tylko „ustawień sprzętowych”.