Nasza wcześniejsza analiza szkodliwego oprogramowania o nazwie Flame, zaawansowanego zestawu cyberszpiegowskiego powiązanego z operacją Stuxnet, została opublikowana pod koniec maja 2012 r. i ujawniła przeprowadzaną na ogromną skalę kampanię, ukierunkowaną na Bliski Wschód.

Szkodnik Flame, wraz ze wszystkimi swoimi składnikami stanowił przedmiot długiego i mozolnego śledztwa, które co rusz ujawniało nowe szczegóły. Natężenie informacji o tym zagrożeniu osiągnęło swoje apogeum 4 czerwca 2012 r., kiedy to firma Microsoft wydała ponadprogramową poprawkę służącą do zablokowania trzech fałszywych certyfikatów cyfrowych używanych przez Flame'a. Tego samego dnia potwierdziliśmy, że Flame faktycznie korzysta ze sfałszowanych certyfikatów i opublikowaliśmy naszą własną analizę techniczną tego wyrafinowanego ataku. To nowe oblicze Flame'a było tak zaawansowane technicznie, że tylko najlepsi w skali światowej kryptolodzy byli w stanie je wykreować. Od tamtej pory zniknęły sceptyczne żarty na temat Flame'a. W kolejnych dniach czerwca 2012 r. definitywnie potwierdziliśmy, że twórcy Flame'a komunikowali się z grupą odpowiedzialną za Stuxneta, co było kolejnym dowodem na to, że Flame został opracowany z poparciem rządowym. Opublikowaliśmy również naszą analizę serwerów centrum kontroli (C&C) Flame'a, opierając się na zewnętrznych obserwacjach i publicznie dostępnych informacjach. To pomogło w zrozumieniu, gdzie zlokalizowane były serwery C&C i w jaki sposób były one rejestrowane.

W niniejszym artykule publikujemy nowe informacje, które zostały zebrane podczas analizy serwerów centrum kontroli Flame'a. Śledztwo zostało przeprowadzone we współpracy z firmą Symantec, ITU-IMPACT i CERT-Bund/BSI.

Podstawowe informacje na temat badanego serwera C&C

• System operacyjny: 64-bitowy Debian 6.0.x;
• Wirtualizacja: w większości przypadków pod kontrolą OpenVZ;
• Używane języki programowania: PHP (większa część kodu), Python, bash;
• Baza danych: MySQL z tablicami InnoDB;
• Serwer sieciowy: Apache 2.x z samodzielnie podpisanymi certyfikatami.

Analiza serwera

Jeden z serwerów C&C, który analizowaliśmy, należał do europejskiej firmy posiadającej centra danych w krajach Unii Europejskiej. Udało nam się pozyskać obraz serwera, który był kontenerem systemu plików OpenVZ. Praca z kontenerami systemu plików OpenVZ wniosła pewne ograniczenia, które spowodowały podniesienie poziomu trudności analizy. Dla przykładu, kontenery OpenVZ nie pozwalają na przeszukanie wolnego miejsca na dysku twardym w celu odzyskania usuniętych plików. Konfiguracja serwera oparta była o typowy schemat LAMP (Linux, Apache, MySQL, PHP). Używano go zarówno do hostowania internetowego panelu sterowania, jak również do planowanego wykonywania w tle kilku w pełni automatycznych skryptów.

Serwer dostępny był poprzez protokół HTTPS (porty 443 i 80800). Katalogiem głównym dokumentów był folder "/var/www/htdocs/", który posiadał różne podkatalogi i skrypty PHP. Mimo, iż systemy posiadały zainstalowane PHP5, kod mógł pracować również na PHP4. Dla przykładu, "/var/www/htdocs/newsforyou/Utils.php" posiadał zdefiniowaną funkcję "str_split" implementującą logikę funkcyjną "str_split" z PHP5, która nie była dostępna w PHP4. Twórcy kodu C&C wdrożyli kompatybilność z PHP4 prawdopodobnie dlatego, iż nie byli pewni, która z dwóch głównych wersji PHP będzie instalowana na serwerach centrum kontroli.

