Cześć 😊 Poniższy wpis stanowi kontynuację poprzedniego artykułu o Windows Defenderze. W poprzednim artykule udało się nam doprowadzić do sytuacji w której możemy swobodnie usuwać zawartości wybranych przez nas folderów. W tym odcinku postaramy się pójść o krok dalej i wykorzystać tą możliwość w celu eskalacji uprawnień.  

Pozwólcie, że nie będę omawiać od nowa całej ścieżki jak wygląda usuwanie pików i folderów. Zrobiłem to w poprzednim wpisie. W tym ograniczę się do informacji, że na sam początek potrzebujemy usunąć folder C:\ProgramData\Microsoft\Windows\WER oraz folder C:\Program Files\Windows Media Player. Dlaczego akurat te dwa?  

Pierwszy z nich to folder związany z Windows Error Reporting. Jest to w dużym skrócie serwis odpowiadający za szeroko pojętą telemetrię oraz za wysyłanie informacji o błędach aplikacji do Microsoftu. To co robi ten serwis jest dla nas w zasadzie nieistotne. Bardziej istotne są np. uprawnienia dla folderu WER.  

Widzimy, że jako zwykli użytkownicy nie mamy prawa zapisu do folderu WER. W miarę zrozumiałe. Ciekawe jednak jest to, że w przypadku usunięcia folderu WER mamy możliwość jego odtworzenia jako użytkownik nieuprzywilejowany. Spróbujmy wykonać taki eksperyment (zakładamy, że wcześniej usunęliśmy go za pomocą CVE-2020-1170).

Na obrazku wyżej widzimy wyraźną różnicę. Pomijając wszystko inne, przede wszystkim każdy użytkownik („Authenticated Users”) posiada prawa zapisu do tego folderu, subfolderów (CI), a także plików (OI). I jeszcze jedno, może najważniejsze – wewnątrz folderu „WER” tworzony jest jeszcze jeden folder o nazwie „Temp”, z takimi samymi uprawnieniami. Podsumujmy zatem:

• możemy usuwać dowolne foldery wraz z plikami w systemie
• możemy tworzyć folder C:\ProgramData\Microsoft\Windows\WER\Temp z uprawnieniami użytkownika NT Authority\SYSTEM
• mamy prawa zapisu do wyżej wymienionego folderu.

Brzmi nieźle, prawda?  Aby wskazać systemowi Windows, że „C:\ProgramData\Microsoft\Windows\WER\Temp” tak naprawdę wskazuje na „C:\Program Files\Windows Media Player” wykorzystamy symboliczne linki. Dlaczego tak bardzo uparłem się na folder „Windows Media Player”? Ano dlatego, że znajduje się tam plik wykonywalny „wmpnetwk.exe”, który jest uruchamiany przez serwis „Windows Media Player Network Sharing Service”.  Rzućmy jeszcze szybko okiem na uprawnienia, które mają „zwykli” użytkownicy wobec serwisu WMPNetworkSvc.

Widzimy, że nieuprzywilejowany użytkownik ma prawo do uruchomienia serwisu. Na pierwszym z powyższych obrazków jest to dość oczywiste, natomiast w drugim sprawa nieco się komplikuje 😉 Format zapisu danych z dolnego obrazka to tak zwany SDDL – Security Descriptor Definition Language. Jest to nic innego jak struktura „Security Descriptor”^[1] zapisana w formie jedno-linijkowego łańcucha znaków. Literka „D” na samym początku oznacza standardową listę kontroli dostępu (DACL – Discretionary Access Control List)  składającą się z wpisów kontroli dostępu (ACE – Access Control Entry). Przypominam, że każdy obiekt w systemie windows posiada też SACL – System Access Control List, który odpowiada za audyt obiektu. W powyższym ciągu znaków możemy odczytać, że nieuprzywilejowany, zalogowany użytkownik (IU – Interactive Logged-In User) może uruchamiać serwis (RP). Polecam zrobić sobie ściągawkę z oznaczeniami SDDL, ja nie potrafią bez niej odczytywać tych znaków.

Okej, ale wróćmy do naszego symbolicznego linku. Aby utworzyć bezpośrednie symboliczne dowiązanie w systemie Windows potrzebujemy uprawnień administratorskich, lub co najmniej przydzielonego tokenu SeCreateSymbolicLinkPrivilege. Możemy jednak obejść to ograniczenie montując folder do katalogu w Menadżerze Obiektów systemu Windows (np. do \RPC CONTROL\), a następnie tworząc symboliczne dowiązanie z katalogu \RPC Control\ do docelowego pliku. Pożądana konfiguracja sytuacji folderA\plikA -> folderB\plikB w naszym przypadku będzie wyglądać następująco:

folderA  -> \RPC CONTROL\ – NTFS JUNCTION

\RPC CONTROL\plikA -> folderB\plikB – symboliczne dowiązanie

W celu utworzenia symbolicznego dowiązania użyjemy biblioteki NtApiDotNet.

Obecność dowiązania można potwierdzić w programie WinObj z pakietu SysInternals.

Po utworzeniu dowiązania należy uruchomić zadanie Windows Error Reporting\QueueReporting.

Przy odpowiednio ustawionych filtrach w programie Process Monitor możemy zaobserwować, że folder „C:\ProgramData\Microsoft\Windows\WER\Temp” został zinterpretowany przez system jako „C:\Program Files\Windows Media Player” i utworzony.

Sprawdźmy jeszcze czy mamy odpowiednie uprawnienia do tego folderu.

Świetnie! Wygląda na to, że mamy prawa zapisu do tego folderu. Teraz pozostaje nam już tylko wygenerowanie odpowiedniego payloadu w msfvenom, uruchomienie netcata na lokalnym adresie i otrzymanie shella użytkownika „Network Service”.

Przenosimy wygenerowany plik do folderu Windows Media Player, a następnie nadajemy odpowiednie prawa do niego dla użytkownika „NT AUTHORITY/NETWORK SERVICE”.

Ostatnim etapem jest uruchomienie programu netcat, który będzie nasłuchiwał na porcie 8888, a następnie wystartowanie serwisu WMPNetworkSvc. Otrzymany efekt powinien być podobny jak na obrazku poniżej.

Myślę, że większość wie jak dokonać eskalacji uprawnień. Posiadając token „SeImpersonatePrivilege” możemy dokonać eskalacji uprawnień za pomocą narzędzi takich jak „Rotten Potato”, „Rotten Potato NG”, „Juicy Potato” czy „Print Spoofer”. O tym jak działa takie podnoszenie uprawnień będę chciał napisać niedługo.  Poniżej przykład działania programu PrintSpoofer.exe

To by było na tyle jeśli chodzi o eskalację uprawnień z wykorzystaniem Windows Error Reporting oraz Windows Defendera. Eskalacja uprawnień została wykonana na Windowsie 10 PRO 1903.

[1] https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptors