Stuxnet/Duqu: ewolucja sterowników

Od dwóch miesięcy badamy trojana Duqu, próbując ustalić, w jaki sposób pojawił się ten szkodnik, w jakich miejscach był rozprzestrzeniany i w jaki sposób działa. Mimo ogromnej ilości uzyskanych danych (z których większość nie została jeszcze opublikowana) nadal nie znamy odpowiedzi na podstawowe pytanie – kto stoi za Duqu?

Istnieją również inne kwestie, w większości dotyczące stworzenia tego trojana lub raczej platformy wykorzystywanej do implementacji Duqu oraz Stuxneta.

Pod względem architektury platforma wykorzystana do stworzenia Duqu i Stuxneta jest taka sama. Jest to plik sterownika, który ładuje główny moduł w postaci zaszyfrowanej biblioteki. Jednocześnie istnieje osobny plik konfiguracyjny dla całego szkodliwego „zespołu” oraz zaszyfrowany blok w rejestrze systemowym, który określa lokalizację ładowanego modułu i nazwę procesu do wstrzyknięcia.

Konwencjonalna architektura platformy dla Stuxneta i Duqu

Platformę można określić nazwą ‘Tilded’, ponieważ z jakichś powodów jej autorzy stosują nazwy plików rozpoczynające się od znaku tyldy i litery d: "~d".

Uważamy, że Duqu i Stuxnet stanowiły równoległe projekty wspierane przez ten sam zespół twórców.

Na jaw wyszły również inne szczegóły sugerujące, że w latach 2007-2008 istniał prawdopodobnie jeszcze jeden moduł spyware oparty na tej samej platformie oraz kilka innych programów, których funkcjonalność nie była jasna między 2008 a 2010 rokiem.

Fakty te w poważnym stopniu podważają „oficjalną” historię Stuxneta. Postaramy się przytoczyć je w tym artykule, najpierw jednak podsumujemy to, co wiadomo na temat tego szkodnika.

„Oficjalna” historia Stuxneta

Zacznijmy od pytania: jak wiele plików sterowników Stuxneta jest znanych? Na dzień dzisiejszy odpowiedź brzmi: cztery. Więcej informacji na ich temat zawiera tabela poniżej.

Pierwsza modyfikacja robaka Stuxnet, stworzona w 2009 roku, wykorzystywała tylko jeden plik sterownika - mrxcls.sys bez podpisu cyfrowego.

W 2010 roku autorzy szkodnika stworzyli drugi sterownik mrxnet.sys (w celu ukrycia plików komponentów robaka na urządzeniach USB) i wyposażyli sterowniki mrxnet.sys oraz mrxcls.sys w cyfrowe certyfikaty Realtek. Sterownik mrxnet.sys nie odgrywa znaczącej roli w naszej opowieści, ponieważ jest to oddzielny moduł, który nie stanowi części ogólnej architektury platformy.

17 lipca 2010 roku ESET wykrył kolejny sterownik „na wolności” - jmidebs.sys – który był bardzo podobny do znanego już mrxcls.sys, ale został stworzony zaledwie trzy dni przed wykryciem. Sterownik został opatrzony nowym certyfikatem – tym razem wydanym przez Jmicron.

Do niedawna nie było wiadomo, jaki jest cel tego pliku, jednak powszechnie uważano, że był spokrewniony ze Stuxnetem. Według jednej z teorii, centrum kontroli Stuxneta próbowało zastąpić starą wersję z certyfikatem Realtek nową. Autorzy robaka albo mieli nadzieję, że w ten sposób uniemożliwią wykrycie go przez programy antywirusowe, albo zastąpili certyfikat, który został zablokowany.

Niestety, teoria ta nie została potwierdzona - Jmidebs.sys nigdy nie został nigdzie wykryty. Nie znaleziono również nowej wersji Stuxneta potrafiącej zainstalować ten plik.

Taka jest oficjalna historia o Stuxnecie. Jednak, jak już wspomniałem wyżej, w trakcie naszych badań odkryliśmy nowy dowód, który zostanie omówiony w dalszej części tego tekstu.

Nieznane wcześniej sterowniki

rtniczw.sys

Podczas analizowania incydentu z udziałem Duqu, którego ofiarą padł jeden z użytkowników, wykryliśmy coś nowego – coś, co potencjalnie mogło mieć wpływ na wszystko, co wiemy na temat Stuxneta.

Na komputerze ofiary został znaleziony nietypowy plik, wykryty przez nasz silnik antywirusowy jako Rootkit.Win32.Stuxnet.a. Werdykt miał odpowiadać znanemu plikowi mrxcls.sys, który został opisany wyżej, jednak nazwa wykrytego pliku i suma kontrolna różniły się!

Plik ten to rtniczw.sys, o rozmiarze 26 872 bajtów, MD5 546C4BBEBF02A1604EB2CAAAD4974DE0.

