W dzisiejszym artykule opiszemy kolejną, ciekawą technikę trwałego ukrywania się cyberprzestępców w systemie Windows, umożliwiającą uruchomienie złośliwego oprogramowania. Tym razem napiszemy o możliwości wykorzystania luki w komponencie Windows o nazwie Task Scheduler (harmonogram zadań) pozwalającej uruchomić złośliwy kod w systemie bez konieczności tworzenia w nim dodatkowych zadań (Scheduled Tasks). Pokażemy jak za pomocą tej metody możemy zdobyć także największe uprawnienia w systemie Windows, czyli LOCAL SYSTEM.
Nadmienię przy tej okazji, że ostatnio opisywaliśmy sposób na ukrywanie się atakujących w systemie Windows wykorzystując do tego funkcję innej usługi Print Spooler o nazwie Port Monitor.
Sposobów na ukrycie uruchomienia złośliwego kodu w Windows jest wiele. Jednym z nich, wykorzystywanym przez cyberprzestępców jest tworzenie zaplanowanych zadań (ang. Scheduled Task). Lecz w opisywanym tutaj przypadku, aby uruchomić złośliwy kod nie będziemy tworzyć nowego, zaplanowanego zadania w systemie. Byłoby to zbyt oczywiste i w miarę łatwe do wykrycia przez narzędzia Security czy zespół BlueTeam. Skupimy się na ciekawej możliwość polegającej na dostarczeniu do systemu Windows złośliwej biblioteki z kodem, którą wgramy w odpowiednie miejsce. Następnie system Windows sam załaduje ją automatycznie i wraz z uruchomieniem usługi Task Scheduler uruchomi nasz kod.
Bug w Task Scheduler pozwala uruchomić kod jako LOCAL SYSTEM!
Jak to jest możliwe, że bez tworzenia nowego zadania w systemie będziemy w stanie użyć Task Scheduler’a do uruchomienia kodu? Powód jest prosty – istniejąca luka w kodzie Microsoft, która do tej pory nie została naprawiona. Błąd polega na tym, że usługa harmonogram zadań systemu Windows (Windows 10 i Windows Server 2016) próbuje załadować nieistniejącą bibliotekę DLL WptsExtensions.dll z katalogu systemowego %windir%\System32. Microsoft w systemie Windows 10 (oraz Windows 2016) wprowadził bibliotekę WPTaskScheduler.dll (bibliotekę DLL harmonogramu zadań WP), która po poprawnym wywołaniu umożliwia nam uruchomienie własnego kodu w systemie. Jednym z pierwszych zadań wewnątrz WPTaskScheduler.dll:: WptsInitialize() jest wywołanie funkcji InitializeWPTS(). Ta funkcja z kolei ładuje nieistniejącą w systemie bibliotekę WptsExtensions.dll i rozwiązuje następujące funkcje, jeśli biblioteka DLL została znaleziona i załadowana poprawnie:
Zatem jeśli będziemy w stanie stworzyć plik WptsExtensions.dll i wgrać go do katalogu systemowego mamy backdoora pozwalającego nam uruchomić dowolny kod! Dodatkowym bonusem wykorzystania tego błędu jest możliwość uruchomienia w systemie Windows łatwy sposób dowolnego kodu na najwyższych uprawnieniach – LOCAL SYSTEM, ponieważ usługa Task Scheduler działa właśnie w tym kontekście.
Scenariusz uruchomienia złośliwej Biblioteki przez Task Scheduler
W celu przekonania się, czy opisana powyżej metoda naprawdę działa na najnowszym Windows 10, utworzyliśmy w Visual C++ bibliotekę DLL, której załadowanie przez usługę Task Scheduler’a spowoduje, że w systemie uruchomimy program – notepad.exe (notatnik).
Krok 1 – utworzenie biblioteki DLL
Poniżej zamieszczamy kod biblioteki w C++.
Załadowanie biblioteki do pamięci powoduje uruchomienie funkcji WinExec, która w parametrach uruchomi notatnik. Oczywiście zamiast uruchamiania notatnika moglibyśmy pokusić się o uruchomienie czegokolwiek innego (np. payload).
Krok 2 – skopiowanie biblioteki WptsExtensions.dll do katalogu System32
Następnie tak skompilowaną bibliotekę WptsExtensions.dll musimy wgrać do katalogu systemowego „C:\Windows\System32”. Lecz, aby to wykonać musimy posiadać lokalne uprawnienia administracyjne na Windows 10 (jak zdobyć takie uprawnienia pisaliśmy wielokrotnie na Kapitanie Hack’u).
Krok 3 – restart komputera lub usługi Task Scheduler
Można odczekać do restartu systemu lub spróbować zrestartować usługę ręcznie. Ponowne załadowanie usługi harmonogramu (Task Scheduler) załaduje naszą bibliotekę DLL.
W wyniku załadownia naszej biblioteki w systemie zobaczymy uruchomiony proces notatnika (notepad.exe). Widzimy również, że został on uruchomiony przez proces „svchost.exe” na uprawnieniach NT AUTHORITY\LOCAL SYSTEM. To ten dodatkowy bonus, o którym wcześniej pisaliśmy.
Podsumowanie
Powyższy przykład obala teorię, w której powinniśmy zwracać uwagę (monitorować) na wszystkie załadowane biblioteki, których lokalizacja pochodzi z zewnętrznych ścieżek (nie tych systemowych) przez wbudowane procesy Windows. Nasuwa się nam pytanie: Dlaczego Microsoft do tej pory nie zablokował lub nie naprawił tej możliwości? Być może uważa, że nie stanowi ona wysokiego zagrożenia dla bezpieczeństwa Windows, bo żeby móc wgrać cokolwiek do katalogu „C:\Windows\System32” trzeba posiadać uprawnienia administracyjne. O to ostatnie zbytnio nie powinniśmy się przejmować, ponieważ istnieją sposoby na ich zdobycie, które często pokazujemy na Kapitanie. Może opisywana przez nas metoda uruchomienia dowolnego kodu nie jest zbyt oryginalna ani tajemna, ale przynajmniej jest trochę bardziej dyskretna (podobnie jak inne ukryte możliwości w Windows :)).