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:[code]cmd.exe /c "ping 127.0.0.1/../../../../../../../../../../windows/system32/calc.exe"[/code]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".
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.