Plik miał trochę większy rozmiar niż mrxcls.sys, który posiadał podpis cyfrowy Realtek. To sugerowało, że rtniczw.sys również posiada podpis cyfrowy. Udało nam się zdobyć kopię tego pliku i ze zdziwieniem stwierdziliśmy, że stosował ten sam certyfikat Realteka, ale z inną datą podpisu pliku niż mrxcls.sys: rtniczw.sys został podpisany 18 marca 2010 roku, podczas gdy sterownik mrxcls został podpisany 25 stycznia tego samego roku.

Ponadto, rtniczw.sys stosował klucz rejestru oraz blokadę danych konfiguracyjnych, która nie była wykorzystywana w Stuxnecie. Stuxnet używał klucza “MRxCls” oraz wartości “Data”, podczas gdy w przypadku rtniczw.sys, klucz to “rtniczw”, a wartość “Config”.

Szczegółowa analiza kodu wykrytego w rtniczw.sys nie ujawniła innych różnic w stosunku do sterownika “referencyjnego”: był to ten sam plik mrxcls.sys, stworzony w tym samym roku, w tym samym dniu i o tej samej godzinie - 1 stycznia 2009 r.

Szukaliśmy dodatkowych informacji o innych użytkownikach, którzy posiadali ten sam plik, ale nie zdołaliśmy niczego znaleźć! Co więcej, w żadnej przeglądarce nie znaleźliśmy żadnych informacji o nazwie pliku (rtniczw.sys) lub jego MD5. Plik został zidentyfikowany tylko jeden raz: został przesłany do przeskanowania przez VirusTotal z Chin w maju 2011 roku.

Badany przez nas system został najwyraźniej zainfekowany pod koniec sierpnia 2011 roku. Należy podkreślić, że w systemie nie została zidentyfikowana infekcja Stuxneta; nie zostały znalezione żadne dodatkowe pliki z zestawu Stuxneta. Znaleźliśmy jednak pliki Duqu.

Doszliśmy do wniosku, że mogły istnieć inne pliki sterowników podobne do pliku „referencyjnego” mrxcls.sys, które nie należą do znanych wariantów Stuxneta.

rndismpc.sys

Sprawdzenie naszej kolekcji szkodliwego oprogramowania pomogło zidentyfikować kolejny interesujący plik, który został dodany do niej ponad rok temu. Plik miał nazwę rndismpc.sys, rozmiar 19 968 bajtów i MD5 9AEC6E10C5EE9C05BED93221544C783E.

Okazało się, że jest to kolejny sterownik o funkcjonalności bardzo zbliżonej do mrxcls.sys z wyjątkiem kilku szczegółów:

1. rndismpc.sys wykorzystuje klucz rejestru, który różni się od kluczy wykorzystywanych przez mrxcls i rtniczw – jest to klucz “rndismpc” o wartości “Action”;
2. wykorzystuje klucz szyfrowania, który różni się od tego używanego przez mrxcls/rtniczw – 0x89CF98B1;
3. data kompilacji pliku to 20 stycznia 2008 r., tzn. rok przed stworzeniem mrxcls/rtniczw.

Podobnie jak rtniczw.sys, plik rndismpc.sys nigdy nie został znaleziony na komputerach użytkowników. Nie wiemy, jaki szkodliwy program zainstalował go ani z jakim głównym modułem miał współpracować.

Łączące ogniwo: mrxcls.sys -> jmidebs.sys ->sterowniki Duqu

Uzyskane dane oraz dostępne informacje dotyczące sterowników wykorzystywanych w Duqu można podsumować w tabeli poniżej:

*Znane sterowniki Duqu posiadają unikatowe nazwy plików dla każdego wariantu. Jednak ich funkcjonalność jest całkowicie identyczna.

Według naszych analityków, jmidebs.sys jest ogniwem łączącym mrxcls.sys oraz sterowniki wykorzystane w Duqu w późniejszym czasie.

Kod sterowników mrxcls i jmidebs jest w dużej mierze podobny. Niektóre niewielkie różnice mogą być spowodowane różnymi ustawieniami oraz minimalnymi zmianami w kodzie źródłowym, podczas gdy jego cel pozostaje niezmieniony.

Jednak poważniejsze zmiany można znaleźć w kilku funkcjach:

1. W funkcji obsługi, która uzyskuje adresy funkcji API: wersja w mrxcls wykorzystuje w tym celu funkcję MmGetSystemRoutineAddress oraz odpowiednie nazwy tekstowe adresów przychodzących funkcji API. Wersja w jmidebs wywołuje swoje własne funkcje w celu uzyskania adresów API przy użyciu sum hash swoich nazw. Te same funkcje są wykorzystywane w sterownikach Duqu, podczas gdy lista hashów funkcji jest dwukrotnie dłuższa.
2. W funkcji tworzącej tymczasowe fragmenty kodu (stub) w celu wstrzyknięcia PNF DLL do procesów: wersja mrxcls wykorzystuje stub o całkowitym rozmiarze 6332 bajtów. Sterowniki jmidebs i Duqu wykorzystują stuby o całkowitym rozmiarze 7061 bajtów. Kod wykorzystany w modułach stub dla tych sterowników jest identyczny, ale posiada różne daty kompilacji.

