BYOVD bez sprzętu: podatne sterowniki Windows nadal mogą być osiągalne i groźne

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Technika BYOVD, czyli Bring Your Own Vulnerable Driver, polega na wykorzystaniu legalnie podpisanego, ale podatnego sterownika systemu Windows do uzyskania dostępu na poziomie jądra, eskalacji uprawnień lub obejścia mechanizmów ochronnych. Najnowsze analizy pokazują, że część takich sterowników może pozostać dostępna z poziomu user mode nawet wtedy, gdy w systemie nie ma fizycznego urządzenia, dla którego zostały zaprojektowane.

To istotna zmiana w postrzeganiu ryzyka. Dotychczas brak sprzętu często uznawano za naturalną barierę ograniczającą możliwość wykorzystania luki. W praktyce okazuje się jednak, że sposób inicjalizacji sterownika, logika Plug and Play oraz tworzenie obiektów urządzeń mogą pozwolić na osiągnięcie podatnej ścieżki kodu również bez obecności odpowiadającego mu hardware.

W skrócie

Badacze opisali, w jaki sposób oceniać, czy podatny sterownik Windows da się wykorzystać bez podłączonego urządzenia. Kluczowe znaczenie ma to, czy sterownik tworzy obiekt urządzenia bezwarunkowo, warunkowo czy dopiero po enumeracji sprzętu przez mechanizmy PnP.

Brak fizycznego urządzenia nie zawsze eliminuje możliwość eksploatacji sterownika.
Istotne są szczegóły implementacyjne, a nie tylko sama klasa podatności.
Atakujący mogą próbować sztucznie odtworzyć warunki inicjalizacji sterownika.
BYOVD pozostaje ważnym narzędziem do obchodzenia EDR, self-protection i eskalacji uprawnień.

Kontekst / historia

BYOVD od lat jest jednym z najważniejszych wektorów post-exploitation w środowisku Windows. Atakujący wykorzystują legalne i podpisane sterowniki z lukami, ponieważ kod wykonywany w kernel mode daje możliwości niedostępne dla zwykłych procesów użytkownika. W praktyce obejmuje to między innymi arbitralny odczyt i zapis pamięci, manipulację uchwytami, kończenie procesów oraz obchodzenie mechanizmów integralności i ochrony narzędzi bezpieczeństwa.

Przez długi czas analiza ryzyka koncentrowała się głównie na rodzaju podatności, na przykład na tym, czy dany sterownik umożliwia arbitrary kernel read/write. Mniej uwagi poświęcano temu, czy podatny kod jest faktycznie osiągalny na konkretnym systemie. Najnowsze badania przesuwają punkt ciężkości właśnie na exploitable path, czyli realną możliwość uruchomienia podatnej funkcjonalności w środowisku, w którym nie występuje dedykowany sprzęt.

Z perspektywy obrony ma to duże znaczenie. Microsoft rozwija mechanizmy ograniczające uruchamianie znanych podatnych sterowników, w tym rekomendowane reguły blokowania oraz ochrony związane z integralnością kodu. Mimo to ekosystem Windows nadal zawiera dużą liczbę starszych, niszowych lub historycznych sterowników, które mogą zostać wykorzystane przez operatorów ransomware i grupy intrusion do realizacji działań na poziomie jądra.

Analiza techniczna

Sedno problemu sprowadza się do pytania, kiedy i w jaki sposób sterownik tworzy device object oraz czy jego logika inicjalizacji wymaga obecności konkretnego urządzenia. W najprostszym wariancie sterownik tworzy obiekt urządzenia już podczas wykonania procedury inicjalizacyjnej. W takiej sytuacji samo załadowanie sterownika może wystarczyć, aby proces użytkownika uzyskał dostęp do interfejsu I/O i wywoływał żądania prowadzące do wykonania podatnego kodu.

Częściej spotykany jest jednak model warunkowy. Sterownik może sprawdzać określone klucze rejestru, artefakty instalacyjne, stan środowiska lub oczekiwać, że odpowiednia ścieżka zostanie aktywowana przez Plug and Play. W sterownikach PnP kluczową rolę odgrywają mechanizmy takie jak AddDevice, obsługa żądań PnP oraz tworzenie obiektów urządzeń funkcyjnych i filtrujących. To właśnie w tych momentach mogą powstawać struktury i interfejsy niezbędne do późniejszego wywołania podatnej funkcji.

Z punktu widzenia exploitability oznacza to, że sam plik sterownika nie zawsze stanowi natychmiastową ścieżkę ataku. Atakujący może jednak próbować doprowadzić do spełnienia warunków inicjalizacji. Jedną z metod jest utworzenie programowo emulowanego urządzenia z odpowiednim identyfikatorem sprzętowym, tak aby system skojarzył sterownik z nowym węzłem urządzenia. Innym podejściem może być manipulacja logiką filtrowania lub stosem urządzeń w celu osiągnięcia pożądanego fragmentu kodu bez fizycznego hardware.

