Ukazał się raport opisujący nową technikę ataku na systemy Windows zwaną „Windows Downdate”:

• przedstawiona technika pozwala na downgrade zainstalowanego oprogramowania do podatnych wersji, a następnie jego eksploitację
• oprogramowanie odpowiedzialne za integralność systemu i sprawdzanie aktualizacji nie wykazuje braków czy konieczności aktualizacji
• technika pozwala na zaatakowanie również bezpiecznych enklaw systemu Windows bazujących na Hyper-V
• atakujący może wykorzystać tę technikę do wyłączenia mechanizmów bezpieczeństwa i trwałego zbackdoorowania systemu oraz uzyskania dostępu do sekretów wykorzystywanych przez Secure Kernel (w tym pamięci procesów przechowujących poświadczenia)

Aktualizacje są jednym z kluczowych procesów pozwalających na zapewnienie bezpieczeństwa wykorzystywanych systemów. Kolejne poprawki mają na celu między innymi usunięcie podatności wykrytych od czasu wydania poprzedniej aktualizacji. Chociaż systemy operacyjne wciąż mają wiele do nadrobienia, to ich mechanizmy bezpieczeństwa oraz jakość kodu się poprawia. Jednak jak udowadnia Alon Leviev z SafeBreach, to, że Windows Update oraz narzędzia do enumeracji zainstalowanych łatek pokazują, że system jest w pełni aktualny… nie musi nic oznaczać. Dzięki zaprezentowanej technice ataku, możliwe jest skryte dokonanie downgrade’u (wycofania aktualizacji), aby ponownie wprowadzić do systemu znane podatności i wykorzystać je niczym 0-day. Tymczasem system będzie twierdził, że posiada wszystkie aktualizacje.

Czy to możliwe? Okazuje się, że tak. Opublikowany raport, który autor zaprezentował na tegorocznych konferencjach Black Hat i DEF CON, ukazuje dokładnie, jak wycofać i podmienić nowe oprogramowanie na stare, dziurawe. Badacz założył sobie, że pełny atak będzie musiał:

• być niewykrywalny przez systemy bezpieczeństwa takie jak EDR,
• być niewidoczny z punktu widzenia mechanizmów dbających o aktualność systemu (tzn. brak informacji o tym, że jakiś komponent wymaga <ponownej> aktualizacji),
• przeżywać rebooty i aktualizacje (tzw. persistence),
• być nieodwracalny (narzędzia do naprawy systemu nie powinny móc przywrócić poprawnych, zalatanych wersji oprogramowania); innymi słowy backdoor ma być „trwały” i zapewnić „persistence”. 

Z naszego punktu widzenia, wskazane założenia oraz fakt wykorzystania tak nieoczywistego wektora ataku, łamie dotychczas przyjęte wzorce w kontekście bezpieczeństwa aktualizacji. Integralność systemów operacyjnych będzie musiała zostać ponownie rozważona, z uwzględnieniem nowych technik. Opisywany problem dotyczy systemu Microsoft Windows, jednak, znając życie, jest wysoko prawdopodobne, że analogiczne techniki, będą mogły zostać zaadaptowane do innych OS-ów. 

Windows Update oraz TrustedInstaller

Usługa Windows Update odpowiada za instalację aktualizacji w systemie. Rozwiązanie bazuje na architekturze klient-serwer. Obydwa te komponenty komunikują się ze sobą z wykorzystaniem Component Object Model (w skrócie COM). Uproszczony schemat został przedstawiony na rysunku 1.

Rysunek 1. Uproszczony schemat budowy Windows Update (źródło: safebreach)

