Secure Boot można ominąć z UEFI Shell. System operacyjny nawet nie dostaje szansy się bronić
Secure Boot można ominąć z UEFI Shell. System operacyjny nawet nie dostaje szansy się bronić
Secure Boot miał być jedną z najważniejszych granic bezpieczeństwa współczesnego komputera. Problem w tym, że granica może zostać przesunięta o jeden poziom niżej — do samego firmware. Nowo ujawniona technika związana z UEFI Shell pokazuje, jak obecność narzędzia serwisowego w pamięci SPI Flash oraz błędne zarządzanie wpisami bootowania może doprowadzić do obejścia Secure Boot jeszcze przed uruchomieniem Windows lub Linux. System operacyjny nie jest wtedy pierwszą linią obrony. Nie jest nawet częścią problemu.
Secure Boot miał zatrzymać atak przed startem systemu
Secure Boot jest często przedstawiany bardzo prosto:
UEFI
↓
sprawdzenie podpisu
↓
zaufany bootloader
↓
system operacyjny
Jeżeli bootloader nie spełnia wymagań zaufania, firmware nie powinien go uruchomić.
W praktyce mechanizm jest bardziej rozbudowany. UEFI wykorzystuje między innymi bazę dozwolonych certyfikatów i podpisów db, bazę unieważnionych elementów dbx, klucze platformy oraz mechanizmy aktualizacji zaufania. Całość ma stworzyć chain of trust prowadzący od firmware do kodu uruchamianego przez system.
Na Netbe szczegółowo opisywałem już Secure Boot i jego architekturę. W tym modelu najważniejsze jest jedno założenie:
kod wykonywany przed systemem operacyjnym musi sam podlegać kontroli zaufania.
I właśnie tutaj pojawia się UEFI Shell.
UEFI Shell nie jest systemem operacyjnym
UEFI Shell to środowisko wykonywane bezpośrednio w pre-boot environment.
Nie jest to Linux.
Nie jest to Windows.
Nie jest to nawet zwykły program uruchamiany przez system operacyjny.
Shell działa na poziomie UEFI i udostępnia zestaw poleceń przeznaczonych przede wszystkim do diagnostyki, serwisowania, konfiguracji oraz pracy z platformą przed startem systemu.
To ogromna różnica.
W Windows polecenie działające jako administrator nadal znajduje się wewnątrz systemowego modelu bezpieczeństwa.
W UEFI Shell sytuacja wygląda inaczej:
Hardware
↓
Firmware
↓
UEFI Services
↓
UEFI Shell
↓
Bootloader
↓
Operating System
Shell jest więc bardzo blisko fundamentu całego procesu startowego.
A im bliżej fundamentu znajduje się kod, tym większe są potencjalne konsekwencje jego kompromitacji.
Problem VU#718077
8 września 2026 roku CERT Coordination Center opublikował VU#718077, opisujący możliwość wykorzystania UEFI Shell obecnego w pamięci SPI Flash do obejścia mechanizmów Secure Boot.
CERT wskazuje, że problem występuje w scenariuszach, w których UEFI Shell znajduje się w firmware, a atakujący może modyfikować konfigurację wpisów rozruchowych.
Istotą problemu jest możliwość utworzenia dodatkowych wpisów bootowania w taki sposób, aby ominąć mechanizm, który miał usunąć lub zablokować dostęp do Shell podczas aktywnego Secure Boot.
To nie jest klasyczny przypadek:
złośliwy plik
↓
exploit
↓
Windows
Tutaj ścieżka jest przesunięta niżej:
UEFI configuration
↓
Boot entry manipulation
↓
UEFI Shell
↓
pre-boot memory access
↓
zmiana środowiska startowego
↓
nieautoryzowany kod
↓
OS
To fundamentalna różnica.
Dlaczego UEFI Shell jest tak potężny?
Powodem nie jest sama obecność konsoli.
Problemem są uprawnienia i kontekst wykonania.
UEFI Shell posiada funkcje przeznaczone do pracy diagnostycznej z pamięcią i środowiskiem firmware. CERT wskazuje wprost na możliwości związane m.in. z odczytem i modyfikacją pamięci fizycznej.
W kontekście bezpieczeństwa jest to bardzo istotne.
Jeżeli kod działający w pre-boot environment może uzyskać dostęp do obszarów pamięci, które zawierają informacje związane ze stanem bezpieczeństwa platformy, klasyczny model:
Secure Boot → sprawdzam podpis → uruchamiam / blokuję
przestaje być wystarczający.
Nie trzeba wtedy koniecznie „złamać kryptografii”.
Można próbować zaatakować implementację i stan środowiska, w którym Secure Boot jest egzekwowany.
To jedna z najważniejszych lekcji płynących z tego przypadku.
Nie złamano kryptografii Secure Boot
To trzeba bardzo wyraźnie podkreślić.
Nie mamy tutaj sytuacji, w której ktoś znalazł sposób na wygenerowanie poprawnego podpisu bez posiadania klucza prywatnego.
Secure Boot może nadal poprawnie wykonywać swoje operacje kryptograficzne.
Problem leży gdzie indziej.
Jeżeli uprzywilejowany komponent pre-boot otrzyma możliwość manipulowania stanem, konfiguracją lub pamięcią wykorzystywaną przez mechanizm bezpieczeństwa, kryptografia nie rozwiązuje całego problemu.
Można to zobrazować:
KRYPTografia
│
▼
"Czy kod jest zaufany?"
│
▼
Secure Boot
│
┌──────┴──────┐
│ │
poprawny problem
podpis wyżej
│ │
▼ ▼
ALLOW manipulacja
środowiskiem
Bezpieczeństwo systemu nie składa się wyłącznie z podpisu cyfrowego.
Liczy się również miejsce, w którym ten podpis jest sprawdzany, kod wykonujący sprawdzenie oraz możliwość manipulowania jego stanem.
SPI Flash — miejsce, o którym większość użytkowników nie myśli
SPI Flash to pamięć wykorzystywana przez platformę do przechowywania firmware.
W uproszczeniu:
Motherboard
│
▼
SPI Flash
│
├── UEFI firmware
├── DXE modules
├── BDS components
├── configuration
└── dodatkowe moduły
Użytkownik może myśleć:
„System mam na SSD.”
To prawda.
Ale system operacyjny nie jest pierwszym kodem wykonywanym podczas uruchamiania komputera.
Przed nim istnieje cały świat firmware.
Dlatego infekcja lub manipulacja na poziomie UEFI może mieć zupełnie inny charakter niż malware zapisany na partycji systemowej.
Dlaczego Shell trafia do firmware?
To interesujący element całej historii.
UEFI Shell ma legalne zastosowania.
Administratorzy i technicy wykorzystują go do:
- diagnostyki sprzętu,
- aktualizacji,
- konfiguracji,
- testowania,
- odzyskiwania systemów,
- pracy serwisowej,
- diagnostyki urządzeń,
- wykonywania operacji przed uruchomieniem OS.
Problem pojawia się wtedy, gdy funkcjonalność serwisowa pozostaje dostępna w produkcyjnym firmware, mimo że model bezpieczeństwa zakłada, iż Secure Boot powinien ograniczać możliwość uruchamiania nieautoryzowanych komponentów.
CERT wskazuje, że wiele implementacji OEM i IBV zawiera UEFI Shell w SPI Flash właśnie ze względów serwisowych.
To klasyczny konflikt:
debuggability
vs.
security
Im więcej funkcji diagnostycznych zostawimy w firmware, tym większa powierzchnia ataku.
Błąd nie polega tylko na tym, że Shell istnieje
Samo umieszczenie Shell w firmware nie oznacza automatycznie kompromitacji Secure Boot.
To ważne rozróżnienie.
Problem pojawia się wtedy, gdy kilka elementów połączy się w jeden łańcuch:
UEFI Shell obecny w firmware
+
możliwość manipulowania boot entries
+
błędna logika kontroli wpisów
+
dostęp do pre-boot environment
=
możliwe obejście Secure Boot
To właśnie dlatego podatności firmware są tak trudne do oceniania.
Pojedynczy komponent może być całkowicie legalny.
Pojedynczy mechanizm może być poprawny.
Błąd pojawia się dopiero na styku kilku mechanizmów.
AMI Aptio pokazuje problem implementacyjny
CERT wskazuje między innymi na podatność dotyczącą AMI Aptio UEFI BDS module.
W przypadku opisanym przez GIGABYTE problem wynikał z błędu logicznego podczas usuwania wpisów uruchamiających Shell.
Jeżeli występowały wielokrotne wpisy odnoszące się do Shell, mechanizm nie usuwał ich prawidłowo.
Efekt:
Secure Boot ON
↓
Shell powinien być niedostępny
↓
BDS usuwa wpis Shell
↓
pozostaje alternatywny wpis
↓
Shell nadal może zostać uruchomiony
To świetny przykład tego, dlaczego bezpieczeństwo nie kończy się na implementacji kryptografii.
Jedna błędna decyzja logiczna w kodzie zarządzającym boot entries może podważyć założenia całego mechanizmu.
CERT podaje, że GIGABYTE potwierdziło problem w module BDS i wdrażało poprawkę dostarczoną przez AMI.
CVE-2026-33197, CVE-2026-6485 i CVE-2026-20293
Problem nie jest jednym uniwersalnym CVE dla wszystkich urządzeń.
CERT wskazuje kilka identyfikatorów związanych z różnymi implementacjami:
- CVE-2026-33197 — związane z AMI,
- CVE-2026-6485 — związane z Insyde,
- CVE-2026-20293 — wariant dotyczący Cisco UCS i urządzeń bazujących na UCS.
To bardzo ważne dla administratorów.
Nie można przyjąć:
„Mam Secure Boot, więc mnie to nie dotyczy.”
Trzeba wiedzieć:
- jaki jest producent platformy,
- jaki jest dostawca firmware,
- jaka wersja UEFI jest zainstalowana,
- czy UEFI Shell znajduje się w obrazie firmware,
- czy producent opublikował poprawkę,
- czy urządzenie ma dodatkowe mechanizmy ochrony konfiguracji bootowania.
Cisco również zostało dotknięte
CERT potwierdza wariant problemu w Cisco UCS Servers i UCS-based appliances, dla którego Cisco nadało własny identyfikator CVE-2026-20293.
To zmienia perspektywę.
Nie mówimy już tylko o komputerze użytkownika.
UEFI i Secure Boot są obecne również w infrastrukturze serwerowej.
Jeżeli podobny mechanizm znajduje się na serwerze, konsekwencje potencjalnego kompromisu mogą obejmować znacznie więcej niż jeden endpoint.
W środowisku data center firmware staje się częścią infrastruktury bezpieczeństwa.
Insyde: nie każdy system jest podatny
CERT przytacza również stanowisko Insyde.
Producent wskazuje, że większość klientów może nie być dotknięta problemem, ponieważ nie umieszczają Shell w obszarach system code zatwierdzonych do wykonywania bez podpisu podczas Secure Boot.
Istnieje jednak grupa wdrożeń, w których Shell został dodany i tam problem może wystąpić.
To kolejny powód, dla którego lista „podatnych producentów” nie wystarcza.
Liczy się konkretna konfiguracja firmware.
Dwa urządzenia tej samej marki mogą mieć zupełnie inną konfigurację UEFI.
Atakujący nie musi zaczynać od fizycznego dostępu
Wokół firmware często pojawia się błędne założenie:
„Żeby zaatakować UEFI, trzeba mieć komputer w rękach.”
Nie zawsze.
CERT opisuje scenariusz, w którym warunkiem jest możliwość modyfikowania UEFI boot configuration. W praktyce może to oznaczać, że atakujący najpierw musi uzyskać odpowiednio wysoki poziom uprawnień w systemie lub inny kanał pozwalający zmienić konfigurację startową.
To zmienia sposób patrzenia na ryzyko.
Secure Boot może być bardzo skuteczny przeciwko atakującemu, który próbuje po prostu uruchomić niepodpisany bootloader.
Jeżeli jednak przeciwnik wcześniej przejmie uprzywilejowany dostęp do systemu, zaczyna atakować warstwę konfiguracji pre-boot.
Model zagrożenia wygląda wtedy tak:
Initial Access
↓
Privilege / Administrative Access
↓
Boot Configuration Manipulation
↓
UEFI Shell
↓
Pre-boot Execution
↓
Secure Boot Bypass
↓
Bootkit / malicious boot component
↓
Operating System
To jest dużo bardziej realistyczny model niż „haker naciska F12 i omija Secure Boot”.
Dlaczego OS może nawet nie wiedzieć, co się stało?
To najciekawsza część.
Jeżeli nieautoryzowany kod zostanie uruchomiony przed systemem operacyjnym, mechanizmy działające dopiero po starcie Windows lub Linux mają ograniczoną widoczność.
EDR może doskonale monitorować:
Windows
↓
process
↓
DLL
↓
driver
ale niekoniecznie zobaczy bezpośrednio wszystko, co wydarzyło się:
UEFI
↓
BDS
↓
UEFI Shell
↓
pre-boot manipulation
↓
bootloader
↓
Windows
Dlatego ataki bootkitowe są tak interesujące z punktu widzenia obrońców.
Atakujący próbuje zejść poniżej poziomu, na którym znajduje się główna telemetria bezpieczeństwa.
To właśnie jest problem bootkitów
Bootkit nie musi być spektakularnym rootkitem zapisanym w firmware.
Wystarczy, że przejmie odpowiednio wczesny etap procesu uruchamiania.
Przykładowy model:
UEFI
↓
malicious component
↓
trusted-looking boot path
↓
Windows Boot Manager
↓
Windows Kernel
W tym momencie złośliwy kod może próbować przygotować środowisko dla kolejnych komponentów.
Historia zna już takie przypadki.
BlackLotus pokazał, że podatny, ale nadal zaufany komponent bootowania może być problemem nawet wtedy, gdy system posiada aktywny Secure Boot. W 2026 roku problem starych, nadal zaufanych shimów ponownie pokazał, jak trudne jest zarządzanie zaufaniem w całym ekosystemie bootloaderów.
Wspólny mianownik jest prosty:
zaufany kod nie zawsze oznacza bezpieczny kod.
Secure Boot nie jest magiczną tarczą
To jedna z najważniejszych rzeczy, które warto zapamiętać.
Secure Boot chroni określony model:
trusted code
↓
verified
↓
execute
Nie chroni automatycznie przed:
trusted but vulnerable component
Nie chroni też automatycznie przed:
firmware logic bug
ani:
misconfigured boot policy
ani:
compromised configuration state
Dlatego nowoczesne bezpieczeństwo platformy wymaga kilku warstw.
Secure Boot + TPM to nie to samo
TPM często jest wrzucany do tego samego worka co Secure Boot.
To błąd.
Secure Boot odpowiada przede wszystkim za kontrolę zaufania do kodu startowego.
TPM może natomiast uczestniczyć w mierzeniu stanu platformy i ochronie kluczy.
Schematycznie:
UEFI
│
┌───────┴────────┐
│ │
Secure Boot TPM
│ │
Czy kod Co zostało
jest zaufany? zmierzone?
│ │
└───────┬────────┘
▼
OS / Data
Na Netbe szczegółowo opisywałem już TPM 2.0 i jego rolę w bezpieczeństwie Windows.
Właśnie dlatego kompromitacja jednego elementu nie musi automatycznie oznaczać całkowitego pokonania wszystkich pozostałych.
BitLocker jest kolejną warstwą
Jeżeli system wykorzystuje BitLocker, zmiany w środowisku startowym mogą wpłynąć również na zachowanie TPM i mechanizmu ochrony kluczy.
Może pojawić się:
Boot state changed
↓
TPM measurements differ
↓
BitLocker Recovery
Nie oznacza to oczywiście, że każdy nieoczekiwany BitLocker Recovery jest dowodem ataku.
Może go wywołać zwykła aktualizacja firmware, zmiana konfiguracji UEFI, zmiana Secure Boot czy wymiana sprzętu.
Ale:
unexpected recovery
+
unexpected boot configuration change
+
firmware anomaly
powinny już zainteresować administratora.
Na Netbe opisywałem szerzej BitLocker Recovery i jego związek ze zmianami środowiska startowego.
Co dokładnie trzeba monitorować?
W przedsiębiorstwie samo sprawdzenie:
Secure Boot = Enabled
jest zdecydowanie za mało.
Warto monitorować cały stan platformy.
1. Secure Boot
Sprawdź, czy jest aktywny.
W Windows można wykorzystać:
Confirm-SecureBootUEFI
Wynik:
True
oznacza aktywny Secure Boot.
Ale to dopiero początek.
2. Tryb UEFI
System powinien działać w oczekiwanym trybie UEFI, a nie w przypadkowej konfiguracji Legacy/CSM.
3. TPM
Sprawdź:
- obecność TPM,
- wersję,
- stan,
- dostępność,
- błędy związane z pomiarami platformy.
4. Boot entries
W Windows przydatnym narzędziem jest:
bcdedit /enum firmware
Można również wykorzystać:
mountvol S: /S
do analizy partycji EFI — oczywiście w kontrolowanym środowisku administracyjnym.
Celem nie jest wykonywanie przypadkowych zmian.
Celem jest wykrycie anomalii.
Niespodziewany wpis bootowania powinien być traktowany poważnie
Jeżeli administrator zna standardową konfigurację urządzenia, powinien wiedzieć, jakie wpisy są oczekiwane.
Przykładowo:
Windows Boot Manager
Linux Boot Manager
firmware diagnostics
mogą być normalne.
Natomiast pojawienie się nieznanego wpisu wskazującego na dodatkowy EFI executable powinno zostać zbadane.
W kontekście VU#718077 ma to szczególne znaczenie, ponieważ mechanizm ataku wykorzystuje właśnie możliwość manipulowania boot entries.
UEFI variables są częścią powierzchni ataku
UEFI przechowuje konfigurację w zmiennych firmware.
To między innymi tam mogą znajdować się informacje związane z kolejnością bootowania i konfiguracją platformy.
Dlatego administratorzy powinni traktować UEFI variables jako element infrastruktury bezpieczeństwa, a nie tylko „ustawienia BIOS-u”.
Jeżeli środowisko posiada możliwości audytowania zmian:
UEFI variable change
↓
audit
↓
correlation
↓
alert
może dostarczyć bardzo cennego sygnału.
Szczególnie gdy zmiana występuje razem z:
- uzyskaniem uprawnień administratora,
- modyfikacją partycji EFI,
- zmianą ustawień Secure Boot,
- zmianą TPM state,
- aktualizacją firmware,
- nietypowym restartem.
Firmware powinien wejść do procesu patch management
To nadal jeden z największych problemów bezpieczeństwa przedsiębiorstw.
Windows Update?
Tak.
Linux packages?
Tak.
Aplikacje?
Tak.
Firmware?
Często:
„sprawdzimy później”.
To podejście jest coraz mniej sensowne.
Jeżeli podatność znajduje się w firmware, aktualizacja systemu operacyjnego może jej nie naprawić.
CERT wprost zaleca aktualizację firmware zgodnie z procesem producenta platformy.
To oznacza, że organizacja powinna posiadać:
Firmware inventory
↓
Version tracking
↓
Vendor advisory monitoring
↓
Risk assessment
↓
Firmware update
↓
Post-update verification
Bez tego administrator może mieć doskonale aktualny Windows na komputerze z przestarzałym firmware.
Firmware inventory powinien być normalnym asset inventory
Dojrzałe środowisko powinno wiedzieć:
Device
├── Manufacturer
├── Model
├── BIOS/UEFI vendor
├── Firmware version
├── Secure Boot state
├── TPM state
├── Boot configuration
└── Last firmware update
Dopiero wtedy można odpowiedzieć na pytanie:
Ile naszych urządzeń rzeczywiście jest podatnych?
Bez inventory odpowiedź często brzmi:
„Nie wiemy.”
A to jest najgorsza możliwa odpowiedź podczas incydentu firmware.
Co z Linuxem?
Problem nie dotyczy wyłącznie Windows.
UEFI Secure Boot jest również wykorzystywany przez dystrybucje Linux.
Typowa ścieżka może wyglądać następująco:
UEFI
↓
shim
↓
GRUB
↓
Linux kernel
↓
initramfs
↓
Linux
Każdy dodatkowy komponent jest elementem chain of trust.
Dlatego administrator Linux powinien zwracać uwagę między innymi na:
- stan Secure Boot,
- wersję firmware,
- wersję shim,
- wersję GRUB,
- konfigurację EFI System Partition,
- zmiany wpisów UEFI,
- integralność bootloadera.
Nie wystarczy powiedzieć:
„Kernel jest podpisany.”
Jeżeli wcześniejszy etap procesu startowego został skompromitowany, problem znajduje się przed kernelem.
Secure Boot i supply chain
To prowadzi do jeszcze większego problemu.
Secure Boot tworzy system zaufania do komponentów.
Ale ktoś musi te komponenty dostarczyć.
W łańcuchu mogą występować:
CPU vendor
↓
IBV
↓
OEM
↓
firmware build
↓
bootloader
↓
OS vendor
↓
system
Każdy etap może wprowadzić błąd.
W przypadku UEFI jest to szczególnie skomplikowane, ponieważ OEM często buduje własne obrazy firmware na bazie komponentów dostarczanych przez niezależnych dostawców BIOS/UEFI.
Dlatego jedna wada upstream może pojawić się w wielu produktach.
TianoCore pokazuje skalę problemu
TianoCore EDK II jest otwartą implementacją wykorzystywaną jako fundament ekosystemu UEFI.
CERT wskazuje właśnie na UEFI Shell związaną z TianoCore EDK II jako element istotny dla analizowanego problemu.
To ma znaczenie dla bezpieczeństwa supply chain.
Jeżeli wspólny komponent znajduje się w firmware wielu producentów, jedna klasa błędu może zostać odziedziczona przez wiele produktów.
Nie oznacza to jednak, że każdy sprzęt wykorzystujący EDK II jest automatycznie podatny.
Konfiguracja, sposób integracji oraz konkretne moduły mają ogromne znaczenie.
Najbardziej niebezpieczne jest połączenie legalnej funkcji z błędną logiką
To moim zdaniem najciekawszy element całego przypadku.
UEFI Shell jest legalnym narzędziem.
Boot entries są legalnym mechanizmem.
Secure Boot jest legalnym mechanizmem.
SPI Flash jest normalnym elementem platformy.
Każdy element osobno ma uzasadnienie.
Problem pojawia się tutaj:
legal feature
+
incorrect state handling
+
insufficient enforcement
+
powerful pre-boot capability
=
security boundary failure
To bardzo typowy wzorzec współczesnych podatności firmware.
Nie trzeba mieć „backdoora”.
Wystarczy błąd w logice.
Dlaczego pre-boot jest tak trudny do obrony?
Bo jest jednocześnie:
- bardzo uprzywilejowany,
- bardzo wczesny,
- zależny od sprzętu,
- zależny od firmware,
- częściowo niewidoczny dla OS,
- trudny do monitorowania,
- trudny do aktualizacji,
- zależny od producenta.
To zupełnie inna klasa bezpieczeństwa niż aplikacja webowa.
W aplikacji można:
patch
restart
verify
W firmware:
vendor advisory
↓
firmware package
↓
deployment
↓
reboot
↓
flash update
↓
verification
↓
possible recovery procedure
Błąd podczas aktualizacji może mieć konsekwencje dla całego urządzenia.
Co powinna zrobić firma?
Praktyczna checklista:
Firmware
- zinwentaryzować wersje BIOS/UEFI,
- sprawdzić producenta firmware,
- zidentyfikować modele platform,
- sprawdzić advisories OEM/IBV,
- wdrożyć poprawki firmware.
Secure Boot
- potwierdzić, że Secure Boot jest aktywny,
- sprawdzić konfigurację kluczy,
- kontrolować
dbidbx, - monitorować zmiany konfiguracji.
Boot configuration
- kontrolować wpisy UEFI,
- wykrywać nowe lub nieznane wpisy,
- rejestrować zmiany,
- ograniczyć możliwość ich modyfikacji.
UEFI Shell
- ustalić, czy Shell jest obecny,
- sprawdzić, czy jest wymagany,
- jeśli nie jest potrzebny — usunąć go z obrazu firmware, jeżeli producent na to pozwala,
- nie pozostawiać funkcji diagnostycznych bez powodu na produkcyjnych platformach.
TPM
- monitorować stan TPM,
- analizować nieoczekiwane zmiany,
- korelować zmiany TPM z boot configuration.
BitLocker
- monitorować nieoczekiwane Recovery,
- korelować Recovery z aktualizacją firmware,
- korelować Recovery z modyfikacją Secure Boot i UEFI.
EDR/SIEM
Korelować:
Admin privilege escalation
+
UEFI variable change
+
EFI partition modification
+
unexpected reboot
+
BitLocker Recovery
Taka kombinacja jest znacznie ciekawszym sygnałem niż pojedynczy alert.
Jak sprawdzić stan Secure Boot?
Na Windows można rozpocząć od:
Confirm-SecureBootUEFI
oraz informacji systemowych:
msinfo32
W oknie System Information należy sprawdzić między innymi:
BIOS Mode
Secure Boot State
Nie należy jednak traktować tych informacji jako kompletnego audytu bezpieczeństwa.
Pokazują stan systemu.
Nie odpowiadają na wszystkie pytania dotyczące integralności firmware.
Co z aktualizacją BIOS/UEFI?
W przypadku podatności firmware najważniejszą zasadą jest:
korzystać wyłącznie z oficjalnego mechanizmu producenta urządzenia.
Nie pobieraj przypadkowych obrazów BIOS z forów.
Nie używaj firmware o nieznanym pochodzeniu.
Nie zakładaj, że plik znaleziony dla podobnego modelu będzie właściwy.
W przedsiębiorstwie aktualizacja firmware powinna być kontrolowanym procesem zmian.
Przed aktualizacją należy również uwzględnić BitLocker i TPM, ponieważ zmiana firmware może wpłynąć na stan platformy i doprowadzić do Recovery.
Czy wyłączenie Secure Boot rozwiązuje problem?
Nie.
Wręcz przeciwnie.
Wyłączenie Secure Boot usuwa jedną z warstw kontroli.
Jeżeli istnieje podatność związana z mechanizmem Secure Boot, naturalną reakcją może być:
„Wyłączmy Secure Boot.”
To jednak oznacza rezygnację z mechanizmu, który miał chronić chain of trust.
Nie jest to poprawka.
To obejście problemu poprzez obniżenie poziomu bezpieczeństwa.
Dlatego wcześniejsze materiały Netbe dotyczące TPM i Secure Boot warto traktować jako uzupełnienie, a nie instrukcję wyłączania zabezpieczeń w środowisku produkcyjnym.
Czy Secure Boot jest więc bezwartościowy?
Absolutnie nie.
To byłby błędny wniosek.
Secure Boot nadal jest bardzo ważnym mechanizmem.
Problem pokazuje tylko, że:
Secure Boot nie może być traktowany jako pojedynczy, niezniszczalny przełącznik bezpieczeństwa.
Jego skuteczność zależy od:
- firmware,
- boot managera,
- certyfikatów,
- baz
db/dbx, - implementacji BDS,
- konfiguracji platformy,
- aktualności komponentów,
- ochrony TPM,
- polityki aktualizacji,
- integralności całego chain of trust.
Bezpieczeństwo platformy jest systemem.
Nie checkboxem.
Najważniejsza lekcja z VU#718077
Najbardziej interesujący aspekt tej podatności nie brzmi:
„UEFI Shell jest niebezpieczny.”
To zbyt proste.
Prawdziwa lekcja brzmi:
Każdy komponent działający przed systemem operacyjnym powinien być traktowany jako część granicy bezpieczeństwa.
Jeżeli producent dodaje narzędzie diagnostyczne do firmware, musi uwzględnić jego możliwości w modelu zagrożeń.
Jeżeli boot manager usuwa wpisy Shell przy aktywnym Secure Boot, musi prawidłowo obsługiwać wszystkie odpowiadające mu wpisy.
Jeżeli platforma pozwala modyfikować boot configuration, musi istnieć kontrola nad tym, kto może to zrobić.
Jeżeli Secure Boot ma gwarantować chain of trust, wszystkie elementy uczestniczące w jego egzekwowaniu muszą być traktowane jako security-critical.
To nie jest problem tylko „BIOS-u”
Przez lata firmware był traktowany jako coś znajdującego się poza głównym obszarem bezpieczeństwa.
Administrator aktualizował Windows.
Administrator aktualizował Linux.
Administrator aktualizował aplikacje.
BIOS?
„Jak będzie nowa wersja, to się zrobi.”
To podejście musi się skończyć.
Firmware jest częścią platformy bezpieczeństwa.
Jeżeli atakujący może zejść poniżej poziomu systemu operacyjnego, klasyczny model endpoint security zaczyna mieć dziury w monitoringu.
I dlatego:
OS security
≠
platform security
Potrzebujemy obu.
Przyszłość bezpieczeństwa będzie coraz bardziej firmware-centric
Im więcej funkcji przenosimy do sprzętu i firmware, tym większa jest powierzchnia, której administrator musi pilnować.
Dzisiaj mamy:
UEFI
Secure Boot
TPM
VBS
HVCI
BitLocker
Measured Boot
Jutro dojdą kolejne mechanizmy sprzętowego root of trust.
To dobry kierunek.
Ale każda dodatkowa warstwa oznacza także więcej kodu, więcej konfiguracji i więcej zależności.
Badania z 2026 roku pokazują nawet próby automatyzacji analizy i wykrywania powtarzalnych klas błędów w kodzie firmware UEFI, co dobrze pokazuje, że bezpieczeństwo firmware staje się osobnym, rozwijającym się obszarem badań.
Podsumowanie
Secure Boot miał postawić granicę:
niezaufany kod
↓
X
VU#718077 pokazuje jednak, że granica może zostać zaatakowana od strony samego środowiska pre-boot.
Jeżeli UEFI Shell znajduje się w firmware, a mechanizm zarządzania wpisami bootowania ma błąd logiczny, odpowiednio uprzywilejowany atakujący może doprowadzić do jego uruchomienia mimo aktywnego Secure Boot. Następnie możliwości UEFI Shell mogą zostać wykorzystane do manipulowania środowiskiem startowym i obejścia założeń, na których opiera się Secure Boot.
To nie jest historia o tym, że Secure Boot „nie działa”.
To historia o czymś znacznie ważniejszym:
najsilniejsza kryptografia nie naprawi błędnej logiki firmware.
Dlatego administratorzy powinni zacząć traktować BIOS/UEFI, Secure Boot, TPM, boot entries i firmware jako jeden wspólny obszar bezpieczeństwa.
Windows może być aktualny.
Linux może być aktualny.
EDR może działać.
Antywirus może działać.
A mimo to platforma może mieć problem znajdujący się jeszcze przed uruchomieniem systemu.
I właśnie dlatego firmware nie może już być traktowany jako czarna skrzynka.
Źródła techniczne
- CERT/CC — VU#718077: UEFI Shell module embedded in SPI Flash can be used to bypass Secure Boot. CERT/CC Vulnerability Note VU#718077
- UEFI Forum — oficjalne materiały dotyczące UEFI i Secure Boot
- Netbe — Secure Boot – ochrona procesu uruchamiania systemu
- Netbe — TPM 2.0 – sprzętowy fundament bezpieczeństwa Windows
- Netbe — BitLocker Recovery
- CERT/CC — informacje producentów dotyczące AMI, GIGABYTE, Insyde i Cisco oraz powiązanych CVE.
Autor: Marek „Netbe” Lampart — Inżynier Informatyki, praktyk systemów Windows/Linux i cyberbezpieczeństwa.
Program do wyłączania funkcji Windows 10, Windows 11, Windows 12 Systemy operacyjne Windows są wyposażone w wiele funkcji, które mogą Czytaj dalej
Pliki .SDI w środowisku Windows PE: kompletny podręcznik użytkownika i zarządzania Pliki z rozszerzeniem .SDI (System Deployment Image) są ważnym Czytaj dalej
