Odkryto nową podatność na nadużycia w wierszu poleceń Windows. Aktualizacji nie będzie Strona główna Aktualności11.06.2020 00:36 Nadużycia w wierszu poleceń Windows (fot. Tony Webster, CC BY 2.0) Udostępnij: O autorze Kamil J. Dudek @wielkipiec 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.exeThanks 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. Oprogramowanie Bezpieczeństwo IT.Pro Udostępnij: © dobreprogramy Zgłoś błąd w publikacji Zobacz także Windows File Recovery. Straciłeś plik? Nowe narzędzie Microsoftu pomoże 30 cze 2020 Jakub Krawczyński Oprogramowanie Bezpieczeństwo 57 Nowości w działaniu wirusów. Wkrótce DNS-over-HTTPS wywoła wiele problemów 4 wrz 2020 Kamil J. Dudek Oprogramowanie Bezpieczeństwo IT.Pro 43 GitHub Desktop 2.5 dostępny do pobrania. W końcu obsługuje tagi 14 maj 2020 Oskar Ziomek Oprogramowanie IT.Pro 43 Nie ma czegoś takiego, jak czysty tekst. Najczęstsze problemy programistyczne 5 maj 2020 Kamil J. Dudek Oprogramowanie IT.Pro 45
Udostępnij: O autorze Kamil J. Dudek @wielkipiec 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.exeThanks 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. Oprogramowanie Bezpieczeństwo IT.Pro Udostępnij: © dobreprogramy Zgłoś błąd w publikacji