PKfail – czyli jak drobne przeoczenie może naruszyć bezpieczeństwo setek urządzeń

Wpadka dziesięciu głównych producentów sprzętu, może wydawać się kuriozalna i nawet zabawna, gdyby nie fakt, że narusza kluczowy łańcuch zaufania, mający na celu zabezpieczenie integralności wykorzystywanych systemów operacyjnych. 

Unified Extensible Firmware Interface (w skrócie UEFI) to interfejs pomiędzy sprzętem, a systemem operacyjnym – nowoczesny zamiennik Basic Input/Output System (BIOS). Do wielu funkcji można zaliczyć między innymi modułowość – producenci mogą pisać własne sterowniki i aplikacje pozwalające optymalizować wydajność i rozszerzać możliwości. 

Jednym z kluczowych elementów UEFI jest tzw. Secure Boot, który zapewnia integralność procesu bootowania systemu. Pozwala on na uruchomienie tylko zaufanego (to znaczy kryptograficznie podpisanego) kodu. Ma to na celu zapobieganie sytuacjom, w których złośliwy kod jest wykonywany “poniżej” poziomu systemu operacyjnego. Brzmi poważnie, prawda?

Badacze z Binarly odkryli i opisali problem z najważniejszym elementem tej układanki. Secure Boot działa na zasadzie ustanowienia łańcucha zaufania. Elementy “wyższego poziomu” – uruchamiane później, muszą zostać poprawnie zweryfikowane w celu ich uruchomienia lub zmiany. 

Mowa o tzw. Platform Key (w skrócie PK), który jest głównym elementem zaufania zapisanym na etapie produkowania komponentów przez producentów OEM. Każdy poniższy zestaw kluczy może być zaktualizowany tylko w przypadku podpisania zmiany z wykorzystaniem nadrzędnych kluczy. To znaczy, że aktualizacja db (Signature Database) lub dbx (Forbidden Signature Database) może się odbyć tylko po weryfikacji podpisu przy pomocy KEK (Key Exchange Key). A same klucze z KEK mogą być wymienione pod warunkiem podpisania aktualizacji przez PK. Jak można wywnioskować z tej zależności, PK jest nadrzędnym i kluczowym komponentem łańcucha zaufania. 

Badacze z Binarly zauważyli, że setki produktów producentów: 

• Acer
• Aopen
• Dell
• Formelife
• Fujitsu
• Gigabyte
• HP
• Intel
• Lenovo
• Supermicro

korzystają z testowych kluczy wygenerowanych przez firmę American Megatrends International (AMI) – klucze te mają w polach Subject oraz Issuer wpisany ciąg CN=DO NOT TRUST – AMI Test PK, który w zamierzeniu miał być wymieniony na klucz producentów komputerów, który byłby wygenerowany i przechowywany zgodnie z najlepszymi praktykami bezpieczeństwa, włączając w to użycie modułów Hardware Security Modules (w skrócie HMS). Binarly znalazło prywatną część klucza PK w, zabezpieczonym czteroznakowym hasłem, pliku dostępnym na portalu GitHub. 

Okazuje się również, że wcześniej (w 2023 roku) miał miejsce wyciek kluczy AMI, zresztą taki sam los spotkał klucze do podobnego rozwiązania Intela – Boot Guard. Sam fakt wykorzystania niebezpiecznych kluczy w UEFI, jak słusznie zauważają autorzy PKfail, nie jest niczym nowym i już w 2016 roku podobne zgłoszenie otrzymało CVE. Badaczom udało się zidentyfikować 22 klucze, które powinny zostać wycofane z użytku zarówno z laptopów kierowanych do zwykłych konsumentów (np. laptopy dla graczy) jak i biznesu (serwery). 

Atakujący z wysokimi uprawnieniami w systemie, może przygotować swój KEK, który będzie mógł dodać do bazy. Ten krok umożliwi mu podpisanie aktualizacji Signature Database, tak aby dodać klucz wykorzystywany do podpisania złośliwego modułu UEFI. Dokonując aktualizacji firmware, podczas uruchomienia urządzenia zostanie również uruchomiony złośliwy moduł dostarczony przez atakującego, który z powodzeniem zostanie zaakceptowany podczas walidacji przeprowadzanej przez mechanizm Secure Boot. Moduł ten może mieć pełny dostęp do komputera ofiary, łącznie z dostępem do plików czy możliwości modyfikacji kluczowych elementów systemu operacyjnego takich jak loader. Może to wykorzystywać malware takie jak BlackLotus, o którym już pisaliśmy.

Badacze przedstawili PoCa, którego działanie zostało zademonstrowane na poniższym filmiku:

Opublikowana została również domena pk.fail, która pozwala zidentyfikować czy dane urządzenie jest podatne. Producenci zostali poinformowani o zaistniałej sytuacji. Użytkownikom pozostaje oczekiwać aktualizacji, a do tego czasu wykorzystać wszelkie znane mechanizmy obrony urządzeń; systemowe oraz fizyczne, ponieważ do tego ataku wymagane są wysokie uprawnienia lub fizyczny dostęp do urządzenia.  

~fc