Warto zauważyć, że oba komponenty wymagają określonych uprawnień. Po stronie klienta wymagany jest poziom Administratora. Z drugiej strony proces serwera wymusza poziom TrustedInstaller. Zabieg ten ma na celu zapewnienie integralności systemu plików. Powoduje to, że procesy działające w kontekście AUTHORITY\NT SYSTEM oraz lokalnego Administratora nie są w stanie dokonać zmian w plikach. Może się to wydawać logicznym zabiegiem mającym na celu podniesienie bezpieczeństwa systemu. Jednak jak podkreśla Alon Leviev: Microsoft nie traktuje podniesienia uprawnień z Administratora do TrustedInstallera jako granicy bezpieczeństwa (security boundary). W przeszłości pojawiały się metody pozwalające na eskalację do poziomu TrustedInstallera. Są one jednak traktowane jako działanie złośliwe (nic dziwnego), więc wszelkie mechanizmy typu EDR będą flagować takie próby. 

Sam proces aktualizacji składa się z kilku etapów. W raporcie z badań przytoczony został ogólny schemat składający się z pięciu kroków (dla czytelności pominięte zostały niewykorzystywane w tym ataku etapy przygotowania plików z aktualizacjami, opis kompletnego cyklu aktualizacji jest dostępny w dokumentacji Microsoftu).

1. Klient wymusza przeprowadzenie aktualizacji przez komponent serwera – dostarcza pliki aktualizacji w katalogu.
2. Serwer dokonuje sprawdzenia integralności katalogu aktualizacji.
3. Komponent serwera dokonuje finalizacji struktury aktualizacji plików. Przenosi zawartość do miejsca w systemie plików, które wymaga działania w kontekście TrustedInstallera, powodując, że „zwykły” Administrator nie ma do nich dostępu.
4. Tworzony jest plik Pending.xml będący spisem działań, które mają zostać wykonane na systemie, np. które pliki powinny zostać podmienione na nowsze.
5. W momencie ponownego uruchomienia systemu, komponent odpowiedzialny za przeprowadzenie aktualizacji wykonuje zdefiniowane zadania aktualizując system.

W pierwszej kolejności racjonalnym, z punktu widzenia badacza bezpieczeństwa, jest spojrzenie na katalog zarządzany przez klienta, do przygotowania aktualizacji, wykorzystywany w pierwszym z przytoczonych kroków, ponieważ dostęp do niego wymaga jedynie uprawnień Administratora. 

Rysunek 2. Struktura katalogu aktualizacji. (źródło: safebreach)

Aktualizacje podzielone są na tzw. update components. W skład update components wchodzą: pliki z rozszerzeniem MUM przechowujące metadane, zależności czy kolejność instalacji, pliki manifestu przechowujące ścieżki w systemie plików czy też klucze rejestrów, delta files, czyli informacje o zmianach – przechowywanie tylko zmian redukuje narzut związany z transferem oraz przechowywaniem pełnej informacji o aktualizacji, Manifest oraz pliki MUM są podpisane, a podpisy przechowywane są w zabezpieczonych kryptograficznie plikach catalog (zazwyczaj z rozszerzeniem .cat). 

To, co zwróciło słuszną uwagę badacza, to fakt, że pliki różnicowe nie są podpisane oraz ich sygnatury nie znajdują się w plikach catalog. Ponadto to właśnie one definiują końcowy stan systemu po zainstalowaniu aktualizacji. Jednak wektor ten jest ograniczony przez to, że w podpisanym manifeście znajdują się kryptograficzne skróty plików delta, co wyklucza ich zmianę (zmiana zawartości pliku delta zmienia wartość funkcji skrótu umieszczonego w manifeście, edycja manifestu wymaga już poprawnego podpisu, którego atakujący raczej nie podrobi).

Podatność kryje się w innym miejscu. Okazuje się, że wspomniany wcześniej Pending.xml zawierający listę kroków do wykonania podczas aktualizacji, pozwala między innymi na: tworzenie, usuwanie i przenoszenie plików, dodawanie twardych dowiązań czy też wprowadzanie zmian w rejestrze. Zawartość Pending.xml jest chroniona przez wymaganie poziomu TrustedInstallera. Jednak w rejestrze systemu Alon znalazł klucz, który przechowuje binarkę parsującą (PoqExec.exe) oraz wszystkie parametry wywołania, w tym Pending.xml. Klucz ten (PoqexecCmdline) nie wymaga do zmiany kontekstu wbudowanego konta TrustedInstaller. 

