Luka w AppLockerze – drobny błąd, wielka dziura w zabezpieczeniach

kapitanhack.pl 10 godzin temu

Microsoft AppLocker od lat uchodzi za jedno z najbardziej precyzyjnych narzędzi kontroli aplikacji w systemach Windows. Umożliwia administratorom sieci wdrażanie reguł dotyczących uruchamiania plików wykonywalnych, skryptów, instalatorów i bibliotek DLL. W dużych środowiskach korporacyjnych to często jedna z podstawowych warstw zabezpieczeń stacji roboczych i serwerów. Niedawne odkrycie luki w mechanizmie wersjonowania pokazało jednak, iż choćby najlepiej zaprojektowany system może zawieść, jeżeli popełni się pozornie nieistotny błąd konfiguracyjny.

AppLocker – kontrola na poziomie jądra

AppLocker działa na poziomie jądra systemu Windows, blokując wykonanie plików, które nie spełniają określonych polityk. Można definiować reguły według lokalizacji, nazwy pliku, jego wersji, wydawcy (na podstawie podpisu cyfrowego) oraz hashów. Co ważne, AppLocker może działać zarówno w trybie „white-list” (biała lista – tylko dozwolone programy), jak i „black-list” (czarna lista – zakazane programy). Choć pierwsze podejście jest bezpieczniejsze, wielu administratorów stosuje drugie z powodu prostszej konfiguracji. To właśnie w takim scenariuszu ujawniła się luka.

Źródło problemu – literówka z dużymi konsekwencjami

Luka nie dotyczy samego kodu AppLockera, ale sposobu, w jaki Microsoft przedstawił przykładowe reguły XML w dokumentacji technicznej. Wartość MaximumFileVersion została ustawiona na błędne:

65355.65355.65355.65355

zamiast poprawnego maksymalnego zakresu wersji dla pliku PE (Portable Executable):

65535.65535.65535.65535

Pomimo iż różnica wynosi zaledwie kilkadziesiąt jednostek, konsekwencje są poważne – każda binarka, której wersja jest większa niż błędnie określony limit, nie będzie podlegała blokadzie, choć powinna. To otwiera pole do obejścia reguł zabezpieczających.

Jak wygląda obejście AppLockera w praktyce?

Atakujący może przygotować kopię dowolnego pliku wykonywalnego (np. PowerShell, CMD czy narzędzie zewnętrzne), który normalnie byłby przez AppLocker blokowany. Następnie zmienia w niej metadane wersji pliku na wartość pomiędzy 65355 a 65535 – czyli dokładnie w lukę pozostawioną przez błędną konfigurację. jeżeli system operacyjny nie wymusza podpisanych aplikacji, a AppLocker działa jedynie w trybie black-list, taka zmodyfikowana binarka uruchomi się bez przeszkód – skutecznie omijając zabezpieczenie.

Link do DEMO: https://www.varonis.com/blog/applocker-bypass-risks

Co sprawia, iż ten atak jest skuteczny?

Mechanizm AppLockera interpretuje wersję pliku z metadanych nagłówka pliku PE, a nie z podpisu czy innego źródła. To oznacza, iż manipulując wartościami w nagłówku, można oszukać mechanizm kontroli bez konieczności zmieniania adekwatnego kodu programu. Co więcej, niektóre narzędzia deweloperskie pozwalają łatwo ustawić wersję kompilowanego pliku – co może zostać wykorzystane przez złośliwe oprogramowanie lub osoby testujące zabezpieczenia w nieautoryzowany sposób.

Zagrożenie rośnie w środowiskach bez podpisów cyfrowych

AppLocker staje się bezbronny wobec tego typu obejścia, jeżeli nie skonfigurowano dodatkowego wymogu dotyczącego podpisu cyfrowego binarek. W trybie domyślnym AppLocker może polegać wyłącznie na regułach blokujących (np. na podstawie nazwy lub wersji pliku), co nie wystarcza, jeżeli wersję można tak łatwo zmanipulować. Tylko organizacje, które stosują strategię „only allow signed executables” – czyli tylko uruchamianie podpisanych cyfrowo aplikacji – są chronione przed tym atakiem.

