Odkryto nową podatność na nadużycia w wierszu poleceń Windows. Aktualizacji nie będzie

Opracowano nową, interesującą metodę dokonywania nadużyć w systemowym wierszu poleceń Windows, cmd.exe. Autorem odkrycia jest Julian Horoszkiewicz. Słabość jest podobna do typowej klasy błędów z cyklu path traversal, gdzie korzystanie z relatywnych ścieżek lub podawanie ich w niespodziewanych miejscach może skutkować rozszerzeniem uprawnień. Nie jest to jednak zwyczajny “path traversal”.

W swoim godnym rekomendacji opracowaniu, autor przytacza następujący przykład:

cmd.exe /c "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe"

Powyższe polecenie uruchamia Wiersz Poleceń, zestawiany jako wyjście (conhost, coś na kształt stdout) dla polecenia podanego parametrem /c. Jednak mimo, że składnia wskazuje na uruchomienie programu ping (z dziwnym argumentem), w praktyce uruchamiany jest Kalkulator. Zachodzi więc rozbieżność między poleceniem a autentycznie wykonywanym programem.

Co z tego?

Śledzenie procesów pokazuje ponadto, że bezpośrednim procesem potomnym takiego wywołania jest calc.exe, a ping nie jest uruchamiany w ogóle. W systemach z włączonym audytowaniem procesów (jest to jedno z wymagań DISA STIG), ispekcja wykaże, że wykonano polecenie zawierające inny program niż proces, który powstał w jego skutek. To groźne, ponieważ niedokładny audyt i nonszalancja w użyciu Sysmona mogą doprowadzić do przeoczeń. A logowanie nowych procesów powstałych w ramach “cmd /c” jest męczące samo w sobie.

Opisowi odkrycia towarzyszy szereg interesujących uzupełnień, jak próba przemycenia payloadu w samym poleceniu, pozorującym uruchomienie innego programu, a także dyskusja dotycząca tego, co cmd.exe usiłuje potraktować jako obraz wykonywalny, nie tylko na podstawie samego rozszerzenia.

Cenną uwagą w temacie podzielił się przy okazji Oddvar Moe, używając w tym samym celu nie cmd.exe, a conhost.exe, czyli proces-kontener, w którym pracuje “wszystko co tekstowe”.

Found an even cooler example with this technique when looking at it quick.

When executing with conhost it executes the process without a parent PID.

conhost calc.exe/../../windows/notepad.exe

Thanks for the inspiring post @julianpentest https://t.co/pT6oTDKVlw pic.twitter.com/FMh30yynm0

— Oddvar Moe (@Oddvarmoe) June 10, 2020

Ponieważ conhost jest procesem towarzyszącym każdemu wywołaniu cmd, zdarzenia audytowe dotyczące tworzenia go często są logowane w SIEM jedynie warunkowo, na podstawie korelacji z uruchamianym poleceniem. Ta ryzykowna metoda “odszumiania logów” i niekoniecznie najlepsza praktyka, mogłaby się tutaj zemścić.

Wymowna jest reakcja Microsoftu. Generalnie stwierdzono, że “tak ma być”, bo właśnie taka jest kolejność przetwarzania argumentów i ścieżek. Problem sprowadza się w praktyce do wyprowadzania w pole kiepsko parsowanych audytów, oszukiwania korelatorów w SIEM i dodawania męczącej roboty antywirusom. Jasne, nie jest to krytyczna luka. Ale świat naprawdę byłby lepszy, gdyby to działało trochę inaczej. Tymczasem duet conhost+sysmon wciąż pozostanie źródłem frustracji administratorów Windows.

Reakcja

0%0Pozytywnie0%0Neutralnie 0%0Negatywnie

Twoje emocje

0%0Lubię to!

0%0Super0%0Ekscytujący 0%0Ciekawy0%0Smieszny0%0Smutny0%0Wściekły0%0Przerażony0%0Szokujący0%0Wzruszający0%0Rozczarowany0%0Zaskoczony

Co sądzisz?

0%0Prawda0%0Manipulacja0%0Fake news

0

0Ulub

Oryginalne źródło ZOBACZ