Rysunek 3. Zaproponowany schemat ataku (źródło: safebreach)

Dokonując aktualizacji ścieżki Pending.xml, trzeba to zrobić tak, aby wskazywała ona na spreparowaną listę kroków, która de facto wprowadza stare podatności i pozwala obejść wszystkie kroki walidacji przeprowadzane przez system. W wyniku tego działania nie zachodzi potrzeba przeprowadzania eskalacji uprawnień z Administratora do TrustedInstallera. 

Atak wykorzystuje system aktualizacji, więc spełnia przytoczone wyżej założenia odnośnie wykrywalności, ukrycia faktu ataku czy też przeżywalności. Jeśli zaś chodzi o nieodwracalność, brak możliwości wycofania zmian, to autorowi badania udało się zauważyć, że narzędzie System File Checker (SFC.exe), służące do naprawiania uszkodzonych i uzupełniania brakujących plików, nie jest podpisane cyfrowo i można go po prostu spatchować. Piękna katastrofa, prawda? Inne elementy weryfikacji poprawności aktualizacji operują na Update Component, który nie był modyfikowany.

Na tym etapie atakujący, uzbrojony w mechanizm nazwany downdate, jest w stanie przywrócić starsze wersje oprogramowania w tym biblioteki DLL, sterowniki i – co gorsza – jądro systemu. 

"I then managed to downgrade critical OS components, including dynamic link libraries (DLLs), drivers, and even the NT kernel. After these downgrades, the OS reported that it was fully updated and was unable to install future updates, while recovery and scanning tools were unable to detect issues.„

Dalsza eskalacja

Microsoft nie rozpatruje eskalacji uprawnień przez Administratora do kernela jako przekroczenia granicy bezpieczeństwa, chociaż w rzeczy samej może ono powodować dodatkowe zagrożenia. Mitygacją wprowadzoną przez Microsoft było obniżenie uprawnień samego kernela systemu oraz wprowadzenie bezpiecznego komponentu, wyizolowanego wirtualnego środowiska, które staje się źródłem zaufania (root of trust) dla systemu przy dodatkowym założeniu, że sam kernel może być pod kontrolą atakującego. Rozwiązanie Virtualization-based Security (w skrócie VBS) wykorzystuje mechanizmy sprzętowej wirtualizacji oraz Hyper-V do stworzenia bezpiecznej enklawy implementującej mechanizmy bezpieczeństwa jak Credential Guard, czy przechowującej klucze. 

Rysunek 4. Schemat izolacji wprowadzonej przez VBS (źródło: microsoft)

VBS wprowadza hierarchiczne poziomy zaufania – Virtual Trust Levels (w skrócie VTLs), które odpowiadają za separację przetwarzania. Wprowadzono je w Windows 10 jako Virtual Secure Mode (VSM). VTL0 jest najmniej zaufanym, najmniej uprzywilejowanym poziomem, a np. VTL2 jest bardziej uprzywilejowany niż VTL1. Chociaż obecnie system Windows ma obsługiwać 16 takich poziomów, to obecnie tylko dwa są zaimplementowane (VTL0 i VTL1).

W VTL0 działa system operacyjny, poziom ten nazywany jest Normal Mode. 

Rysunek 5. Architektura rozwiązania VBS oraz poziomy VTL0 i VTL1 (źródło: safebreach)

Rysunek 5 przedstawia schemat działania izolacji przy zastosowaniu VTL. Bardziej szczegółowo mechanizm ten został zaprezentowany w dokumentacji Microsoftu.

Rysunek 6. Diagram prezentujący Isolated User Mode (źródło: microsoft)