Rysunek 1 - Zawartość katalogu "newsforyou"

Panel kontrolny C&C został wykryty w "newsforyou/CP/CP.php". Otwarcie go w przeglądarce internetowej powoduje wyświetlenie ekranu logowania:

Rysunek 2 - Logowanie do panelu kontrolnego

Nazwa użytkownika i hash hasła zostały później znalezione w bazie danych MySQL w tablicy "settings".

Login: username
Hash hasła (MD5): 27934e96d90d06818674b98bec7230fa

(ok, cracked: 900gage!@#)

 

Zresetowaliśmy login i hash hasła, by po zalogowaniu do panelu zobaczyć, jak wygląda on od strony atakującej. Byliśmy bardziej niż zaskoczeni, kiedy logowanie powiodło się.

Rysunek 3 - Interfejs panelu kontrolnego

W pierwszej chwili myśleliśmy, że panel został zaprojektowany przez jakieś "dzieciaki skryptowe". Wyglądał jak wczesna wersja alfa panelu C&C podrzędnego botnetu. Jednak powtórne obejrzenie tego obrazu sprawiło, że wszystko stało się jasne - napastnicy świadomie wybrali ten interfejs. W odróżnieniu od tradycyjnych cyberprzestępców, którzy implementują cukierkowe interfejsy WWW, przez przeciętnego użytkownika łatwo rozpoznawane jako panele sterowania botnetu, twórcy centrum kontroli Flame'a zadbali, aby panel był bardzo ogólny i bezpretensjonalny. Twórcy centrum kontroli nie używali w swoim panelu kontrolnym profesjonalnych zwrotów, takich jak: bot, botnet, infekcja, rozkaz itp. Zamiast tego zastosowali popularne słowa, jak: dane, upload, download, klient, nowości, blog, reklamy, kopia zapasowa itd. Wierzymy, że zostało to zrobione celowo, aby oszukać operatorów z firmy hostingowej, którzy mogliby przeprowadzać niezapowiedziane kontrole. Nie ma mowy żeby przesyłać rozkazy do zainfekowanych komputerów korzystając tylko z interfejsu sieciowego panelu C&C - i jest to kolejna cecha, która odróżnia ten projekt od innych botnetów. Zainfekowana maszyna była kontrolowana za pomocą mechanizmu wymiany informacji opartego na plikach (twórcy nazwali te pliki "kontenerami danych").

Aby wysłać polecenie lub zestaw poleceń do ofiary, atakujący przesyłał specjalnie spreparowane archiwum "tar.gz", które było przetwarzane po stronie serwera. Specjalny skrypt serwera wyodrębniał zawartość archiwum i szukał plików *.news oraz *.ad. Pliki te były wprowadzane do odpowiednich katalogów "news" i "ads". Panel C&C pozwalał napastnikowi wysłać uaktualnienia do określonej ofiary lub do wszystkich ofiar jednocześnie. Możliwe było nadanie poleceniom określonego priorytetu, co pozwalało zorganizować porządek wykonywania rozkazów. Priorytet i identyfikator celu były przesyłane w niekonwencjonalny sposób. Były one przechowywane w nazwie pliku, który atakujący ładował na serwer C&C. Poniżej znajduje się szablon nazw plików "nowości", których oczekiwał serwer C&C:

<losowa_liczba>_<typ_użytkownika>_<identyfikator_użytkownika>_<priorytet>.<rozszerzenie pliku>

Analiza plików źródłowych wykazała, że C&C może zrozumieć kilka protokołów komunikacyjnych i jest w stanie komunikować się z różnymi klientami:

• "OldProtocol";
• "OldProtocolE";
• "SignupProtocol";
• "RedProtocol" (wymieniony, ale nie zaimplementowany).

 

Bliższe spojrzenie na mechanizmy obsługi tych protokołów ujawniło cztery różne typy klientów o nazwach kodowych: "SP", "SPE", "FL" i "IP". Potwierdzamy, że szkodliwe oprogramowanie Flame zostało zidentyfikowane jako klient typu "FL". Oczywiście oznacza to, że istnieją co najmniej trzy inne, niewykryte do tej pory, narzędzia cyberszpiegostwa lub cybersabotażu autorstwa tych samych ludzi ("SP", "SPE" i "IP").

Rysunek 4 - Zależności klientów i protokołów istniejące w badanym C&C

Typowa sesja kliencka obsługiwana przez analizowane centrum kontroli rozpoczęła się od rozpoznania wersji protokołu i rejestracji informacji na temat połączenia. Następnie rozpoczęte zostało dekodowanie żądania klienta i zapisywanie go w zaszyfrowanej formie w lokalnym magazynie plików. Wszelkie metadane plików odebranych od klienta były przechowywane w bazie danych MySQL. Skrypt kontroli C&C szyfruje wszystkie pliki otrzymywane od klienta. Centrum kontroli używa do szyfrowania mechanizmu podobnego do PGP. Najpierw plik danych jest szyfrowany przy użyciu algorytmu Blowfish w trybie CBC (ze statycznym parametrem IV). Klucz Blowfish jest generowany losowo dla każdego pliku. Po zaszyfrowaniu pliku klucz Blowfish jest szyfrowany przy pomocy klucza publicznego z wykorzystaniem algorytmu asymetrycznego szyfrowania z funkcji PHP "openssl_public_encrypt".

Parametry szyfrowania:

IV: 12345678

Klucz publiczny OpenSSL:

-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtZslxFiR9KJE05Nhh7Xk
+lVVpD9F6AQnvZeknDiwL3SBjZB/dB/LLXtwiet8LUS6JYCXnaIq4NxW1PymwGFZ
zuc/B3p+ZAFPt06veOHOfaMAI0KDMb+laNPINvn/jJ8TfvCaUMUuMEY4sayh0xwD
MwSAazMYI8rvaaS/BqhI/6vPN6D02UIpwT1TSBVeRRoPBHuYE7A93b8vJw9sBGIp
KXZ90sgP1CjdAmCbhYelelninKdeTKCGvd5YXt86grWgEVf5WXzxXi3ZK1T4w0Yt
mNhUEAwS7zCdtZ+Ak8b0M83wAirASvPZiBl6qF8hqCT5pKkwgBG//kk8JicboLsM
VQIDAQAB
-----END PUBLIC KEY-----

Gwarantuje to, że nikt inny poza atakującym nie może odczytać plików pobranych z magazynu plików serwera, ponieważ tylko atakujący posiada klucz prywatny, który jest niezbędny do odszyfrowania plików pochodzących od klientów.

Pod względem funkcjonalności zainfekowane komputery klienckie obsługują stosunkowo niewiele poleceń:

• GET_NEWS: pobiera plik (lub pliki) z podkatalogów "./news", które są przypisane do aktualnego identyfikatora klienta. Pliki "nowości" zawierają uaktualnienia i dodatkowe moduły Flame'a, jak i również specjalne rozkazy, takie jak zmiana wartości kluczy rejestru.
• ADD_ENTRY: gromadzi informacje zebrane przez klienta.
• ADD_SUB_ENTRY: to samo co ADD_ENTRY.
• GET_AD: pobiera pliki z katalogu "./ad_path". Ta funkcjonalność wydaje się być wadliwa w kodzie C&C ponieważ nie istnieje katalog "./ad_path" tylko "./ads". Jednakże, atakujący może przesyłać pliki do katalogu "./ads" za pośrednictwem panelu kontrolnego.

 

Zauważyliśmy, że konwencja nazewnictwa plików i klas w skryptach nie jest typowa dla programistów środowiska Unix, ponieważ każde słowo w zmiennej, funkcji i nazwie pliku rozpoczynało się wielką literą. Istnieją również specjalne klasy, które są zdefiniowane, ale nigdzie nie są wywoływane - np. "IProtocol" (Protocol.php) i "IRequestHandler" (RequestHandler.php). Klasy, które nie są wywoływane, wykorzystano w mechanizmie dziedziczenia w programowaniu zorientowanym obiektowo. Klasy te nazywane są interfejsami w językach programowania, takich jak: C++, C# i Java. Wstawianie dużej litery "I" w prefiksach tych klas jest popularnym nawykiem wśród wielu deweloperów Windows C++ / C#.

Najcenniejszymi śladami, pozostawionymi w skryptach przez twórców, były ich pseudonimy i znaczniki czasowe:

• @autor [O]-ocenzurowano w 12/3/2006
• @autor [D]-ocenzurowano w 12/4/2006
• @autor [D]-ocenzurowano w 01/23/2007
• @autor [H]-ocenzurowano w 09/02/2007
• @autor [O]-ocenzurowano, [D] ocenzurowano
• @autor [D]-ocenzurowano (modyfikacje)
• @autor gruntowna modyfikacja przez [D]-ocenzurowano
• @autor [R]-ocenzurowano @copyright 2011

 

Poniżej informacje na temat aktywności poszczególnych twórców:

• [D]-ocenzurowano: pracował nad przynajmniej 31 plikami;
• [H]-ocenzurowano: pracował nad przynajmniej 10 plikami;
• [O]-ocenzurowano: pracował nad przynajmniej 4 plikami;
• [R]-ocenzurowano: pracował nad przynajmniej 1 plikiem (funkcja usuwania duplikatów plików).

 

Rysunek 5 - Oś czasu aktywności programistów kodu C&C Flame'a

Na podstawie powyższych informacji wnioskujemy, że pierwsze pliki kodu C&C powstały 3 grudnia 2006 r., co oznacza, że platforma Flame jest dużo starsza, niż pierwotnie szacowano. Za rozwój tego C&C odpowiedzialnych było czterech ludzi. Jasnym jest, że jeden z nich, [H]-ocenzurowano, posiadał dużo większe doświadczenie niż reszta. Zakodował kilka naprawdę inteligentnych poprawek i zaimplementował bardzo złożoną logikę; dodatkowo pokazując, że jest mistrzem jeżeli chodzi o algorytmy szyfrowania. Uważamy, że [H]-ocenzurowano był liderem tego zespołu.

Do przygotowania środowiska serwera operatorzy centrum kontroli użyli automatyki. Uważamy, iż zrobili tak ze względu na bardzo dużą liczbę serwerów - ręczne ustawianie wszystkiego po prostu nie miałoby sensu. Poniżej znajduje się część interesującego skryptu ("LogWiper.sh") z głównego katalogu systemu plików, który pozostał na analizowanym serwerze:

#! /bin/bash
apt-get install -y chkconfig
#stop history
echo "unset HISTFILE" >> /etc/profile
history -c
find ~/.bash_history -exec shred -fvzu -n 3 { } \;
service rsyslog stop
chkconfig rsyslog off
service sysklogd stop
chkconfig sysklogd off
service msyslog stop
chkconfigm syslog off
service syslog-ng stop
chkconfig syslog-ng off
shred -fvzu -n 3 /var/log/wtmp
shred -fvzu -n 3 /var/log/lastlog
shred -fvzu -n 3 /var/run/utmp
shred -fvzu -n 3 /var/log/mail.*
shred -fvzu -n 3 /var/log/syslog*
shred -fvzu -n 3 /var/log/messages*
#stop logging ssh
cp /etc/ssh/aa
sed -i 's/LogLevel.*/LogLevel QUIET/' /etc/ssh/sshd_config
shred -fvzu -n 3 /var/log/auth.log*
services sh restart
#delete hidden files
find / -type f -name ".*" | grep -v ".bash_profile" | grep -v ".bashrc" | grep "home" | xargs shred -fvzu -n 3
find / -type f -name ".*" | grep -v ".bash_profile" | grep -v ".bashrc" | grep "root" | xargs shred -fvzu -n 3 #stop apache2 logging
sed -i 's|ErrorLog [$/a-zA-Z0-9{ }_.]*|ErrorLog /dev/null|g' /etc/apache2/sites-available/default
sed -i 's|CustomLog [$/a-zA-Z0-9{ }_.]*|CustomLog /dev/null|g' /etc/apache2/sites-available/default
sed -i 's|LogLevel [$/a-zA-Z0-9{ }_.]*|LogLevel emerg|g' /etc/apache2/sites-available/default
sed -i 's|ErrorLog [$/a-zA-Z0-9{ }_.]*|ErrorLog /dev/null|g' /etc/apache2/sites-available/default-ssl
sed -i 's|CustomLog [$/a-zA-Z0-9{ }_.]*|CustomLog /dev/null|g' /etc/apache2/sites-available/default-ssl
sed -i 's|LogLevel [$/a-zA-Z0-9{ }_.]*|LogLevel emerg|g' /etc/apache2/sites-available/default-ssl
...
shred -fvzu -n 3 /var/log/apache2/*
service apache2 restart
#self delete
find ./ -type f | grep logging.sh | xargs -I { } shred -fvzu -n 3 { } \;

Skrypt zamieszczony powyżej jest używany do przystosowania środowiska serwera do pracy jako serwer C&C. Ten plik daje generalne rozeznanie w umiejętnościach i preferencjach operatorów C&C. Przede wszystkim widzimy, że operatorzy zainstalowali i używali narzędzia "chkconfig". Oto oficjalny opis pakietu "chkconfig" dla systemów Debian:

Chkconfig jest narzędziem systemowym, które pozwala włączać lub wyłączać usługi systemowe. Chkconfig to narzędzie do aktualizacji i kwerenda informacji startowych usług systemowych. Chkconfig manipuluje wieloma dowiązaniami symbolicznymi w "/etc/init.d/", ułatwiając administratorom systemowym procedurę ręcznego edytowania dowiązań symbolicznych. W Debianie istnieje kilka narzędzi o podobnej funkcjonalności, lecz właśnie to ten pakiet został użyty, ponieważ jest stosunkowo łatwy w obeznaniu dla użytkowników migrujących z innych dystrybucji linuksowych.

Jest to raczej nietypowe, ponieważ Debian posiada dużo innych popularnych narzędzi do manipulacji skryptami uruchamiającymi: "rcconf", "update-rc.d", "sysv-rc-conf" itd. Narzędzie "chkconfig" dla Debiana jest implementacją popularnego narzędzia RedHat o tej samej nazwie. Wygląda na to, że ludzie, którzy zarządzali serwerami C&C są bardziej obeznani z systemami RedHat. Przypomina to centra kontroli Duqu, które wszystkie były oparte na RedHat CentOS. Zaprezentowany skrypt zatrzymuje wszystkie znane systemowe demony logowania, takie jak: "rsyslog", "sysklogd", "syslog-ng", "msyslog". Podczas gdy pierwsze trzy są bardzo popularne na systemach Debian, "msyslog" nie występuje w oficjalnych repozytoriach publicznych. Wygląda na to, że "msyslog" jest wspierany przez firmę Core Security i może zostać uruchomiony na systemach Linux, BSD, Irix, Solaris i AIX. Najnowsza wersja demona "msyslog" została wydana 15 kwietnia 2003 r. Żaden z analizowanych przez nas systemów nie posiadał instalacji "msyslog". Nie jest jasne, dlaczego operatorzy wprowadzili specjalne linie kodu dla demona "msyslog".

Do czyszczenia danych operatorzy centrum kontroli Flame'a wykorzystali narzędzie niszczarki plików (funkcja "shred"). Podobne narzędzie zostało użyte wcześniej do czyszczenia serwerów przez operatorów Duqu. Na końcu skryptu znajduje się specjalna linia kodu wymuszająca usunięcie oryginalnego skryptu. Ta operacja może zostać również przeprowadzona przy pomocy rozkazu "shred", jednakże w tym miejscu pojawił się błąd, ponieważ nazwa pliku przeznaczonego do wymazania to "logging.sh", a aktualny skrypt nazywa "LogWiper.sh" - to właśnie dlatego skrypt nie został usunięty z systemu.

Demon systemowy "cron" został skonfigurowany do okresowego uruchamiania kilku zadań :

• Co 30 minut: php /var/www/htdocs/newsforyou/UnloadChecker.php
• Co 6 godzin: python /home/.../pycleaner/Eraser.py
• O północy: php /home/.../delete.php

 

Oprócz głównego katalogu serwera WWW, odkryliśmy również katalog domowy użytkownika o nazwie złożonej z trzech znaków. Jest to zbieżne z analizą innych serwerów, gdzie nazwy użytkowników zawsze zawierały trzy znaki i były wybierane losowo. To ujawniło kilka innych plików i katalogów użytych w projekcie:

Rysunek 6 - Katalog domowy użytkownika

"LogWiper_fixed.txt" jest tym samym plikiem, co opisany wcześniej "LogWiper.sh". "delete.php" jest skryptem PHP, który był uruchamiany zgodnie z terminarzem i służył do usuwania plików "nowości", starszych niż 30 dni. Usuwanie pliku było realizowane w sposób bezpieczny przy użyciu zewnętrznego wywołania narzędzia systemowego "shred". Ta procedura obsługiwała również usuwanie matadanych.

W zautomatyzowanych procedurach czyszczenia wykorzystywane były

cztery pliki z katalogu "pycleanscr":

Rysunek 7 - Katalog "pycleanscr"

Ten skrypt został zaprojektowany do usuwania plików tymczasowych z katalogu "tmp" serwera WWW i był przeznaczony do wykonywania zaplanowanych zadań. Jednak, błąd popełniony przez autorów całkowicie uniemożliwił jego uruchomienie. Demon "cron" otrzymał zadanie uruchamiania skryptu: "python /home/.../pycleaner/Eraser.py", podczas gdy właściwa ścieżka dostępu do skryptu to: "python /home/.../pycleanscr/Eraser.py". Wygląda na to, że operatorzy dysponowali kilkoma wariantami skryptów do kontroli wykorzystania dysku i zapobiegania nadużywaniu przestrzeni dyskowej. W katalogu domowym znaleźliśmy również plik "RequestHandler.php", co wskazuje na to, że operatorzy ostatnio pracowali nad tym plikiem. Wspomniany plik został umieszczony w katalogu domowym 14 maja 2012 r. Jest to ten sam plik, co plik w katalogu "newsforyou" na serwerze WWW. W późniejszym czasie, gdy analizowaliśmy obrazy innych serwerów, zdaliśmy sobie sprawę, że ten plik jednak różnił się od egzemplarzy z innych serwerów. Różnica tego pliku polegała na "przepychaniu" do klientów modułu o wewnętrznej nazwie "SHREDER", kiedy żadne inne moduły nie oczekiwały na "nowości". Moduł "SHREDER" jest dobrze znanym (opisanym dokładnie na blogu firmy Symantec), powiązanym z Flamem, plikiem binarnym Windows służącym do przeprowadzenia procesu samousuwania.

Katalog "Simulator" zawierał specjalne skrypty do wykonywania testów obciążenia infrastruktury C&C poprzez tworzenie zapytań, identycznych jak oryginalne żądania HTTP przesyłane przez zainfekowane ofiary. Operator mógł określić liczbę wątków roboczych i częstotliwość przychodzących żądań. To sugeruje, że deweloperzy użyli do celów testowych prawdziwych serwerów "produkcyjnych".

Po naszych wcześniejszych publikacjach otrzymaliśmy wiele pytań dotyczących ilości danych, który zostały wyprowadzone przez Flame'a. Jest to bardzo trudne do oszacowania, kiedy posiada się dostęp jedynie do pliku wykonywalnego szkodnika. Mało tego - nie będąc świadomym natury szkodnika, łatwo przeoczyć fakt, że jakiekolwiek dane mają dostęp do C&C, ponieważ operatorzy co 30 minut pobierali skradzione dane i usuwali je z serwera kontrolnego. Jeżeli z jakiegoś powodu nie zadziałałyby skrypty pobierania, nie stanowiłoby to problemu, ponieważ po stronie serwera znajdowały się inne skrypty kontrolujące ilość danych przechowywanych na serwerze. Jeżeli zostałaby osiągnięta wartość progowa, starsze dane zostałyby usunięte w celu zwolnienia miejsca na dysku. Tak więc, nawet jeśli "zdejmie się" serwer i przeanalizuje jego zawartość, można zobaczyć tylko niewielką część rzeczywistych danych, które zostały skradzione. Jednakże, z powodu pomyłki napastników, którzy nieświadomie zablokowali procedurę zacierania śladów, na serwerze pozostała spora kolekcja plików, które nie zostały usunięte. To pomogło zmierzyć rzeczywistą ilość skradzionych plików, przesyłanych tygodniowo do tego centrum kontroli: 5,5 GB skompresowanych danych.

Na jednym z serwerów napastnicy zapomnieli wyczyścić logi HTTP - to pozwoliło nam zorientować się, ile ofiar zostało podłączonych do serwera przez odwołania POST do kodu C&C Flame'a:

Rysunek 8 - Statystyki logowania do serwera WWW

W ciągu zaledwie jednego tygodnia (25 marca - 2 kwietnia 2012r.) zaobserwowaliśmy 5377 unikatowych adresów IP, które łączyły się z serwerem C&C - z czego przeważająca większość pochodziła z Iranu: 3702. Zaskakująco dużo adresów IP pochodziło również z Sudanu: 1280. Nasze poprzednie statystyki nie wykazywały wielu infekcji w Sudanie, więc musiała to być dedykowana kampania skoncentrowana na systemach w Iranie i Sudanie. Jeżeli jeden serwer był w stanie obsłużyć ponad 5000 ofiar w okresie jednego tygodnia i mając na uwadze, że działało wtedy kilka serwerów - szacujemy, że całkowita liczba ofiar Flame'a jest wyższa, niż pierwotnie prognozowaliśmy i zapewne przekracza 10 000.

SP, SPE, FL, IP, Gauss i Stuxnet

Pozyskany kod C&C obsługuje czterech głównych klientów: "SP", "SPE", "FL" i "IP". Najbardziej interesującym szkodnikiem z tej listy jest "IP", którego kod jest najświeższy w całym kodzie źródłowym:

/// Typy klientów
define('CLIENT_TYPE_UNKNOWN', 0);
define('CLIENT_TYPE_SP', 1);
define('CLIENT_TYPE_SPE', 2);
define('CLIENT_TYPE_FL', 3);
define('CLIENT_TYPE_IP', 6);

Klient "IP" jako jedyny używa protokołu "Signup Protocol". Aby wykryć protokół "Signup Protocol", serwer poszukuje specyficznej linii "uid=number&action=number" w żądaniu HTTP:

if (preg_match('/^uid\=\d+\&action\=\d+/', $data) === 1)
{
return array(RC_SUCCESS, PROTOCOL_SIGNUP);
}

Gwoli ścisłości - żadna z wersji szkodliwych programów, które badaliśmy, nie korzystała z tego schematu. Dla przykładu, Gauss używa "POST /userhome.php?sid=string==&uid=string=". Podobnie, Stuxnet używa "index.php?data=...". Tak więc jesteśmy prawie pewni, że "IP" to nie Gauss ani Stuxnet. Ponadto, obecny kod C&C nie jest w stanie obsłużyć połączeń Gaussa i Stuxneta.

Rezultaty z leja dla "SPE"

Z pomocą swoich partnerów, firma Kaspersky Lab skonfigurowała lej dla szkodnika Flame. Statystyki opracowane na podstawie danych pozyskanych z leja opublikowaliśmy w jednym z poprzednich artykułów.

Prawdopodobnie najbardziej interesującą rzeczą jest to, że opierając się na kodzie C&C Flame'a byliśmy w stanie podzielić połączenia nawiązywane z lejem na dwie kategorie:

• Połączenia "OldProtocol" - pochodzące od Flame'a;
• Połączenia "OldProtocolE" - używane przez "SPE".

 

W nawiązaniu do powyższego odkrycia potwierdzamy, że szkodliwe oprogramowanie znane jako "SPE" istnieje i aktualnie znajduje się "na wolności". Ponadto, nie stwierdziliśmy żadnych sygnałów pochodzących od tajemniczych szkodników "SP" i "IP".

Wnioski i podsumowanie

Podczas intensywnego dochodzenia, przeprowadzonego wraz z naszymi partnerami - firmami Symantec, ITU-IMPACT i CERT-Bund/BSI, zdołaliśmy odkryć szereg nieznanych dotąd faktów dotyczących Flame'a i powiązanej z nim platformy:

• Prace nad platformą kontroli Flame'a rozpoczęły się już w grudniu 2006 r.
• Komentarze, jakimi opatrzono kod źródłowy, wskazują, że w projekcie brało udział przynajmniej czterech programistów: [D]-ocenzurowano, [O]-ocenzurowano, [H]-ocenzurowano i [R]-ocenzurowano.
• Ostatnia zmiana kodu źródłowego miała miejsce 18 maja 2012 r. ("LogWiper_fixed.txt", "Constants.py").
• Kod C&C obsługuje cztery różne odmiany szkodliwego oprogramowania - nazwane przez autorów "SP", "SPE", "FL" i "IP". Kod C&C jest również odpowiedzialny za obsługę trzech protokołów komunikacyjnych ("OldProtocol", "OldProtocolE", "SignupProtocol").
• Z czterech odmian szkodliwego oprogramowania do tej pory znany jest tylko Flame ("FL"); trzy pozostałe pozostają nieznane ("SP", "SPE", "IP").
• Flame do komunikacji używa protokołu "OldProtocol".
• Istnieje nieznane, powiązane z Flamem, szkodliwe oprogramowanie o nazwie kodowej "SPE" i wierzymy, że znajduje się ono "na wolności".
• Flame nie jest zbyt "nowoczesny", jeśli spojrzeć na niego pod kątem kodu C&C.
• Najświeższy szkodnik zwany jest "IP" i nie został do tej pory wykryty.
• Kod jest (lub był) w fazie rozwoju - nowy protokół o nazwie "RedProtocol" nie został jeszcze w pełni zaimplementowany.

 

Dane prezentowane w niniejszym artykule wskazują na kilka istotnych faktów. Przede wszystkim prace nad projektami cyberszpiegowskimi rozpoczęto wcześniej, niż się spodziewano - już w roku 2006. Po drugie - kod, który obsługuje żądania jest bardzo złożony i używa silnego szyfrowania. Programiści, którzy pracowali nad tym szkodnikiem włożyli bardzo wiele starań, aby przypominał on legalną platformę zarządzania zawartością (CMS). I w końcu, skradzione dane są szyfrowane po stronie serwera w taki sposób, że tylko atakujący mogą je odczytać - twórcy szkodnika użyli kryptografii z wykorzystaniem silnego klucza publicznego. Są to funkcjonalności, których nie spotyka się w szkodliwym oprogramowaniu tworzonym na co dzień, a to potwierdza nasze wstępne przypuszczenia, że Flame jest atakiem sponsorowanym przez rząd.

W oparciu o kod pozyskany z serwera kontroli stwierdzamy, że Flame jest jednym z czterech projektów. Cel oraz charakter pozostałych trzech pozostają nieznane.