ESET na swoim blogu welivesecurity.com przedstawił odkrycie jedenastu podatnych UEFI shim bootloaders. Użycie podatnego bootloadera umożliwiało obejście mechanizmu Secure Boot (którego zadaniem jest zapobieganie możliwości uruchomienia „niezaufanego” oprogramowania podczas startu urządzenia) i w konsekwencji wykonanie dowolnego, złośliwego kodu. Dalsze scenariusze zależały już tylko od umiejętności i pomysłów atakującego. Jako przykład ESET podaje instalację bootkitów (jest to rodzaj malware bytujący w szeroko pojętym oprogramowaniu układowym, m.in. właśnie w UEFI), takich jak Bootkitty, HybridPetya czy BlackLotus. Bootkity z powodu umieszczenia w firmware są w stanie „przetrwać” reinstalację systemu operacyjnego, dlatego powinny być uznawane za poważne zagrożenie.
Pojęcie „UEFI shim” nie jest szczególne rozpowszechnione w polskojęzycznych serwisach technicznych, ale we wspomnianym wpisie na blogu ESET znajdziemy dość prostą definicję. Określamy tak niewielki „moduł” rozruchowy stosowany w dystrybucjach systemu Linux, który weryfikuje kolejny bootloader (współcześnie w zdecydowanej większości przypadków będzie to GRUB2) i jeśli uzna go za „zaufany”, to pozwala przejąć mu działanie i wykonać dalsze etapy rozruchu systemu operacyjnego. Zastosowanie UEFI shims stało się koniecznością z uwagi na ilość dystrybucji systemów Linux – nie sposób przeprowadzić procedurę weryfikacji i podpisania każdego możliwego bootloadera przez Microsoft. Dostępny jest raz podpisany UEFI shim stanowiący „warstwę zaufania”.
Firma Microsoft de facto zarządza listami zaufanego i niezaufanego oprogramowania stosowanego na etapie rozruchu. Polecam doczytać informacje na blogu ESET, bo przystępnie opisano skomplikowane aspekty działania Secure Boot i baz db oraz dbx.
ESET fakt odkrycia podatnych UEFI shims zgłosił do CERT/CC w lutym. Z kolei wszystkie podatne bootloadery zostały dodane do bazy dbx (zawierającej listę „niedozwolonych” programów) 9 czerwca w ramach standardowej aktualizacji systemu Windows (Patch Tuesday). Lista zablokowanych bootloaderów została zamieszczona w tym artykule. Znajdują się na niej bootloadery stosowane m.in. w systemach RHEL 7.2 i CentOS 7.2, pakiecie baramundi Management Suite, PC-Doctor czy customowym systemie Abitti (używanym do zdawania przez abiturientów egzaminu maturalnego w Finlandii z użyciem własnych laptopów – jednak nie w formie zdalnej, tylko w szkolnej sali). To starsze wersje wymienionych systemów i narzędzi do zarządzania stacjami roboczymi bądź też stanowiących tzw. płyty ratunkowe.
Istnieje duże prawdopodobieństwo, że zablokowane shims to jedynie niewielka część ogólnego problemu z bezpieczeństwem UEFI. Z pewnością różne podatności pozwalające atakującym na wykonanie „niezaufanego” kodu znajdą się też w innych rozwiązaniach. Podobna kwestia dotyczy bootloadera GRUB2, który również może posiadać podatności umożliwiające nieautoryzowane działania. Z drugiej strony ataki na proces rozruchu nie są trywialne bądź też wymagają fizycznego dostępu do urządzenia, co powinno ograniczyć ryzyko podobnych sytuacji.
Secure Boot warto aktywować (jeśli nie jest to opcja domyślna w danym UEFI), aczkolwiek niektóre rozwiązania ochronne wymagają z kolei wyłączenia tego mechanizmu. Stanowi on jeden z poziomów zabezpieczeń, ale nie jest to oczywiście doskonała funkcja, której nie można obejść.