W klasycznym modelu (lewa strona rysunku 6) przetwarzanie kodu z User Mode odbywa się w ringu 3, a Kernel Mode w ringu 0. Ring 3 może się komunikować z ring 0 przy pomocy wywołań funkcji systemowych (syscall). Podział na VTL implementowany przy pomocy Hyper-V pozwala dodatkowo wydzielić pamięć chronioną przed VTL0 przejętym (ang. compromised) kernelem działającym w VSM Normal Mode. 

Wyłączenie VBS nie jest możliwe poprzez prostą edycję wartości w rejestrze, ponieważ w takim przypadku skuteczność tego rozwiązania byłaby naprawdę niska. Dlatego konfigurację chroni UEFI lock, który do wyłączenia wymaga edycji ustawień EFI oraz fizycznego dostępu do komputera podczas procesu bootowania. 

Rysunek 7. VBS wyłączyć można przy użyciu EFI, jeśli włączony jest UEFI Lock (źródło: safebreach)

Założenia mechanizmu są słuszne, jednak brakuje pewnego istotnego szczegółu. Mianowicie chodzi o postępowanie w przypadku wykazania niepoprawności binariów odpowiedzialnych za implementację tego mechanizmu (np. pliki Hyper-V albo secure kernela). SafeBreach dowiódł, że w przypadku podmiany kluczowych plików wykonywalnych (przy pomocy mechanizmu downdate), proces bootowania systemu zamiast przejść do trybu recovery, poprawnie uruchamia system z wyłączonym mechanizmem VBS. Technika ta całkowicie obchodzi zabezpieczenia UEFI Lock (rysunek 8). 

Rysunek 8. Skutki podmiany pliku SecureKernel.exe (źródło: safebreach)

Autor researchu mógł tym sposobem wyciągnąć poświadczenia przechowywane w Credential Guard, który wykorzystuje mechanizm VBS do izolacji. Oprócz obejścia CG, Leview pokonał też mechanizm Protected Process Light (PPL), który uniemożliwia zabicie niektórych chronionych procesów, nawet z wykorzystaniem uprawnień administratorskich. Jest to kolejne zabezpieczenie implementujące izolację ze względu na poziomy. 

Rysunek 9. Uproszczony diagram poziomów PPL (źródło: elastic.co)

PPL jest mechanizmem, który chroni między innymi Local Service Authority. Wycofując patch na podatność o nazwie PPLFault, udało się zrzucić pamięć procesu lsass.exe. 

Rysunek 10. Spatchowany PPL nie dopuszcza do utworzenia dumpa procesu lsass.exe (źródło: safebreach)

"I bypassed these settings by first reverting the PPLFault patch to allow PPL bypass. Second, I disabled Credential Guard, bypassing the UEFI locks by invalidating the Secure Kernel. Finally, I made Windows Defender non-functional by invalidating MsMpEng, the main Defender executable."

Na końcu udało się również doprowadzić do wyłączenia mechanizmu Defendera przez nadpisanie głównej binarki antywirusa. 

Reasumując, na tym etapie atakujący ma pełną kontrolę nad systemem, wyłączone mechanizmy izolacji, wprowadzone znane podatności (które zostały uprzednio załatane, ale łatki i aktualizacje zostały wycofane), wyłączony antywirus, a narzędzia systemowe nie wykazują konieczności aktualizacji. Z punktu widzenia administratora jest to bardzo smutny obraz rzeczywistości. 

Hakowanie VBS

Chociaż wyżej przedstawiony scenariusz wygląda bardzo źle z punktu widzenia bezpieczeństwa i integralności systemu, to Alon poszedł o krok dalej, sprawdzając ograniczenia mechanizmu Virtualization-based Security. 

Na początku, przy pomocy ponownego wdrożenia podatności CVE-2022-34709 udało się uzyskać dostęp do User Mode w VTL1, będąc administratorem w User Mode (ring 3) w VTL0 (rysunek 11). 