Jak Microsoft zareagował na problem?

Po zgłoszeniu błędu przez badaczy z Varonis Microsoft zaktualizował dokumentację AppLockera, poprawiając wartość MaximumFileVersion do prawidłowej. Oznacza to jednak, iż przez wiele lat użytkownicy mogli nieświadomie wdrażać wadliwą konfigurację, kopiując oficjalny przykład XML z portalu Microsoft Docs. Co gorsza, niektóre poradniki firm trzecich również bazowały na tym błędzie, powielając go w swoich implementacjach.

Przykład większego problemu – zaufanie do dokumentacji

To nie pierwszy przypadek, gdy błędna dokumentacja prowadzi do realnych zagrożeń bezpieczeństwa. Administratorzy często wdrażają konfiguracje na podstawie przykładów z oficjalnych stron producenta – a nie każda z tych konfiguracji jest gruntownie testowana w środowiskach o wysokim poziomie ryzyka. Luka w AppLockerze to przypomnienie, iż każda linijka kodu, choćby XML, musi być traktowana z ostrożnością.

Zalecenia dla administratorów systemów Windows

Administratorzy powinni jak najszybciej:

  • Zrewidować istniejące reguły AppLocker – zwłaszcza te z MaximumFileVersion.
  • Zaktualizować wartość do 65535.65535.65535.65535 tam, gdzie dotąd używano błędnej.
  • Wprowadzić politykę tylko podpisanych plików wykonywalnych.
  • Zamiast czarnych list stosować podejście „white-listing” – czyli określać dokładnie, co wolno uruchomić.
  • Włączyć rejestrowanie logów AppLocker w Event Viewerze i regularnie je analizować – zdarzenia 8002, 8003 i 8004 są najważniejsze dla detekcji prób obejścia reguł.

Praktyczne konsekwencje dla bezpieczeństwa organizacji

Jeśli luka zostanie wykorzystana przez atakującego wewnętrznego (tzw. insider threat) lub malware, który potrafi manipulować wersją pliku PE, AppLocker może nie zatrzymać jego uruchomienia. To oznacza, iż systemy polegające wyłącznie na AppLockerze jako formie ochrony przed złośliwym oprogramowaniem, phishingiem lub nieautoryzowanymi narzędziami mogą nie zapewniać oczekiwanego poziomu bezpieczeństwa.

Luka w AppLockerze jako lekcja projektowania polityk bezpieczeństwa

Przypadek ten ilustruje szerszy problem – nie tylko w kontekście AppLockera, ale ogólnie polityk bezpieczeństwa opartych na listach kontrolnych i plikach konfiguracyjnych. choćby mały błąd w wartościach numerycznych może zmienić interpretację reguł i stworzyć niezamierzoną lukę. Organizacje powinny traktować polityki bezpieczeństwa jak kod – testować je, audytować i poddawać analizie ryzyka, zanim trafią na środowiska produkcyjne.

Checklista naprawcza

Co należy zrobić już teraz?

  • Sprawdź wszystkie reguły AppLocker zawierające MaximumFileVersion.
  • Zmień błędne wartości na 65535.65535.65535.65535.
  • Włącz reguły opierające się na podpisie cyfrowym (Publisher).
  • Rozważ pełne przejście na politykę white-listing.
  • Wprowadź skanowanie logów Event Viewer oraz automatyczne alerty na naruszenia.
  • Przeprowadź szkolenie zespołu IT z zakresu aktualizacji reguł i rozpoznawania ryzyk konfiguracyjnych.

Podsumowanie

W świecie bezpieczeństwa IT detale mają znaczenie. Luka w AppLockerze przypomina, iż choćby narzędzie sygnowane przez giganta takiego jak Microsoft może zostać osłabione przez zaledwie jedną wartość liczbową. To nie tylko ciekawostka techniczna, ale realne zagrożenie, które może zostać wykorzystane przez cyberprzestępców. Obrona wymaga nie tylko technologii, ale i dokładności, ciągłych testów oraz nieustannej czujności.

Idź do oryginalnego materiału