W Internecie pojawił się (na chwilę) artykuł opisujący eksploit RCE wraz z kodem źródłowym na lukę Windows związaną z błędną obsługa linków powiązań do folderów usługi WER, w którym autor pokazuje jak ze zwykłego użytkownika można zdobyć najwyższe uprawnienia systemowe. Niestety artykuł szybko został usunięty z sieci. Zdążyliśmy wcześniej dotrzeć do jego źródła i opisać go dla Was.
Autorem eksploit jest Jonas L. z Secret Club. W swoim artykule z dnia 23 kwietnia 2020 roku opisał sposób na przejęcie najwyższych uprawnień systemowych z poziomu zwykłego użytkownika. Cały post znajdował się na stronie secret.club, lecz z niewiadomych powodów szybko został skasowany.
Może jednym z powodów jego usunięcia były obawy firmy Microsoft przed nieuczciwymi intencjami cyberprzestępców? Kto wie?…W każdym bądź razie zredagowaliśmy go i sprawdziliśmy poniżej.
Luka w usłudze Windows powodem do napisania eksploit
Luki w zabezpieczeniach, które umożliwiają nieuprzywilejowanemu użytkownikowi spowodowanie, że usługa (działająca w kontekście NT AUTHORITY\SYSTEM) usuwa dowolny katalog / plik, nie są rzadkim zjawiskiem. Podczas poszukiwań luki te są w większości ignorowane przez badaczy bezpieczeństwa, ponieważ nie ma ustalonej ścieżki do eskalacji uprawnień za pomocą tak prymitywnej techniki. Badacz Jonas przez przypadek znalazł taką ścieżkę, używając przypadkowo odkrytej luki w usłudze raportowania błędów systemu Windows – Windows Error Reporting Service.
Czym jest WER?
Zapewne zetknęliście się niejednokrotnie z problemem, kiedy podczas Waszej pracy „wysypała” się Wasza aplikacja i Windows prosił o przesłanie informacji do Microsoft celem jego dalszej analizy. Za takie przypadki w Windows odpowiedzialna jest usługa WER (Windows Error Reporting). Celem jej jest raportowanie błędów systemu Windows – zebranych danych telemetrycznych po awarii aplikacji.
Usługa WER jest podzielona na dwa moduły. Moduł trybu użytkownika i komponent usługi, który komunikuje się przez COM po ALPC. Raporty o błędach są tworzone, ustawiane w kolejce i dostarczane przy użyciu systemu plików jako tymczasowa pamięć.
Pliki usługi WER przechowywane są w podfolderach w ścieżce na dysku: „C:\ProgramData\Microsoft\Windows\WER”. Są w niej foldery:
- Temp służy do przechowywania zebranych danych o awariach z różnych źródeł, zanim zostaną scalone w jeden plik.
- ReportQueue jest używany, gdy raport jest gotowy do dostarczenia na serwery Microsoft. Jeśli dostarczenie raportu nie jest możliwe z powodu problemów lub braku połączenia z Internetem, próba dostawy zostanie podjęta później i dostarczona, jeśli pozwolą na to warunki.
- ReportArchive to historyczne archiwum dostarczonych raportów.
Na czym polega wykorzystanie luki w Microsoft WER?
W celu umożliwienia dowolnej aplikacji powodującej awarię dostarczenie danych do firmy Microsoft, system Windows posiada ustawione odpowiednie uprawnienia NTFS do powyżej wymienionych folderów. Tworzone w podfolderach pliki i foldery specyficzne dla awarii mogą mieć bardziej restrykcyjne uprawnienia w zależności od kontekstu bezpieczeństwa aplikacji, która uległa awarii.
Domyślne uprawnienia do folderu głównego „C:\ProgramData\Microsoft\Windows\WER” to:
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
Everyone:(I)(OI)(CI)(RX)
Główną przyczyną umożliwiającą arbitralne usunięcie katalogu uprzywilejowanego w celu eskalacji uprawnień jest zaskakujący, logiczny przepływ w WER. Jeśli folder główny nie istnieje, gdy jest potrzebny do utworzenia raportu to zostanie utworzony.
Zaskakujące jest jednak to, że folder jest tworzony z następującymi uprawnieniami:
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\Authenticated Users:(OI)(CI)(R,W,D)
NT AUTHORITY\SERVICE:(OI)(CI)(R,W,D)
NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(R,W,D)
NT AUTHORITY\NETWORK SERVICE:(OI)(CI)(R,W,D)
NT AUTHORITY\WRITE RESTRICTED:(OI)(CI)(R,W,D)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(R,W,D)
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(R,W,D)
Usuwamy folder WER:
Poniżej porównanie uprawnień przed skasowaniem folderu WER i po.
Jak się okazuje nadane przez system Windows nowe uprawnienia umożliwiają przekształcenie folderu głównego w folder powiązany (junction folder) za pomocą nieuprzywilejowanego profilu – czyli na uprawnieniach zwykłego konta użytkownika.
W tym momencie autor odkrycia zauważył, że jest to scenariusz, dla którego nie została zaprogramowana usługa WER i zajął się napisaniem odpowiedniego kodu aplikacji powodującej wykorzystanie tej luki.
Zaprojektowanie eksploita
Do wykonania całej operacji potrzebujemy uprawnienia DELETE do folderu nadrzędnego, ponieważ podfoldery mogą zawierać dane, których normalnie nie byłoby tak łatwo usunąć (uprawnienia do dziedziczenia plików i folderów są nieistotne).
Mało znanym szczegółem NTFS jest to, że operację zmiany nazwy można używać do przenoszenia plików i folderów w dowolnym miejscu woluminu dysku. Operacja zmiany nazwy wymaga uprawnienia DELETE do źródła i uprawnienia FILE_ADD_FILE/FILE_ADD_SUBDIRECTORY w folderze docelowym.
Przenosząc wszystkie podfoldery z C:\ProgramData\Microsoft\Windows\WER do innej zapisywalnej lokalizacji, takiej jak C:\ Windows\Temp, omijamy wszelkie ograniczenia dotyczące plików w podfolderach.
W tym momencie z powodzeniem można wykorzystać lukę w zabezpieczeniach polegającą na usuwaniu dowolnego katalogu w C:\ProgramData\ Microsoft\Windows\WER.
Jest jeszcze jedna kwestia, którą wymienił Jonas:
„Jeśli luka w zabezpieczeniach umożliwia jedynie usunięcie pliku, ponieważ NtCreateFile jest wywoływany z FILE_NON_DIRECTORY_FILE, ograniczenie to można ominąć, otwierając ścieżkę C:\ProgramData\Microsoft\Windows\WER::$ INDEX_ALLOCATION.”
Po zniknięciu folderu następnym krokiem jest ponowne utworzenie go przez usługę WER. Można to zrobić, uruchamiając zadanie \Microsoft\Windows\Windows Error Reporting\QueueReporting.
Zadanie możemy uruchomić następująca komendą z wiersza linii komend (CMD).
SCHTASKS.EXE /RUN /TN “\Microsoft\Windows\Windows Error Reporting\QueueReporting”
Zadanie jest uruchamiane przez nieuprzywilejowany profil (zwykłe konto użytkownika), ale jest wykonywane jako SYSTEM. Po zakończeniu zadania widzimy nowy folder z odtworzoną strukturą podfolderów. Aby skorzystać z naszego nowego uprawnienia FILE_WRITE_ATTRIBUTES na odtworzonym folderze w celu przekształcenia go w folder połączenia, musimy najpierw go opróżnić. To co jeszcze musimy wykonać to powtórzenie operacji przenoszenia w podkatalogach jak poprzednio, aby można było utworzyć nasz folder powiązań.
Po ustawieniu punktu powiązania na folder \??\c:\windows\system32\wermgr.exe.local usługa raportowania błędów utworzy folder docelowy z tą samą dopuszczalną listą ACL.
Jonas zauważył także, że każde wykonanie pliku usługi wermgr.exe będzie próbowało otworzyć folder wermgr.exe.local. Jeśli ten zostanie otwarty, będzie miał najwyższy priorytet podczas wczytywania pliku Comctl32.dll, który powinien znajdować się w podfolderze o nazwie: amd64_microsoft.windows.common-control_6595b64144ccf1df_6.0.18362.778_none_e6c6b761130d4fb8.
Oznacza to tyle, że jeśli wgramy złośliwą bibliotekę DLL o nazwie comctl32.dll i umieścimy ją w folderze amd64_microsoft.windows.common-control_6595b64144ccf1df_6.0.18362.778_none_e6c6b761130d4fb8 wówczas zostanie ona załadowana przez funkcję API Windows „LoadLibrary” przez usługę WER w kontekście użytkownika SYSTEM.
Autor stworzył pod to odpowiedni kod (exploit) i pokazał nim jak uruchomić wiersz linii poleceń w kontekście użytkownika „NT AUTHORITY\SYSTEM”.
Po kompilacji kodu eksploita i uruchomieniu go, wynik jego uruchomienia można zaobserwować na poniższym ekranie:
Podsumowanie
Opisany powyżej przykład wykorzystujący błędną obsługę linków powiązań do folderów pokazuje, że w dziedzinie cyberbezpieczeństwa jest jeszcze dużo do zrobienia. Okazuje się, że nadal istnieją takie zakamarki w Windows, które można wykorzystać do przejęcia uprawnień do systemu. W przypadku ochrony stosowne w tej sytuacji byłoby odpowiednie monitorowanie procesów w systemie oraz wszelkich eskalacji uprawnień jakie są wykonywane przez użytkowników.