Ewolucja sterowników

Stworzyliśmy mapę połączeń między znanymi sterownikami, których ewolucja oraz kluczowe etapy rozwoju są łatwe do wyśledzenia.

 
Ewolucja sterowników od 2008 do 2011 roku

rndismpc.sys, rtniczw.sys oraz jmidebs.sys

Jak widać na wykresie, nie wiadomo, który szkodliwy program wszedł w interakcję z następującymi trzema sterownikami: rndismpc.sys, rtniczw.sys oraz jmidebs.sys. Oczywiste pytanie brzmiałoby: czy zostały wykorzystane w Stuxnecie? Według nas, odpowiedź powinna brzmieć “nie”.

Przede wszystkim, gdyby zostały wykorzystane w Stuxnecie, zajmowałyby o wiele więcej miejsca niż poszczególne wykryte przez nas przypadki. Po drugie, nie zidentyfikowano żadnej wersji Stuxneta, która potrafi współdziałać z tymi sterownikami.

Plik rtniczw.sys został podpisany 18 marca 2010 roku, jednak 14 kwietnia 2010 roku autorzy Stuxneta stworzyli nowy wariant tego robaka, który wykorzystywał referencyjny plik mrxcls.sys. Jest oczywiste, że rtniczw.sys był przeznaczony do innych celów. To samo można powiedzieć o jmidebs.sys. Uważamy, że te trzy sterowniki są tylko pośrednio związane ze Stuxnetem i można je bezpiecznie wymazać z historii Stuxneta.

Jest również drugie pytanie: czy te sterowniki mogły być wykorzystane w Duqu?

Na to pytanie nie ma jednoznacznej odpowiedzi. Chociaż wszystkie znane warianty Duqu pochodzą z okresu listopad 2010 – październik 2011, uważamy, że istnieją wcześniejsze wersje tego trojana szpiegującego stworzone w celu kradzieży informacji. Trzy omawiane sterowniki mogły zostać bez trudu użyte we wcześniejszych wersjach Duqu lub w innych trojanach opartych na platformie Stuxnet/Duqu. Podobnie jak Duqu trojany te były najprawdopodobniej wykorzystywane w atakach ukierunkowanych przed pojawieniem się Stuxneta (co najmniej w 2008 roku), w czasie, gdy był aktywny i po zamknięciu jego centrum kontroli. Prawdopodobnie były to równoległe projekty, a Stuxnet został stworzony później na podstawie zdobytego doświadczenia i kodu, który został napisany już wcześniej. Wydaje się wysoce nieprawdopodobne, że był to jedyny projekt realizowany przez jego autorów.

Proces tworzenia sterowników

Spróbujmy wyobrazić sobie, jak wygląda proces tworzenia sterowników. Kilka razy w roku autorzy kompilują nową wersję pliku sterownika, tworząc plik referencyjny. Głównym celem tego pliku jest ładowanie i wykonanie głównego modułu, który jest tworzony oddzielnie. Może to być Stuxnet lub Duqu, albo jakiś inny program.

Kiedy trzeba użyć sterownika dla nowego modułu, autorzy wykorzystują wyspecjalizowany program w celu zmodyfikowania informacji w pliku “referencyjnym” sterownika, tj. informacji o jego nazwie i usłudze jak również kluczu rejestru i jego wartości.

Warto podkreślić, że cyberprzestępcy nie tworzą nowego pliku od podstaw, ale podrasowują gotowe. To oznacza, że mogą stworzyć dowolną liczbę różnych plików sterownika, z których każdy będzie miał dokładnie tę samą funkcjonalność i datę utworzenia.

W zależności od celu ataku i ofiary trojana można następnie podpisać kilka plików sterowników przy użyciu legalnych certyfikatów cyfrowych o nieznanym pochodzeniu.

Wnioski

Posiadane przez nas dane pozwalają stwierdzić z dużą dozą pewności, że platforma “Tilded” została stworzona pomiędzy końcem 2007 r. a początkiem 2008 r., przy czym najpoważniejsze zmiany przeszła na przełomie lata i jesieni 2010 roku. Zmiany te wynikały z rozwoju kodu oraz konieczności uniknięcia wykrycia przez rozwiązania antywirusowe. W latach 2007-2011 powstało wiele projektów dotyczących programów opartych na platformie “Tilded”. Stuxnet i Duqu to dwa z nich – jednak mogły być również inne, na razie jednak pozostają nieznane. Platforma wciąż jest rozwijana, co może oznaczać tylko jedno – w przyszłości prawdopodobnie pojawi się więcej modyfikacji.