Niedawno opublikowaliśmy informację o niewykrywanej do tej pory przez oprogramowanie antywirusowe podatności w MS Excel wykorzystującej historyczną wersję makra 4.0 z 1992 roku. W tym artykule skupimy się na kolejnej, nowo odkrytej podatności zero-day, tym razem odnalezionej w architekturze implementacji wbudowanego w Windows komponentu – Harmonogramu zadań (ang. Task Scheduler). Opisywana podatność zero-day pozwala atakującemu (zalogowanemu w Windows jako zwykły użytkownik) lub złośliwemu oprogramowaniu na uzyskanie i uruchomienie kodu z uprawnieniami administracyjnymi.
W celu lepszego zrozumienia na czym polega podatność poniżej przedstawiliśmy scenariusz POC wykorzystujący kod jego twórcy wraz z objaśnieniami. Zacznijmy najpierw od historii.
Czyżby kolejny historyczny bug niezauważony przez Microsoft?
Jest 31 stycznia 1994 roku – czas, w którym w Polsce lider zespołu Akcent – Zenon Martyniuk wydaje swój szósty z kolei album studyjny pt. „Życie to są chwile”, natomiast w Redmond w Stanach zjednoczonych firma Microsoft, będąca wówczas pod rządami Billa Gates’a po raz pierwszy wprowadza na rynek dodatek do Windows 95 pod nazwą „Microsoft Plus” i wraz z nią pojawia się słynny „Harmonogram zadań”.
Od tej pory każdy system operacyjnymi Microsoft zostaje wyposażony w wbudowany Harmonogram zadań, a z biegiem lat pojawiają się jego kolejne wersje:
– 1.0 – instalowany z systemami operacyjnymi Windows Server 2003, Windows XP i Windows 2000.
– 2.0 – instalowany z systemami Windows Vista i Windows Server 2008.
Na przestrzeni ostatnich kilku lat w Harmonogramie zadań wykryto kilka podatności, ale nie były one tak spektakularne jak ta obecna. Ostania, którą szczegółowo opisujemy została opublikowana 22 maja 2019 roku przez anonimowego hakera posługującego się w sieci pseudonimem „SandboxEscaper”. Opublikował on kod exploit’a (nowa luka zero-day), który wpływa na mechanizm zabezpieczeń systemu operacyjnego Windows 10. Jest to już jego piąty publicznie ujawniony exploit zero-day wyprodukowany w niecały rok dla systemu Windows. Hacker mocno depcze gigantowi z Redmont po piętach, natomiast my przetestowaliśmy i sprawdziliśmy exploit w labie, dzięki temu będziemy mogli się przed nim chronić na Windows 10 i wersjach serwerowych Windows 2016 i 2019.
Czego dotyczy podatność?
Nowa luka zero-day dla systemu Windows 10 (działa także na Windows 2016 i 2019) została opublikowana na profilu hackera na GitHub’ie, lecz z oczywistych powodów szybko została z niego zdjęta. Ponieważ zgodnie z zasadą „to co pojawia się w sieci nigdy z niej nie ginie” tak i w tym przypadku kod exploita został wcześniej skopiowany i aktualnie można go znaleźć w Darknecie. Opublikowany exploit dotyka problemu eskalacji uprawnień, który może pozwolić atakującemu zalogowanemu w systemie operacyjnym Windows jako normalny użytkownik lub złośliwemu oprogramowaniu na uzyskanie i uruchomienie kodu z uprawnieniami administracyjnymi. Oznacza to tyle, że system operacyjny pozwoli hackerowi uzyskać pełną kontrolę nad komputerem ofiary. Opisywana luka została wykryta w implementacji sposobu działania Harmonogramu zadań Windows – narzędziu, które umożliwia planowanie uruchamiania programów lub skryptów w określonych godzinach lub po określonych odstępach czasu (tzw. Planowanie zadań).
Exploit od kuchni
Dla niewtajemniczonych, w każdym systemie Windows istnieją dwa foldery, w których przechowywane są konfiguracje zadań dla Harmonogramu zadań (ang. Task Scheduler). Są to:
– „C:\Windows\Tasks”
– „C:\Windows\System32\Tasks”
W dawnych czasach (np. Windows XP) zadania byłyby umieszczane w folderze „C:\Windows\Tasks” w plikach o formacie „*.job”.
Domyślnie każdy użytkownik Windows może tworzyć zadania w Harmonogramie zadań.
Jeśli chcielibyśmy zaimportować swój plik zadań z rozszerzeniem „.job” do harmonogramu zadań na Windows 10, musielibyśmy najpierw skopiować stare pliki „.job” do katalogu „c:\windows\tasks” i uruchomić poniższą komendę, używając do polecenia skopiowanych plików ze starego systemu “schtasks.exe” i „schedsvc.dll” (źródło komendy znajdziesz tutaj):
„schtasks /change / TN „nazwa_zadania” / RU nazwa_użytkownika /RP hasło”
Uruchomienie powyższego polecenia spowoduje wywołanie następującego RPC „_SchRpcRegisterTask”, który jest ujawniany przez usługę planowania zadań. W tym momencie uruchomi się proces podszywający się pod bieżącego użytkownika.
Rozpoczyna się od podszywania się pod bieżącego użytkownika i kiedy napotka wywołanie w kodzie następującej funkcji:
int __stdcall tsched::SetJobFileSecurityByName(LPCWSTR StringSecurityDescriptor, const unsigned __int16 *, int, const unsigned __int16 *)
Process zacznie przedstawiać się jako (NT AUTHORITY\SYSTEM)!
Następnie wywoła na zadaniu funkcję SetSecurityInfo w folderze “C:\windows\system32\tasks”.
W celu sprawdzenia skuteczności exploita wykonaliśmy dwa scenariusze na Windows 10 (build 1809) z wszystkimi aktualnymi uaktualnieniami na dzień 27 maja 2019. Pierwszy scenariusz wykorzystuje skompilowany w C++ przez nas plik „polarbear.exe”, drugi natomiast polecenia w PowerShell.
Scenariusz – aplikacja w języku C++
Przed uruchomieniem exploit’a sprawdźmy jakie uprawnienia w systemie Windows posiada nasz użytkownik „ofiara”.
„Ofiara” jako zwykły użytkownik systemu z oczywistego powodu nie posiada pełnych uprawnień do plików w katalogu „C:\windows\system32”. Postaramy się pokazać jak na przykładzie pliku „pci.sys” możemy je zmodyfikować używając do tego exploit’a.
Ponieważ nie jesteśmy stroną hackerską nie upublicznimy kodu użytego do wykonania omawianego exploit’a, może opiszemy go tylko z grubsza. Kod ma pięć linii. W pierwszej linii kopiowany jest plik „test.job” do starej lokalizacji zadań w „C:\Windows\Tasks\test.job”, następnie w drugiej linijce wywoływana jest komenda systemowa “schtasks /change /TN “bear” /RU username /RP password”, w trzeciej linii kasujemy automatycznie utworzone powiązanie w folderze „c:\windows\system32\tasks”, w czwartej tworzymy twarde powiązanie z plikiem systemowym „pci.sys” i na końcu w piątej linii wywołujemy jeszcze raz komendę “schtasks /change /TN “bear” /RU username /RP password”. Kluczowa jest wywołanie piątej linii, ponieważ to ona wywołuje metodę SetSecurityInfo na powiązaniu do pliku „pci.sys” na uprawnieniach użytkownika „NT AUTHORITY\SYSTEM” 🙂
W celu przetestowania na Windows 10 powyższego kodu musimy wykonać 2 kroki:
1. Skompilować kod (w wersji dla x64) do pliku “polarbear.exe”, następnie skopiować „polarbear.exe” i plik zadania “bear.job” oraz pliki z Windows XP (“schtasks.exe” i „schtasks.dll”) do jednego katalogu na komputer ofiary.
2. Uruchomić “polarbear.exe” wraz z dwoma parametrami („nazwa użytkownika” i „hasło”) aktualnie zalogowanego użytkownika (nieposiadającego uprawnień administracyjnych do Windows).
Po uruchomieniu exploit’a powinniśmy zobaczyć zmienione uprawnienia na pliku „pci.sys”, do którego normalnie nie ma dostępu zwykły użytkownik.
O dziwo podczas uruchomienia komendy „polarbear.exe” usługa Windows Defender zablokowała program, ale dopiero po jego wywołaniu.
Scenariusz – skrypt PowerShell
Zamiast kompilować kod do programu wykonywalnego „polarbear.exe” tak jak w poprzednim scenariuszu możemy użyć do tego celu dostępnej w systemie Windows powłoki PowerShell oraz skryptu Native-HardLink, bo przecież nie o kod nam tutaj chodzi tylko sposób jego wywołania. W Powershell kod exploit’a i jego wywołanie wygląda następująco:
I w tym przypadku udało nam się z sukcesem podmienić uprawnienia na pliku „pci.sys”, który jest tylko przykładem. Wyobraźmy sobie sytuację, w której zmieniamy uprawnienia na innym „krytycznym” pliku systemowym. Może to doprowadzić do przejęcia pełnych uprawnień systemu i jego całkowita kompromitację.
Podsumowanie
Twórca exploit zero-day- SandboxEscaper wykorzystał w swoim kodzie metodę „_SchRpcRegisterTask”, odpowiadającą w Harmonogramie zadań za rejestrowanie zadań w systemie operacyjnym, która nie sprawdza poprawnie uprawnień i dlatego może być używana do ustawiania dowolnego uprawnienia DACL (listy kontroli dostępu do pliku). Oznacza to, że złośliwy program lub osoba o niskich uprawnieniach może posłużyć się złośliwym plikiem o rozszerzeniu „.*job” i uzyskać uprawnienia systemowe (SYSTEM), co pozwoli osobie atakującej uzyskać pełny dostęp do systemu docelowego. Exploit na chwilę obecna nie jest także wykrywany przez żadne oprogramowanie antywirusowe. Skan wykonany na portalu VirusTotal zwrócił 0/73 wyników wśród skanerów antywirusowych!
Na jedną ciekawa rzecz musimy zwrócić uwagę. Mianowicie podczas uruchamiania komendy „polarbear.exe” Windows Defender wykrył podejrzane działanie procesu i zasygnalizował nam to alertem. W przypadku PowerShell nie mieliśmy żadnego ostrzeżenia. Plus dla Windows Defender-a!
Więcej możliwości wykorzystania Windows Zero-Day?
Poza opublikowanym ostatnio exploitem, SandboxEscaper odgraża się, że posiada jeszcze 4 kolejne nieujawnione błędy zero-day na system Windows, z których trzy prowadzą do eskalacji uprawnień lokalnych, a czwarty pozwala atakującemu obejść zabezpieczenia piaskownicy (Sandbox). Szczegóły i kod nowych exploitów pod Windows opublikowany został zaledwie tydzień po comiesięcznych aktualizacjach łatek Microsoft. Oznacza to, że do tej poty nie istnieje żadna łatka dla tych podatności w obecnej wersji Windows, pozwalając każdemu na jej wykorzystywanie i nadużywanie.
Jak sobie radzić z problemem?
Jako użytkownicy systemu Windows 10, musimy jeszcze poczekać na poprawki bezpieczeństwa od Microsoft. Prawdopodobnie nie stanie się to wcześniej jak w przyszłym miesiącu z uwagi na comiesięczne aktualizacje zbiorcze wydawane przez Microsoft – chyba, że firma natychmiast przedstawi aktualizację awaryjną.
Od strony infrastruktury IT powinniśmy monitorować taski w folderach „C:\windows\System32\Tasks” i „C:\Windows\Tasks” oraz wszelkie zmian uprawnień na plikach systemowych.
Warto też włączyć audyt poleceń Powershell lub ograniczyć jego uruchamianie oraz wprowadzić w SIEM wskaźniki kompromitacji – odpowiednie flagi (IOC) pozwalające monitorować podejrzane zachowanie procesów i poleceń.