BIOS i UEFI: przegląd ustawień poprawiających bezpieczeństwo, cz. 1

Poprzedni odcinek naszych rozważań na temat zabezpieczania komputera osobistego był poświęcony aktualizacji głównego oprogramowania układowego, którym w większości jest BIOS lub UEFI z CSM. W procesie oraz samej koncepcji aktualizacji owego komponentu łatwo zidentyfikować pewne fundamentalne problemy. Pierwszym z nich jest trudność dostarczania: aktualizacje często nie są dostępne przez Windows Update, producenci w schizofreniczny sposób czasem jednocześnie oznaczają aktualizacje jako krytyczne i informują, że jeżeli wszystko działa, to nie warto nic ruszać. Ponadto, niepowodzenie procesu aktualizacji BIOSu, choć rzadkie, może być nieprzyjemne.

Jeżeli już jesteśmy przy aktualizacji BIOSu, warto zastanowić się, czy to przypadkiem nie jest dobra okazja na zrewidowanie niektórych ustawień. Część z nich jest łatwa do wprowadzenia, podczas gdy pozostałe będą wymagać reinstalacji systemu (może najwyższa pora...?). Przyjrzyjmy się im. Niestety, podobnie jak w kwestii problemów z dostarczaniem BIOSów ("u każdego inaczej!"), widok paneli konfiguracyjnych również dość mocno się różni między urządzeniami. Problem uległ spotęgowaniu, ponieważ obecne środowiska konfiguracyjne UEFI można "oskinować". Przez co nawet, jeżeli w środku jest ten sam rdzeń, np. firmy Insyde lub Phoenix, wizualnie wygląda to różnie. Ale spróbujmy.

Pierwszą opcją jest włączenie hasła do BIOSu. To dość skromne zabezpieczenie: hasło to ma chronić przed złośliwościami i próbami kopiowania danych w czasie krótkiego stracenia komputera z zasięgu wzroku. Gdy ktoś nam go ukradnie celem przejrzenia danych (a nie sprzedania samego laptopa), i tak spróbuje wykręcić dysk i bawić się nim samym, więc BIOS nie musi stać się fortecą. Poza tym, jeżeli zapomnimy hasła do BIOSu, to w wielu przypadkach jesteśmy ugotowani. Większość laptopów uniemożliwia reset takiego hasła, a przy odpowiednio restrykcyjnych ustawieniach możemy pozbawić się możliwości reinstalacji systemu.

Jeżeli jednak chcemy komuś tymczasowo utrudnić życie i pozbawić możliwości zmiany ustawień lub uruchomienia systemu, jest to opcja w sam raz. Hasło można bowiem założyć na kilka poziomów: na dostęp do BIOSu, odczyt dysku lub wręcz w ogóle "na komputer": bez niego system nie rozpocznie przeszukiwania nośników uruchamialnych i nie pozwoli na dostęp do programu SETUP.

Są też ciekawsze opcje. Na przykład włączenie modułów TPM oraz rozszerzeń procesora VTX pozwalających na wirtualizację. Dziś coraz rzadziej są one fabrycznie wyłączone, ale zdarza się jeszcze czasem, że wyłączają je samozwańczy "eksperci" (nawet w firmach!). Moduł TPM pozwala na przechowywanie kluczy szyfrujących dysk twardy, walidację poprawności startu Secure Boot oraz bywa wykorzystywany przez menedżery haseł. Jeżeli ktoś zakłada, że użycie go to narażanie się na tylne furtki NSA, spieszę z informacją że szyfrowanie w pełni programowe jest jeszcze mniej bezpieczne. Więcej o modułach TPM już wkrótce. Mechanizmowi Secure Boot również poświęcimy oddzielną część.

Rozszerzenia wirtualizacji są z kolei wykorzystywane przez nadzorców maszyn wirtualnych oraz narzędzia do tworzenia piaskownic (Windows Sandbox). Trudno znaleźć racjonalne uzasadnienie dla ich wyłączenia. Nieużywanie maszyn wirtualnych nie jest wystarczającym argumentem dla pozbawiania się możliwości tworzenia piaskownic. Uruchomione rozszerzenia wirtualizacji nie mają też negatywnego wpływu na wydajność. Są po prostu funkcjami procesora. Nie zostaną też cichcem "porwane" przez złośliwe oprogramowanie, ponieważ bardzo prędko rozgości się na nich systemowy Hyper-V. Niemniej...

Istnieje hipotetyczna, i nieco "przeterminowana" klasa ataków wykorzystujących VT-x, czyli zaprojektowany przez Joannę Rutkowską koncept Blue Pill. Chodzi w nim o zahostowanie głównego systemu operacyjnego jako instancji uruchomionej w mikro hypervisorze. Programy uruchomione w nim nie miałyby możliwości dowiedzieć się, że są wirtualizowane. Nadzorcy wirtualizacji zawsze przedstawiają się jako środowisko wirtualne... chyba, że są złośliwi.

Atak Blue Pill jest bardzo skomplikowany, jest też dziś "mniej niewykrywalny" niż kiedyś, a porwanie hypervisora jest znacznie trudniejsze niż kilka lat temu, ze względu na Hyper-V. Jednakże, nawet Microsoft miał wątpliwości, czy należy ignorować to zagrożenie. Warto jednak zwrócić uwagę na użyte argumenty: wykorzystanie owej metody ataku początkowo wymagałoby i tak praw tak wysokich, że już samo to jest krytycznym naruszeniem bezpieczeństwa. Problem zaczyna się więc wcześniej.

Przechodzimy niniejszym do zarządzania układami pomocniczymi. Czip z UEFI to bowiem niejedyna "dusza" zamieszkująca płytę systemową dzisiejszych komputerów. Sporo na niej dodatkowych układów, które często umieją więcej niż myślimy i więcej niż chcemy. Podstawowymi problemami są tutaj ataki z wykorzystaniem bezpośredniego dostępu do pamięci (DMA) oraz nadużycia interfejsów do zdalnego zarządzania. Mowa tu przede wszystkim o mitycznym Intel Management Engine. Zasługuje on na oddzielną część.

Spostrzegawczy czytelnik dostrzeże, że nie padła tu sugestia wyłączenia Hyper-Threadingu celem ochrony przed atakami opartymi o nadużycia kanału bocznego. Nie padły. Po to aktualizowaliśmy BIOS, żeby padać nie musiały 😀 Między innymi również dlatego aktualizowaliśmy system.