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.
Panel kontrolny C&C został wykryty w "newsforyou/CP/CP.php". Otwarcie go w przeglądarce internetowej powoduje wyświetlenie ekranu logowania:
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
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ę.
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:
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").
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ń:
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:
Poniżej informacje na temat aktywności poszczególnych twórców:
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ń :
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:
"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łycztery pliki z katalogu "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:
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.
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.
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:
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".
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:
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.
Analizy
Blog