Stuxnet korzystał z kodu Flame’a

Gdy odkryto wirusa Flame i zauważono, że obszar jego infekcji pokrywa się w dużej mierze z celami Stuxnetu, rozpoczęto poszukiwania wspólnych elementów obu wirusów. Początkowo nie znaleziono w kodzie żadnych wskazówek – aż Kaspersky porównał Flame’a do starej wersji Stuxnetu…

Kiedy czerwcu 2010 wykryto istnienie Stuxnetu, badacze natrafili głównie na wersje kompilowane w marcu i kwietniu tego samego roku. Głębsza analiza wcześniej zebranych próbek wykazała, że istniała jeszcze jedna wersja wirusa – pochodząca z czerwca 2009. Nazwana Stuxnet.A, różniła się znacząco od swoich młodszych braci. Nie wykorzystywała błędu MS10-046 (plik .LNK), miała tylko jeden plik sterownika i infekowała napędy USB przez plik autorun.inf. Większość funkcjonalności charakterystycznej dla tej wersji zawarta była w zasobie PE pod nr 207, który zniknął z kolejnych edycji.

Tajemniczy zasób 207

Zasób 207 w plikach Stuxnetu.A to zaszyfrowany plik DLL, zawierający w środku inny plik wykonywalny. Kiedy analitycy Kasperskiego przyjrzeli się bliżej temu plikowi, odkryli, że jest nad wyraz podobny do aktualnej wersji pliku mssecmgr.ocx, stanowiącego komponent Flame’a. Łączą je nazwy zmiennych, architektura pliku, sposób szyfrowania i funkcjonalność. Analiza kodu źródłowego pokazuje całe fragmenty skopiowane między oboma wersjami. Na przykład moduł Stuxentu używał nazwy pliku dat3a.tmp, podczas kiedy moduł Flame’a dat3C.tmp. Pozostaje pytanie, gdzie użyty był dat3b.tmp – to odkrycie jest dopiero przed nami.

Mapa zasobów Stuxentu (źródło: Kaspersky)

Infekcja przez USB

Głównym zadaniem wspólnego modułu było rozpowszechnianie kopii wirusa poprzez zarażanie dysków USB. W obu wariantach mechanizm rozmnażania polega na zapisaniu na dysku USB pliku wykonywalnego wirusa, na końcu którego znajduje się plik autorun.inf – wykonywany przez nieświadomy niczego system operacyjny przy każdym włożeniu dysku do napędu USB. Zarówno Stuxnet.A jak i Flame korzystały z tej samej funkcjonalności.

Piąty 0day w Stuxnecie?

Stuxnet zasłynął między innymi tym, iż wykorzystywał 4 błędy typu 0day. Przy okazji analizowania podobieństwa do Flame’a analitycy Kasperskiego odkryli w pierwszej wersji Stuxnetu fragment kodu, wykorzystujący błąd w funkcji NtUserRegisterClassExWOW() w pliku win32k.sys, pozwalający na podniesienie uprawnień systemowych kodu. Błąd ten został załatany dopiero w czerwcu 2009, podczas kiedy zasób, zawierający złośliwy kod, powstał prawdopodobnie w lutym 2009. Oznacza to, że poprzeczka w konkursie „ilość wykorzystanych luk 0day w jednym wirusie” została ustawiona przez Stuxnet jeszcze wyżej, niż wcześniej sądzono.

Podsumowanie

Dotychczasowe odkrycia wskazują, że Flame, stworzony prawdopodobnie najdalej latem 2008 roku, istniał już, kiedy powstawała pierwsza wersja Stuxnetu (początek roku 2009). Twórcy Stuxnetu początkowo wykorzystali spore fragmenty kodu źródłowego niektórych mechanizmów Flame’a, które zostały później usunięte po wprowadzeniu do kodu innych mechanizmów rozpowszechniania wirusa, opartych o nowe luki typu 0day. Przypuszczalnie na wczesnym etapie tworzenia wirusa skorzystali z doświadczenia innego zespołu, który podzielił się z nimi wynikami swojej pracy. Brak na razie jakichkolwiek śladów współpracy późniejszej niż rok 2009, co sugeruje, że faktycznie oba wirusy mogły być tworzone przez dwa niezależne zespoły programistów.