Wybrany post: Zero-day w narzędziu Psexec pozwala na eskalację uprawnień do SYSTEM!

Nowoodkryty 0-day w narzędziu PsExec i utworzony specjalny exploit pozwala uzyskać najwyższe uprawnienia administracyjne do systemu Windows!

Jeśli posiadasz lokalny dostęp (nieadministracyjny) do systemu Windows, a administrator środowiska IT lub oprogramowanie w firmie, w której pracujesz używa narzędzia psexec do uruchamiania poleceń na Twoim komputerze, to za pomocą tego specjalnego exploit’a możesz w łatwy sposób uzyskać do niego lokalne uprawnienia administracyjne. Wszystko to dzięki nowoodkrytej luce bezpieczeństwa, która do tej pory nie została jeszcze załatana przez Microsoft. Dla zainteresowanych na pocieszenie informujemy, że powstał micropatch, lecz stworzony został przez firmę zewnętrzną. Szczegóły opisujemy poniżej.

Co to jest PSEXEC?

PsExec to taki lekki zamiennik telnet’u, który umożliwia wykonywanie procesów na innych systemach, wraz z pełną interaktywnością dla aplikacji konsolowych, bez konieczności ręcznego instalowania oprogramowania klienckiego. Stał się powszechnym narzędziem w środowisku administratorów Windows, ale również zyskał swoją popularność w środowisku RedTeam i wśród osób atakujących (używany do przeprowadzania ataków np. CYBER KILLCHAIN). Jest także używany przez wiele specjalistycznych narzędzi administracyjnych w środowisku IT.
Dlatego jego użycie powinno być monitorowane przez specjalistyczne narzędzia do bezpieczeństwa.

Autorem PsExec jest Mark Russinovich, a najpotężniejsze zastosowania PsExec obejmują uruchamianie interaktywnych monitów poleceń na zdalnych systemach i narzędzi umożliwiających zdalne uruchomienie, takich jak np. ipconfig, które nie posiadają wbudowanej możliwości wyświetlania informacji ze zdalnych systemów.

Przyglądając się zaś architekturze działania PsExec zauważymy osadzony zasób o nazwie „PSEXESVC”, który jest wykonywalnym komponentem z poziomu usługi w systemie Windows oraz jest wyodrębniany, kopiowany i wykonywany na zdalnej maszynie na uprawnieniach użytkownika SYSTEM za każdym razem, gdy klient PsExec wykonuje PsExec na docelowym zdalnym komputerze. Komunikacja między klientem PsExec a zdalną usługą PSEXESVC odbywa się za pośrednictwem nazwanych potoków (z ang. „named pipes”). W szczególności potok o nazwie „\PSEXESVC” jest odpowiedzialny za analizowanie i wykonywanie poleceń klienta PsExec, takich jak „którą aplikację wykonać”, „odpowiednie dane wiersza poleceń” itp.

W czym tkwi problem?

Nowoodkryta lokalna luka w PsExec umożliwia eskalację uprawnień (LPE). Jeśli PsExec zostanie uruchomiony lokalnie lub zdalnie na docelowym komputerze przez administratora, a my na tym komputerze uruchomimy proces (exploit’a) na zwykłych uprawnieniach użytkownika (niebędącego administratorem) to umożliwimy mu eskalację uprawnień do SYSTEM i przejmiemy pełne uprawnienia do systemu.

Potok „\ PSEXESVC” usługi PSEXESVC ze względów bezpieczeństwa jest chroniony i umożliwia jedynie administratorom systemu dostęp do odczytu / zapisu, uniemożliwiając w ten sposób lokalnym użytkownikom o niskich uprawnieniach odczyt / zapis w potoku usługi.

Badacz David Wells z Tenable odkrył, że jeśli lokalna aplikacja o niskich uprawnieniach utworzy potok nazwany „\ PSEXESVC” przed wykonaniem PSEXESVC, to PSEXESVC uzyska uchwyt do istniejącej instancji zamiast tworzenia samego potoku nazwanego i może to spowodować nieoczekiwane konsekwencje. W tym celu wykonał inżynierię wsteczną kodu (ang. reverse engineering) PsExec i utworzył własny potok PSEXESVC „\ PSEXESVC”, który był w stanie przejąć.

W kodzie znalazł ciekawy atrybut nMaxInstances, który pozwala na istnienie nieograniczonej liczby instancji potoku „\ PSEXESVC”. Zauważył również, że nie gwarantuje on utworzenia jedynej aplikacji, która utworzy potok „\ PSEXESVC”, co zwykle jest powinno być wykonywane przy użyciu flagi FILE_FLAG_FIRST_PIPE_INSTANCE. W celu exploitacji podatności napisał kod POC, w którym utworzył nowy nazwany potok i uzyskał uchwyt do istniejącego potoku „\PSEXESVC” po wywołaniu PsExec’a przez administratora. Skutkiem całej operacji było odziedziczenie listy ACL istniejącego potoku zamiast stosowania własnej listy ACL „tylko dla administratorów” do potoku, niezależnie od tego, czy atrybuty zabezpieczeń mówią inaczej w wywołaniu „CreateNamedPipe” (listing powyżej).

