Błąd w Windows Defender umożliwiający eskalację uprawnień do SYSTEM!

Stare rozszerzenia plików furtką do ataków dla cyberprzestępców

Problem tkwi w mechanizmie sprawdzania załączników, a dokładniej związany jest z uszkodzeniem pamięci w złożonym unpackerze (w tym przypadku stara wersja ASProtect z lat 90-tych), który nie radzi sobie z poprawnym przeskanowaniem starych plików. Antywirusy cały czas są nękane przez takie problemy.

Jak twierdzi Travis:

„Podobnie jak w przypadku wszystkich programów antywirusowych, program Windows Defender Antivirus zawiera kod do dekompresji i badania tysięcy różnych formatów plików. Obejmują one wszystko, od popularnych formatów, takich jak ZIP i RAR, po mało znane formaty, takie jak ZOO, które były popularne w latach 80-tych wśród użytkowników Amigi. Oprócz plików archiwów program Windows Defender próbuje również rozpakować pliki wykonywalne. Rozpoznawane są setki różnych exe-packer’ów, często nie były one używane od ponad 30 lat i kompresują tylko 16-bitowe pliki COM MS-DOS, których nie można uruchomić na współczesnej maszynie x86_64.”

W roku 2018 Microsoft ogłosił plany utworzenia piaskownicy (sandbox) Windows Defender, ale niestety plany nigdy nie przekształciły się w rzeczywistość. Oznacza to, że wszystkie te parsery, programy rozpakowujące, interpretery i emulatory formatu plików nadal działają jako SYSTEM i są łatwo dostępne zdalnie dla atakujących.

Jest też możliwy taki scenariusz, że otrzymanie wiadomości e-mail może skutkować uruchomieniem malware- nawet bez konieczności jej czytania. Wystarczy, aby wykorzystać jakąkolwiek lukę. Poniżej prezentujemy źródło problemu odkrytego w Defender przez Travisa w exepakerze ASProject.

Co to jest ASProtect?

ASProtect jest skomplikowanym, wieloetapowym exepackerem zaprojektowanym, aby utrudnić inżynierię wsteczną. Jeden z etapów rozpakowywania obejmuje wykonanie kodu bajtowego osadzonego w pliku wykonywalnym. Aby zinterpretować ten kod bajtowy, paker szyfruje i osadza bibliotekę DLL zawierającą maszynę wirtualną.

Zamiast próbować interpretować i analizować ten skomplikowany plik, Microsoft używa popularnej sztuczki, po prostu uruchamia spakowany plik wykonywalny w emulatorze i pozwala mu się rozpakować. Nie jest to jednak takie proste, spakowany kod oczekuje, że osadzona biblioteka DLL będzie dostępna, więc Microsoft wykrywa, kiedy ASProtect został użyty i odszyfrowuje osadzoną bibliotekę DLL, aby udostępnić ją w emulatorze.

Ormanty odkrył, że to wciąż za mało, ponieważ „biblioteka DLL jest sama spakowana i musi zostać zrekonstruowana. Sama biblioteka DLL zwykle nie jest interesująca ani złośliwa, ponieważ jest częścią środowiska wykonawczego ASprotect, a nie (potencjalnie złośliwym) spakowanym plikiem wykonywalnym. Jednak nie jest podpisany, więc nie ma powodu, dla którego nie można było utworzyć własnej biblioteki DLL środowiska uruchomieniowego.”

Co zaskakujące, jak twierdzi Travis, Microsoft nigdy nie rozważał takiej możliwości, a kod dodający bibliotekę DLL środowiska wykonawczego do wirtualnego systemu plików emulatorów ma bardzo małą walidację.

Kod pochodzi z CEmbededDLLDumper::GenerateDLL (jest to ostatnia wersja z dostępnymi symbolami, 1.1.16800.2. Niestety Microsoft przestał publikować symbole dla nowszych wersji, co utrudnia kontrolę bezpieczeństwa).

Powyższy kod wyraźnie ufa „RelativeVirtualAddress” określonemu przez wbudowaną bibliotekę DLL, umożliwiając mu odczytywanie i zapisywanie w dowolnym przesunięciu z „ImageBase”. Sekcja RVA jest używana bezpośrednio z biblioteki DLL środowiska wykonawczego bez żadnej walidacji i używana jako przesunięcie do bufora. Powoduje to odczyt lub zapis do dowolnego przesunięcia. Co ciekawe, ponieważ ta luka tkwi w kodzie konfigurującym emulowanego środowiska, oznacza to, że emulowany kod może odczytywać lub zapisywać pamięć poza emulatorem.

Stwarza to ogromne możliwości do napisania specjalnego kodu – eksploit’a, który może wykorzystać atakujący do uruchomienia własnego programu lub kodu na najwyższych uprawnieniach systemowych. >

Co dalej?

Obecnie Travis pracuje nad utworzeniem exploit’a, natomiast odkryta przez niego luka zgodnie z polityką zgłaszania błedów, podlega 90-dniowemu terminowi ujawnienia. Jeśli Microsoft naprawi w wyznaczonym terminie odkryty błąd, dopiero wówczas zostaną ujawnione dalsze szczegóły luki (zostaną upublicznione 30 dni po wprowadzeniu poprawki fix). W przeciwnym razie zostanie opublikowany w wyznaczonym terminie raport o błędzie. Miejmy nadzieję, że Microsoft zdąży uporać się z powyższym problemem oraz gratulujemy Travisowi kolejnego odkrycia.