W części przypadków dostępność interfejsu I/O może być krótkotrwała. Sterownik może utworzyć obiekt urządzenia, a następnie usunąć go po wykryciu braku zgodnego sprzętu. Taka sytuacja tworzy bardzo wąskie okno czasowe przypominające race condition, ale z perspektywy ofensywnej nadal może wystarczyć do wysłania odpowiednio przygotowanego żądania DeviceIoControl.

Dodatkowym utrudnieniem dla atakującego jest aktywne odpytywanie sprzętu. Jeżeli sterownik wykonuje rzeczywiste operacje komunikacyjne z magistralą lub urządzeniem końcowym, emulacja staje się bardziej złożona. Nie oznacza to jednak automatycznie, że wykorzystanie luki jest niemożliwe. W niektórych przypadkach wystarcza częściowa inicjalizacja i samo wystawienie osiągalnego obiektu urządzenia.

Konsekwencje / ryzyko

Najważniejszy wniosek jest praktyczny: podatność sterownika nie przestaje być istotna tylko dlatego, że dane urządzenie nie jest podłączone do komputera. Jeśli napastnik może załadować podatny sterownik i doprowadzić do utworzenia dostępnego interfejsu I/O, zyskuje potencjalny kanał do wykonywania operacji jądrowych, wyłączenia mechanizmów ochronnych lub lokalnej eskalacji uprawnień.

To wpływa na sposób priorytetyzacji zagrożeń. W wielu organizacjach przyjmuje się, że specjalistyczne sterowniki sprzętowe stanowią ryzyko wyłącznie na stacjach, na których faktycznie występuje określone urządzenie. Opisana perspektywa pokazuje, że ekspozycja może obejmować znacznie szerszy zakres systemów, jeżeli możliwe jest sztuczne odtworzenie warunków inicjalizacji sterownika.

Ryzyko rośnie szczególnie wtedy, gdy atakujący ma już uprawnienia administratora lokalnego. W takim scenariuszu BYOVD staje się narzędziem do przejścia z kontekstu administracyjnego do operacji w jądrze, neutralizacji EDR, ukrycia aktywności i przygotowania środowiska pod kolejne etapy ataku. Jest to model dobrze znany z nowoczesnych kampanii ransomware oraz działań grup wykorzystujących signed drivers do obejścia zabezpieczeń endpointów.

Rekomendacje

Organizacje powinny traktować sterowniki jako wysokowartościową powierzchnię ataku niezależnie od tego, czy odpowiadające im urządzenia fizycznie występują w środowisku. Inwentaryzacja powinna obejmować nie tylko aktywne urządzenia, ale również zainstalowane pakiety sterowników, usługi kernel mode, elementy driver store oraz historyczne pozostałości po oprogramowaniu producentów.

Włączyć i egzekwować listy blokowania znanych podatnych sterowników.
Utrzymywać ochrony integralności kodu, w tym mechanizmy takie jak HVCI, tam gdzie pozwala na to zgodność środowiska.
Ograniczać możliwość ładowania nowych sterowników przez ścisłą kontrolę uprawnień administracyjnych i polityki application control.
Monitorować tworzenie oraz uruchamianie usług typu kernel driver.
Wykrywać nietypowe użycie narzędzi i interfejsów związanych z instalacją sterowników, takich jak sc.exe, INF i SetupAPI.
Korelować zdarzenia dotyczące tworzenia urządzeń programowych i zmian w stosach urządzeń.
Porównywać lokalne sterowniki z publicznymi bazami known vulnerable drivers oraz komponentów nadużywanych w incydentach.

Z perspektywy SOC i DFIR warto rozszerzyć detekcję o sytuacje, w których w systemie pojawia się sterownik producenta urządzeń nieużywanych w organizacji. Podejrzane mogą być także krótkotrwałe obiekty urządzeń, nietypowe wywołania DeviceIoControl kierowane do sterowników firm trzecich oraz zdarzenia blokowania przez polityki integralności kodu.

Dla zespołów hardeningowych ważne jest również testowanie odporności na BYOVD w warunkach laboratoryjnych. Sama obecność podatnego sterownika na dysku lub w magazynie sterowników powinna być traktowana jako potencjalny problem bezpieczeństwa, szczególnie jeśli dany komponent figuruje na listach znanych podatnych sterowników albo ma historię nadużyć w realnych operacjach ofensywnych.

Podsumowanie

Analiza osiągalności podatnych sterowników bez fizycznego sprzętu pokazuje, że realna powierzchnia ataku BYOVD jest szersza, niż zakładano w uproszczonym modelu opartym wyłącznie na obecności urządzenia. O możliwości wykorzystania luki decydują przede wszystkim szczegóły implementacyjne: moment tworzenia device object, zależność od PnP, warunki inicjalizacji i ewentualna potrzeba aktywnej komunikacji ze sprzętem.

Dla obrońców oznacza to konieczność odejścia od założenia, że brak hardware automatycznie neutralizuje zagrożenie. Skuteczna strategia ochrony wymaga blokowania znanych podatnych sterowników, kontroli ładowania kodu jądra, monitorowania nietypowych instalacji driverów oraz regularnego usuwania zbędnych komponentów kernel mode z systemów Windows.