Za pomocą tak stworzonego exploita Wells był w stanie potwierdzić, że problem dotyka wielu wersji systemu Windows, od Windows XP do Windows 10.

UWAGA! Problem dotyczy wersji PsExec wydanych w ciągu ostatnich 14 lat!

Luka została opublikowana przez Wells’a 9 grudnia 2020r., 90 dni po tym, jak Microsoft został o tym poinformowany i nie udało mu się jej załatać.
Odkrył również, że problem dotyka wielu wersji PsExec, począwszy od wersji 1.72 wydanej w 2006 roku, a kończąc na PsExec v2.2, czyli najnowszej wersji wydanej prawie cztery lata temu. Oznacza to, że 0-day ma wpływ na wszystkie wersje PsExec uruchomione w ciągu ostatnich 14 lat!

Demo POC exploit’a 0-day dla PSEXEC

Poniżej zamieszczamy demo exploit’a:

Na powyższym demo (okno po lewej) widzimy jak Administrator systemu próbuje uruchomić narzędzie „cmd.exe” na komputerze zdalnym (prawe okno) przy użyciu narzędzia Psexec.exe. Prawe okno to zdalny komputer z uruchomionym exploitem (Poc), który przechwytuje sterowanie i zamiast tego uruchamia MsPaint.exe na uprawnieniach użytkownika SYSTEM.

Jak sobie radzić z problemem?

Dla powyższej podatności, do tej pory nie zostało jeszcze przypisane żadne CVE przez Microsoft. Co ciekawe gigant z Redmont nie wydał nawet żadnej łatki, za to wykonała ją firma zewnętrzna 0patch. Wczoraj został przez nią wydany specjalny micropatch, który dotyczy tylko najnowszej wersji PsExec, a więc v2.2. Jego autor Mitja Kolsek opisuje, że udostępniona bezpłatna łatka jest uruchamiana w pamięci komputera i nie wymaga ponownego jego uruchamiania. Dotyczy zarówno najnowszej 32-bitowej jak i 64-bitowej wersji PsExec. Autor patch’a informuje również na Twitterze, że może napisać łatkę do starszych wersji PsExec, ale zależne to będzie od opinii użytkowników.

Jak można uzyskać mikropatch?

Uzyskanie i wdrożenia łatki nie jest jednak takie proste. Należy w tym celu:

1. Utworzyć bezpłatne konto na 0patch pod adresem https://central.0patch.com.
2. Pobrać i zainstalować agenta 0patch na wszystkich komputerach, na których uruchamiasz pliki wykonywalne z PsExec. Następnie trzeba je zarejestrować na swoim koncie 0patch.
3. Upewnić się, że używamy wersji PsExec 2.2, w przeciwnym razie mikropatch nie zostanie zastosowany.

Poniższe demo wideo pokazujące, jak mikropatch wydany przez 0patch zapobiega przed wykorzystaniem 0-day’a w systemach Windows z PsExec:

Podsumowanie

Ten przypadek pokazuje, że również w darmowych narzędziach oferowanych przez Microsoft mogą wystepować krytyczne błędy, a ich wykorzystanie może doprowadzić do eskalacji uprawnień do systemu lokalnego i całkowitego przejęcia kontroli nad maszyną, gdy tylko ktoś z administratorów użyje PsExec przeciwko tej maszynie. Konsekwencje exploitacji tej luki mogą być bardzo bolesne dla firm. Dla użytkowników domowych i małych firm nie jest to prawdopodobnie zagrożenie o wysokim priorytecie.

Wyobraźmy sobie sytuację, w której atakujący jako użytkownik niebędący administratorem uruchomia exploit na komputerze zdalnym (np. logując się jako zwykły użytkownik na serwer terminali, ustanawiając sesję RDP jako użytkownik domeny lub włamując się do podatnej na ataki usługi nieuprzywilejowanej działającej na komputerze zdalnym), aby podnieść swoje uprawnienia do systemu lokalnego i całkowicie przejąć kontrolę nad maszyną, gdy tylko ktoś z administratorów użyje na tym komputerze PsExec’a. W konsekwencji może skompromitować całe środowisko.
Zważywszy na to, że w dużych firmach powyższe zalecenia naprawcze mogą być trudne do wdrożenia, zalecamy monitorowanie użycia PSEXEC w organizacji i poinformowanie administratorów o dostępnym micropatch’u lub ewentualnie wstrzymanie się z wykorzystaniem narzędzia w firmie, aż do oficjalnego zalatania go przez twórcę – Microsoft.