Rysunek 11. Przeskoczenie z VTL0 do VTL1 (źródło: safebreach)

Credential Guard działa w User Mode w VTL1, więc procesy VTL0 (lsass.exe) nie mają dostępu do VTL1, gdzie działa Lsalso.exe zawierający faktyczne, niezaszyfrowane sekrety. Stąd zrzucenie pamięci procesu LSASS-a nie daje oczekiwanych wyników. 

Znów mechanizm downdate okazał się skuteczny, system Windows nie ma zaimplementowanej skutecznej metody na sprawdzenie wersji software uruchamianego w uprzywilejowanym VTL-u. 

Wykorzystując inne znane podatności, jak na przykład CVE-2021-27090 (rysunek 12), oraz dokonując downgrade Hyper-V (binarka Hvix64.exe), udało się również zaatakować hypervisor odpowiadający za bezpieczeństwo mechanizmu VBS (rysunek 13). 

Rysunek 12. Schemat przedstawiający atak na ring 0 w VTL1. (źródło: safebreach)

Rysunek 13. Schemat przedstawiający atak na Hyper-V poniżej ring 0 (tzw. ring -1)

Kontrolując hypervisor, atakujący jest w stanie zrobić dosłownie wszystko. To jeden z najbardziej dotkliwych ataków, jakie można sobie wyobrazić na bezpieczną enklawę, jaką jest VBS. 

Microsoft przyjął zgłoszenie w lutym 2024 i przypisał dwie podatności. 

• CVE-2024-21302 – na podniesienie uprawnień do Secure Kernel
• CVE-2024-38202 – na podniesienie uprawnień przez downdate, wykorzystując Windows Update

Dodatkowo opublikowane zostało advisory.

Podatności przedstawione przez Alona Levieva w ataku na w pełni spatchowany i aktualny system wykazują, że raz naprawione luki mogą powrócić i zadziałać niczym podatności typu 0-day i to bez wzbudzania zbyt dużych podejrzeń po stronie osób zajmujących się utrzymywaniem i monitorowaniem systemów. 

Mamy wrażenie, że dyskusja o bezpieczeństwie i patchowaniu systemów w rozumieniu, jakie było w środowisku powszechne do dzisiaj, dopiero się rozpoczyna. Świadomość możliwości podmiany kluczowych elementów systemu na starsze i podatne, powoduje, że rozgrywka pomiędzy atakującym, posiadającym już przyczółek w systemie, tak naprawdę przeniesie się na jeszcze wyższy poziom. 

Przedstawione badanie pokazuje też problemy, z jakimi borykają się systemy operacyjne. Przykładem tutaj była rodzina Windows, jednak nie jest wykluczone, że podobne zabiegi atakujący może wykonać też na innych systemach. A to powoduje, że należy dokładnie zaadresować problem wersjonowania i sprawdzenie integralności procesów aktualizacji. 

Optymizmem nie napawa również separacja gwarantowana przez mechanizmy bazujące na wirtualizacji. Nie jest to problem stricte tego ostatniego, ale sposobu, w jaki na ślepo dziedziczone jest zaufanie do uruchamianego kodu. 

Autorowi gratulujemy bardzo ciekawego znaleziska. Z niecierpliwością czekamy na nagrania talków z konferencji dotykających tego tematu. Mamy nadzieję, że przedstawiony raport będzie natchnieniem dla innych, aby zgłębić mechanizmy aktualizacji systemów oraz problemów, jakie mogą one wnosić do ekosystemu. Warto zauważyć, że nie jest to pierwszy raz, kiedy downgrade wprowadza załatane wcześniej błędy. Takim działaniem wykazywał się BlackLotus, o którym pisaliśmy jakiś czas temu.

Update 28.08.2024 – na portalu GitHub zostało opublikowane narzędzie do automatyzacji omawianego ataku, dostępne jest pod tym linkiem.

~fc