Sprzętowe zabezpieczenia PC, czyli komputer to nie tylko software

Pomijając na chwilę to, w jakim stopniu nowe wymagania sprzętowe są zmową Redmond z Intelem lub sprytnym sposobem na ukrycia rosnącego apetytu Okienek na rdzenie i pamięć, przyjrzyjmy się, jakie są oczekiwania Windows 11 względem sprzętu - mowa o tym, przy których nie tylko mówi o niespełnionych zależnościach, ale i nie marudzi w mniej znanych miejscach, jak Centrum Zabezpieczeń i Dziennik Zdarzeń.

Pierwsze miejsce, do którego należy w tym celu zajrzeć, to Windows Defender (czy też Microsoft Defender, w miejscach gdzie poprawnie go przemianowano). W zasadzie wszystkie nowe wymagania Jedenastki były oczekiwane przez Defendera już od lat i po prostu z opcjonalnych, stały się obowiązkowe. Chodzi tu o TPM, Secure Boot i HVCI.

TPM to układ kryptograficzny, obecnie już zintegrowany z platformą i nieistniejący jako oddzielny chip, odpowiedzialny za przechowywanie kluczy i dokonywanie "pomiarów". Gdy aplikacje korzystają z sekretów, jak hasła, klucze i tokeny, obecność danych wrażliwych w pamięci czyni ja podatnymi na ataki zrzucające i przeszukujące zawartość RAM. Zamiast tego, dostawca kryptografii systemowej ładuje je do TPM, dzięki czemu nie są obecne w pamięci w jednym kawały nawet, gdy są w użyciu.

Druga ważna funkcja TPM to narzędzie pomiarowe. "Pomiary" o których mowa to cechy charakterystyczne procesu uruchamiania systemu, które mają być identyczne między rozruchami. Jeżeli podczas uruchamiania Windows okaże się, że nowy pomiar TPM nie zgadza się ze starym, platforma zabezpieczeń zakłada, że zawartością dysku manipulowano między restartami (np. wykręcono go i wstawiono gdzie indziej, celem zainfekowania).

Gdy wykryta zostaje taka sytuacja, TPM oznacza system jako "brudny". Jeżeli dysk pokryty jest szyfrowaniem BitLockera, system nie uruchomi się i poprosi o klucz odblokowujący, ostrzegając tym samym użytkownika, że z jego komputerem stało się coś niedobrego.

Kolejne wymaganie to Secure Boot. Ten wiekowy, kiepsko zarządzany i dość dziurawy mechanizm pozwala upewnić się, że uruchamiany bootloader jest podpisany przez któregoś z "zaufanych" dystrybutorów z zamkniętej listy lub dysponuje podpisem ręcznie (i interaktywnie!) dodanym do listy kontrolnej. Secure Boot skutecznie chroni przed zagrożeniami, których sedno jest możliwe do osiągnięcia mniej skomplikowanymi drogami, ale w pewnym stopniu chroni przed załadowaniem złośliwego jądra (np. z wbudowanym keyloggerem) - choć i to da się w pewnym stopniu obejść…

Secure Boot wymaga (w praktyce) UEFI. Płyta instalacyjna Windows 11 w dalszym ciągu, nie wiedzieć czemu, zawiera wciąż dwa bootloadery - jeden dla BIOS i drugi dla UEFI - ale teoretycznie obsługiwana jest tylko "nowa" metoda, czyli UEFI.

Skoro Secure Boot chroni przed załadowaniem złośliwego jądra, a podpisany kernel Windows pozwala tylko na ładowanie podpisanych sterowników, kolejną warstwą ochrony jest zatem zabezpieczenie przed sterownikami, które istotnie są podpisane, ale okazują się być niebezpieczne/podatne na nadużycia (ewentualnie po prostu podpisano je kradzionym kluczem). Do tego służy mechanizm izolacji rdzenia opartej o wirtualizację (HVCI, HyperVisor-protected Core Isolation).

