Stan zagrożeń w internecie znajduje się obecnie na poziomie standardowym. Nie występują duże epidemie a eksperci z Kaspersky Lab nie zanotowali żadnych poważnych incydentów związanych z bezpieczeństwem. Poziom zagrożenia: 1

Shamoon the Wiper - szczegóły

Dmitrij Tarakanow
Kaspersky Lab Expert
Dodany 4 września 2012, 09:48 CEST
Tagi:

Nadal analizujemy szkodliwe oprogramowanie o nazwie Shamoon. Ten post zawiera informacje o tym, co znajduje się wewnątrz szkodliwych próbek wykorzystywanych w kampanii.

Zagnieżdżenie próbek

Główny plik wykonywalny (dropper) zawiera 3 zasoby, z których każdy utrzymuje zaszyfrowany program. Szyfr jest dość prosty - XOR wyrażony przez dword. Wspominaliśmy o tym w naszym pierwszym poście.

Zasób PKCS12:112 przechowuje zakodowany plik wykonywalny, poddany operacji XOR z wartością klucza 0xFB5D7F25. Jest on zapisywany na dysku przy użyciu nazwy pobieranej z zaszytej w kodzie na sztywno listy w folderze %WINDIR%\System32 podczas wykonywania droppera. Z kolei ten moduł zawiera zasób READONE :101 (klucz XOR: 0xF052AF15), sterownik zakodowywany i zapisywany na dyskach jako %WINDIR%\System32\Drivers\DRDISK.SYS.

Zasób PKCS7:113 zawiera plik wykonywalny, poddany operacji XOR z kluczem 0x00BAD417 i zapisywanym na dysku jako %WINDIR%\System32\NETINIT.EXE podczas wykonywania droppera.

Zasób X509:116 obejmuje wersję AMD64 głównego pliku wykonywalnego Shamoona (droppera), poddaną operacji XOR z kluczem 0xBB1AC25C. Ten z kolei zawiera niemal ten sam zestaw zasobów co jego odpowiednik dla Win32: PKCS12:112 – plik ten jest wersją AMD64 pierwszego zrzuconego pliku wykonywalnego, wersję AMD64 sterownika oraz PKCS7:113 – wersję AMD64 NETINIT.EXE. Tak więc, zasoby 112 i 113 posiadają te same klucze XOR w wersji x86 oraz droppera wersji AMD64, jednak klucze sterowników są inne: wersja AMD64 jest poddana operacji XOR - wartość 0x10CAFFA0, podczas gdy wersja x86 jest szyfrowana przy użyciu 0xF052AF15. Poniższy obraz jest wart tysiąca słów i podsumowuje, co znajduje się w plikach dyskowych:

Zagnieżdżenie próbek Shamoona

A zatem główny plik wykonywalny Shamoona działa w 3 trybach:

1. Próbka jest uruchamiana jako typowy program w systemie 32-bit OS.
2. Próbka jest uruchamiana w systemie 64-bitowym.
3. Oróbka jest uruchamiana jako usługa w systemie 32-bitowym.

Środowisko 64-bitowe

Najpierw, program sprawdza, czy został uruchomiony w 64-bitowym systemie operacyjnym. Jeżeli tak, zrzuca wersję AMD64 głównego pliku wykonywalnego poprzez odszyfrowanie zasobu X509:116 oraz zapisanie odszyfrowanych danych na dysku jako %WINDIR%\System32\trksrv.exe. Następnie tworzy i uruchamia usługę „TrkSvr” przy pomocy poniższego wiersza poleceń:

%WINDIR%\System32\cmd.exe /c "ping -n 30 127.0.0.1 >nul && sc config TrkSvr binpath= system32\
trksrv.exe && ping -n 10 127.0.0.1 >nul && sc start TrkSvr "

Przyjrzyjmy się, co robi program, gdy jest uruchomiony jako typowy program w 32-bitowym systemie operacyjnym.

Środowisko 32-bitowe: zwykłe uruchomienie, obecne są argumenty

Okazało się, że program oczekuje argumentów, które są traktowane jak lista adresów IP. Są to adresy IP komputerów, które szkodliwy program będzie próbował zainfekować. Jeżeli pierwszy argument stanowi tekst składający się z jednego znaku, wtedy program próbuje zainfekować komputery z sieci lokalnej, wymieniając ostatnią wartość adresu IP zainfekowanego komputera z przedziału od 1 do 254. Dla tego określonego adresu IP program próbuje otworzyć plik przy użyciu następujących ścieżek:

\\\ADMIN$\System32\csrss.exe
\\\C$\Windows\System32\csrss.exe
\\\D$\Windows\System32\csrss.exe
\\\E$\Windows\System32\csrss.exe

Innymi słowy, program próbuje uzyskać dostęp do foldera systemowego dostępnych komputerów w lokalnej (pod)sieci (lub komputerów z określonymi adresami IP w argumentach). Jeżeli szkodliwy program może otworzyć ten plik csrss.exe, tworzy swoją kopię na zdalnym komputerze w dostępnym folderze System32 pod losowo wybraną nazwą pobraną z zakodowanej na sztywno listy:

caclsrv.exe
certutl.exe
clean.exe
ctrl.exe
dfrag.exe
dnslookup.exe
dvdquery.exe
event.exe
findfile.exe
gpget.exe
ipsecure.exe
iissrv.exe
msinit.exe
ntfrsutil.exe
ntdsutl.exe
power.exe
rdsadmin.exe
regsys.exe
sigver.exe
routeman.exe
rrasrv.exe
sacses.exe
sfmsc.exe
smbinit.exe
wcscript.exe
ntnw.exe
netx.exe
fsutl.exe
extract.exe

Następnie dropper próbuje uruchomić swoją kopię poprzez stworzenie wyznaczonego zadania na zdalnym komputerze. W przypadku gdy nie powiedzie się infekcja zdalnego komputera/komputerów podczas tworzenia wyznaczonego zadania, szkodliwy program zmienia nazwę swojej kopii (utworzoną podczas inicjowania wyznaczonego zadania) na „trksvr.exe” i próbuje stworzyć i uruchomić usługę „TrkSvr” (widoczna nazwa: „Distributed Link Tracking Server“) związaną z tym plikiem wykonywalnym na zdalnym komputerze.

Przykład procedury propagacji

Środowisko 32-bitowe: zwykłe uruchomienie, brak argumentów

Kiedy program jest uruchomiony bez argumentów, instaluje lokalnie usługę „TrkSvr” (widoczna nazwa: „Distributed Link Tracking Server“) (kopiuje się do %WINDIR%\System32\trksvr.exe i tworzy odpowiednią usługę) i uruchamia ją. Na tym etapie autor zastosował interesującą sztuczkę, dzięki której szkodliwe oprogramowanie przetrwa powtórne uruchomienia: szkodnik zmienia konfigurację usługi „LanmanWorkstation” (widoczna nazwa: „Workstation” ). Sprawia ona, że usługa ta jest zależna od „TrkSvr”. Zazwyczaj jednak „Workstation” jest uruchamiana automatycznie podczas ładowania systemu operacyjnego.

Istnieje prostszy sposób wymuszenia na systemie operacyjnym, aby uruchomił usługę podczas startu – wystarczy ustawić odpowiednią opcję danej usługi. Ponadto, „TrkSvr” jest tworzona przez szkodliwe oprogramowanie z opcją tą dostosowaną do automatycznego uruchomienia. Trudno powiedzieć, dlaczego autorzy wybrali tę metodę.

Środowisko 32-bitowe: uruchamiany jako usługa

W końcu dochodzimy do ostatniego warunku – dropper jest uruchamiany jako usługa. Najpierw dropper zapisuje zasób PKCS7:113 jako %WINDIR%\System32\netinit.exe i uruchamia go z argumentem “1” na jeden z dwóch sposobów:

1. Tworzy wyznaczone zadanie w celu uruchomienia „netinit.exe 1”.
2. Uruchamia „netinit.exe 1” bezpośrednio poprzez wywołanie funkcji CreateProcess.

Usługa „TrkSvr” nieustannie sprawdza, czy proces netinit.exe został uruchomiony i jeżeli przestanie działać, uruchamia go powtórnie (tzn. jeżeli nie ma go na liście procesów).

Szkodliwa usługa usuwa w pętli wszystkie pliki wykonywalne z zakodowanej na sztywno listy (patrz wyżej) w lokalnym folderze %WINDIR%\System32. W ramach tej pętli program sprawdza jeszcze jeden warunek, zanim przejdzie do ostatniego etapu swojego uruchomienia.

Dropper ustala, czy nadszedł określony dzień. Data jest odczytywana z pliku „%WINDIR%\inf\netft429.pnf” lub (w przypadku niepowodzenia) wykorzystywana jest wartość zakodowana na sztywno. Zakodowana na sztywno data to 15 sierpnia 2012 r. 08:08 UTC. Wygląda na to, że funkcja sprawdzania daty działa niepoprawnie. Jeżeli celem było podzielenie linii czasu na „przed” i „po” określonym punkcie kontrolnym, autorowi nie udało się to działanie. Warunek zawiera błędną logikę.

Porównywanie daty

Jeżeli na przykład rok ma wartość 2013, ale bieżący miesiąc jest wcześniejszy niż miesiąc docelowy (powiedzmy luty), wtedy warunek dałby wynik, według którego bieżąca data znajduje się przed wartością punktu kontrolnego (sierpień 2012 r.). Logika ta jest po prostu błędna. Błąd ten potwierdza nasze początkowe stwierdzenie, że szkodnik Shamoon nie jest Wiperem atakującym irańskie systemy. Wiper jest najprawdopodobniej cyberbronią i w takim wypadku z pewnością został stworzony przez zespół profesjonalistów. Doświadczeni programiści raczej nie mieliby problemów ze stworzeniem poprawnej procedury porównywania daty.

Niezależnie od tego, warunek działa (aczkolwiek nie we wszystkich przypadkach) i dropper przechodzi do procedury finalizującej. Najistotniejszym działaniem wykonanym w tej procedurze jest zapisanie zasobu PKCS12:112 jako pliku wykonywalnego przy użyciu nazwy pobranej z zakodowanej na sztywno listy w folderze %WINDIR%\System32 oraz uruchomienie go (komponent ten wykonuje destrukcyjne działania szkodliwego oprogramowania Shamoon). Ponadto, program wykorzystuje nieparzysty zakodowany na sztywno tekst:

“kijjjjnsnjbnncbknbkjadc
kjsdjbhjsdbhfcbsjkhdf jhg jkhg hjk hjk
slkdfjkhsbdfjbsdf
klsjdfjhsdkufskjdfh”.

Również na tym etapie program sprawdza, czy na atakowanym systemie istnieje plik „c:\windows\temp\out17626867.txt” i ładuje obraz „myimage12767” ze swoich zasobów. Plik „out17626867.txt” nie jest zapisywany przez samego droppera i jak dotąd nie zlokalizowaliśmy żadnych odniesień do niego w innych komponentach tego szkodliwego oprogramowania. Dropper nie zawiera również w swoich zasobach obrazu „myimage12767”. Dlatego nie wiemy, dlaczego szkodnik sprawdza obecność tego pliku, do czego odnosi się plik .txt oraz jaki może być cel brakującego zasobu „myimage12767”. Uważamy, że ta część kodu, która działa z dziwnym tekstem, plikiem „out17626867.txt” oraz obrazem „myimage12767”, jest niepotrzebna i nie wspiera żadnej dodatkowej funkcjonalności. To wszystko na temat pliku wykonywalnego Shamoona. Wkrótce przedstawimy więcej szczegółów na temat innych komponentów tego szkodliwego programu.

PS Podziękowania dla moich kolegów Davida Emma oraz Kurta Baumgartnera za nieocenione komentarze i redakcję.