HVCI to tak naprawdę cztery rzeczy, które inaczej nazywają się w materiałach marketingowych, a inaczej w dokumentacji technicznej. W taki sposób otrzymujemy następujące elementy:

• Ochrona integralności kodu, kiedyś zwana Device Guard. Mechanizm ten wrzuca silnik podsystemu CFG - Control Flow Guard (znowu "Guard"…) w środowisko wirtualne, niemożliwe do modyfikacji. Ponieważ CFG pilnuje, skąd może być wykonywany kod, wirusy usiłujące ukryć się przed wykrywaniem przepełnień bufora, najpierw zaczynały od… zmodyfikowania CFG cele zmylenia. Izolacja rdzenia ma temu zapobiec.

• System Guard, znany także pod nazwą Secure Launch (nie mylić z Secure Boot). Mechanizm ten sprawdza, retroaktywnie, czy ścieżka uruchamiania, z której wystartowano system, nie zawierała po drodze blobów binarnych ani podejrzanych konfiguracji, uznawanych na potencjalnie niebezpieczne. Teoretycznie jego celem jest ochrona przed złośliwym firmware i atakami na samo UEFI. Technologia ta czeka dopiero na swój moment.

• Credential Guard, który robi to samo, co Device Guard, ale nie dla mechanizmu CFG, a LSA. Innymi słowy, wrzuca w chronione środowisko wirtualne podsystem Windows przechowujący hasła. Ma to chronić przed złośliwym oprogramowaniem zrzucającym stan pamięci procesu LSASS celem wyciągnięcia z niego poświadczeń. Dzięki nim, może się rozpowszechniać w uwierzytelniony sposób w sieciach firmowych, co stanowi zagrożenie dla domen Active Directory.

• Ochrona DMA, umożliwiająca podstawową obronę przez atakami wykorzystującymi bezpośredni dostęp do pamięci (czyli właśnie DMA, direct memory access). Polega ona na blokowaniu tych urządzeń stosujących DMA, których sterowniki nie ograniczają bezpośredniego dostępu do pamięci tylko do "swojej" pamięci.

Jeżeli sterownik nie zapewnia takiego mechanizmu, DMA dla jego urządzenia zostanie odcięte. Chroni to przed atakiem, gdy system jest już uruchomiony. Ochrona etapu przed rozruchem systemu (jak np. ręczne aprobowanie podpiętych urządzeń Thunderbolt) powinna być zapewniona przez UEFI. Bywa, że domyślnie jest wyłączona.

Choć rozważania na temat DMA brzmią jak stare dzieje, porty takie, jak Thunderbolt - ze względu na wydajność, robiącą zresztą wrażenie - zapewniły bezpośredni dostęp do pamięci urządzeniom, które można niepostrzeżenie wpiąć w port, gdy akurat nikt nie patrzy. Definiuje to całą gamę zagrożeń na nowo.

Ochrona oparta o wirtualizację wymaga od procesora obsługi mechanizmów pozwalających na szczegółowe flagowanie kodu wykonywalnego, takich jak MBEC. Pojawiły się one w siódmej generacji procesorów. Ale w parze z nimi potrzebne są też zgodne sterowniki, które Intel dostarczył dopiero dla ósmej generacji i nowszych. Wtedy też układ TPM 2.0 był już obowiązkowym składnikiem platformy.

Skoro Windows 11 uczynił pewne dawne opcjonalne zabezpieczenia obowiązkowymi, należy oczekiwać że jego następca uczyni to samo z tymi, które są opcjonalne dzisiaj. Jedną z takich opcji jest sprzętowa ochrona stosu (HSP, czyli Hardware-enforced Stack Protection - implementacja intelowskiego CET). Wprowadzono je w kwietniu 2021 wraz z jedenastą generacją procesorów Intela. Jeżeli obecne tempo zostałoby utrzymane, wpisanie CET do wymagań nastąpiłoby na przełomie lat 2025/2026.