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

Dach płonie: walka z serwerami kontroli Flame'a

Aleksander Gostiew
Kaspersky Lab Expert
Dodany 5 czerwca 2012, 13:38 CEST

Aleksander Gostiew
Ekspert z Kaspersky Lab

W niedzielę 27 maja 2012 roku irańska grupa powołana do reagowania na zdarzenia naruszające bezpieczeństwo w sieci internet (MAHER CERT) opublikowała notatkę z informacją o odkryciu nowego ataku o nazwie kodowej „Flamer”. W poniedziałek 28 maja 2012 roku o godzinie 15:00 czasu polskiego, po zakończeniu dochodzenia zainicjowanego i wspieranego przez Międzynarodowy Związek Telekomunikacyjny (ITU), Kaspersky Lab i laboratorium CrySyS Lab z Węgier, ogłoszono wykrycie robaka Flame (znanego również jako Skywiper) - wyrafinowanego programu cyberszpiegowskiego, ukierunkowanego na atakowanie komputerów pracujących pod kontrolą systemu Windows na Bliskim Wschodzie.

Kilka godzin później, około godziny 18:00 czasu polskiego, centrum kontroli Flame’a, które operowało od kilku lat, zostało wyłączone.

Przez ostatnie tygodnie eksperci z Kaspersky Lab dokładnie monitorowali infrastrukturę dowodzącą Flamem. We współpracy z grupami GoDaddy i OpenDNS daliśmy radę wciągnąć do leja (w operacji „sinkholingu”) większość szkodliwych domen, wykorzystywanych przez Flame’a do nawiązywania komunikacji z centrum kontroli.

Zanim przejdziemy dalej chcielibyśmy złożyć podziękowania oddziałowi GoDaddy Network Abuse Department oraz Williamowi MacArthurowi za ich szybką reakcję i wyjątkowe wsparcie dla tego śledztwa. Serdeczne podziękowania składamy także zespołowi badawczemu OpenDNS za nieocenioną pomoc w trakcie prowadzonego dochodzenia.

Nasze wnioski z analizy infrastruktury można znaleźć poniżej.

Wprowadzenie

Ponieważ zarówno Flame, jak i Duqu wydają się być skierowane na podobne regiony geograficzne i zostały stworzone w podobnym celu, naszą analizę poprowadzimy z punktu widzenia porównania infrastruktury centrum kontroli Flame’a z infrastrukturą dowodzenia Duqu.

W przeszłości zespół ekspertów z Kaspersky Lab analizował infrastrukturę centrum kontroli Duqu (http://www.viruslist.pl/weblog.html?weblogid=780) i znalazł kilka ważnych szczegółów, takich jak preferencje napastników do wykorzystania CentOS, używanie SharpSSH do kontroli serwerów proxy i wykorzystanie ogromnej liczby zainfekowanych serwerów proxy w celu ukrycia prawdziwej tożsamości cyberprzestępców.

Podobną analizę przeprowadziliśmy w przypadku Flame’a. Na wstępie należy podkreślić, że Flame diametralnie różni się od Duqu: podczas gdy wszystkie serwery proxy centrum kontroli Duqu były linuksowymi hostami CentOS, wszystkie znane serwery kontroli Flame’a pracowały pod kontrolą Ubuntu.

Dodatkowo, podczas gdy Duqu używał wyszukanej metody do ukrycia prawdziwego adresu IP „statku matki” (wykorzystując przekierowania portów SSH), skrypty Flame’a po prostu pracowały na poszczególnych serwerach. Dowód jest prosty – w poniedziałek 28 maja wszystkie skrypty kontrolne zaczęły zwracać błędy 403 / 404. W przypadku Duqu prawdziwe szkodliwe skrypty umieszczone były na zdalnym serwerze i nigdy nie zostały odnalezione.

Z tego punktu widzenia możemy stwierdzić, że napastnicy wykorzystujący Duqu byli dużo bardziej skoncentrowani na ukryciu swojej działalności, niż operatorzy Flame’a.

Poniżej znajduje się porównanie infrastruktury centrów kontroli Duqu i Flame’a:

Duqu Flame
System operacyjny serwerów CentOS Linux Ubuntu Linux
Skrypty kontrolne Uruchomione na zdalnym serwerze, ekranowanym poprzez przekierowania portów SSH Uruchomione na poszczególnych serwerach
Liczba ofiar na serwer 2-3 50+
Szyfrowanie połączeń z serwerem SSL + zastrzeżone szyfrowanie oparte na AES SSL
Kompresja połączeń Brak Zlib i modyfikowana kompresja PPMD
Liczba znanych domen kontrolnych Brak danych 80+
Liczba znanych kontrolnych adresów IP 5 15+
Ilość serwerów proxy, wykorzystywanych do ukrywania tożsamości 10+ Brak danych
Strefa czasowa operatora centrum kontroli GMT+2 / GMT+3 Brak danych
Programowanie infrastruktury .NET Brak danych
Lokalizacja serwerów Indie, Wietnam, Belgia, Wielka Brytania, Holandia, Szwajcaria, Korea itd. Indie, Wietnam, Belgia, Wielka Brytania, Holandia, Szwajcaria, Korea itd.
Liczba adresów IP / domen centrów kontroli wbudowanych w szkodnika 1 5, możliwość uaktualniania listy
Certyfikat SSL samopodpisany samopodpisany
Stan serwerów Prawdopodobnie zhakowane Prawdopodobnie kupione
Połączenia SSH Nie Tak

Kiedy komputer zostanie zainfekowany Flame’m używa domyślnej konfiguracji, która zawiera 5 domen serwerów kontroli. Przed kontaktem z tymi serwerami szkodliwy program sprawdza połączenie internetowe próbując uzyskać dostęp do witryny http://www.microsoft.com (windowsupdate.microsoft.com) oraz www.verisign.com używając HTTPS. Jeśli dostęp się powiedzie, zainfekowany komputer rozpoczyna nawiązywanie połączenia z centrum kontroli.

Oprócz konfiguracji statycznej, Flame posiada bazę danych dodatkowych serwerów kontroli. Sprawdziliśmy tę bazę danych. Może zostać ona uaktualniona z samego serwera kontroli, zawiera 5 – 6 dodatkowych domen. W sumie uruchomiona instalacja Flame’a może używać listy około 10 domen do komunikacji z centrum kontroli. Interesujący jest fakt, że Flame zawiera dziennik aktywności, w którym znajdują się raporty połączeń z serwerami kontroli, wraz ze znacznikami czasu.

Analizując próbki Flame’a pozyskane z Bliskiego Wschodu zauważyliśmy, że próbują one kontaktować się z pięcioma różnymi domenami. Dodatkowa konfiguracja zawierała 6 innych domen. Z dzienników aktywności mogliśmy wyłuskać 5 kolejnych domen, w sumie 11 unikalnych domen używanych przez daną próbkę szkodliwego oprogramowania.

Sprawdzając konkretne adresy IP zidentyfikowaliśmy kolejne 30 domen, które hostowane były na tych samych maszynach. Analizując historię adresów IP dodatkowych domen, odkryliśmy kolejne 40 domen, które wydają się być połączone z poprzednimi. W sumie wykryliśmy ponad 80 różnych domen przynależnych do infrastruktury centrum kontroli Flame’a.

Domeny centrum kontroli Flame’a zostały zarejestrowane z użyciem długiej listy fałszywych tożsamości i przy pomocy różnych rejestratorów. Proces rozpoczął się już w roku 2008! Ogólnie rzecz biorąc, na każdą fałszywą tożsamość zarejestrowano 2 - 3 domeny, w rzadkich przypadkach na jedną tożsamość przypadały 4 domeny.

Największa partia domen centrum kontroli Flame’a została zarejestrowana przy pomocy organizacji GoDaddy.

Niektóre z fałszywych tożsamości, wykorzystywanych do rejestrowania domen, to nazwy takie jak: Adrien Leroy, Arthur Vangen, George Wirtz, Gerard Caraty, Ivan Blix, Jerard Ree, Karel Schmid, Maria Weber, Mark Ploder, Mike Bassett, Paolo Calzaretta, Robert Fabous, Robert Wagmann, Romel Bottem, Ronald Dinter, Soma Mukhopadhyay, Stephane Borrail, Traian Lucescu, Werner Goetz lub Will Ripmann.

Wiele z tych fałszywych tożsamości posiada fałszywe adresy w Niemczech i Austrii, szczególnie w Wiedniu. Nie mamy pojęcia, dlaczego akurat Wiedeń okazał się tak atrakcyjnym wyborem dla cyberprzestępców.

Przyjrzyjmy się bliżej fałszywym rejestracjom. Na przykład, rozważmy domenę "chchengine.com", która jest wykorzystywana przez szkodliwe oprogramowanie. Domena została zarejestrowana dla persony o nazwie „Karel Schmid” i adresie „rue dizerens 7, Geneva”. Tak naprawdę jest to adres hotelu zwanego „Appart’Hotel Residence Dizerens”:

Poniżej kolejny przykład domeny, tym razem zarejestrowanej przez osobę o personaliach „Ivan Blix”.

Adres właściciela domeny to „Koninginneweg 93, Oslo”. Poszukiwanie tego adresu ujawniło, że nie ma takiego miejsca w Oslo, natomiast istnieje taki adres w Amsterdamie. Okazało się, że znów jest to adres hotelu, tym razem o nazwie „Apple Inn”:

Wszystkie inne fałszywe tożsamości używały adresów hoteli, sklepów, formalnych organizacji, gabinetów lekarskich lub po prostu adresów nieistniejących.

Poprzez zbieranie informacji na temat infrastruktury centrum kontroli Flame’a, udało nam się połączyć w jeden duży obraz fragmenty tej niezwykle skomplikowanej układanki. Ilość serwerów i domen wykorzystywanych do działania Flame’a potwierdza naszą poprzednią opinię o złożoności tego szkodliwego oprogramowania:

Całkowita liczba znanych domen, wykorzystywanych przez centrum kontroli Flame’a oraz domen powiązanych wynosi aktualnie ponad 80. Domeny te zostały zarejestrowane w latach 2008 – 2012. Podczas ostatnich czterech lat serwery hostujące infrastrukturę centrum kontroli Flame’a były przenoszone pomiędzy m.in. Hong Kongiem, Turcją, Niemcami, Polską, Malezją, Litwą, Szwajcarią. Skala tej operacji jest zaiste ogromna!

Po stwierdzeniu wielu różnych fałszywych domen skontaktowaliśmy się z GoDaddy i zwróciliśmy się o przekierowanie wszystkich szkodliwych domen do naszego leja. Dodatkowo w operacji „zasysania domen” wsparła nas grupa bezpieczeństwa OpenDNS, chcąca zapewnić ochronę użytkownikom OpenDNS.

Serwery kontroli Flame’a

Jeżeli policzymy adresy IP używane przez serwery kontroli Flame’a podczas ostatnich czterech lat i wyeliminujemy adresy znanych usług hostingowych, tymczasowo stosowanych podczas rejestracji, otrzymamy 22 unikatowe adresy IP różnych serwerów kontroli.

Od czasu odkrycia Flame’a mieliśmy szansę przyjrzeć się dokładnie pięciu takim serwerom. Wszystkie z serwerów posiadały otwarte porty 22, 443 i 8080. Wydawały się pracować pod kontrolą dystrybucji Ubuntu systemu Linux – jeżeli damy wiarę nagłówkom Apache i SSH. Jeden z serwerów posiadał również otwarty port 80, jednakże został on zamknięty w następstwie ogłoszenia wykrycia Flame’a.

Wszystkie certyfikaty SSL używane przez centrum kontroli Flame’a były samopodpisane; certyfikat ostatniej aktywnej domeny (w Holandii) został prawdopodobnie wygenerowany 18 maja 2012 roku.

Interesujący szczegół: w sobotę, 2 czerwca 2012 roku, o godzinie 20:40 (GMT), domeny centrum kontroli Flame’a, które wcześniej wskazywały na serwer w Holandii (91.203.214.*) zostały przekierowane do serwera w Niemczech (78.46.253.*), hostowanego przez „Offenbach Hetzner Online Ag”. Nowy serwer został wyłączony w niedzielę, 3 czerwca 2012 roku.

Statystyki z KSN

Kaspersky Security Network (KSN) to infrastruktura na bazie chmury, używana przez produkty Kaspersky do zgłaszania niebezpieczeństw infekcji i dostarczania natychmiastowej ochrony w postaci czarnych list i reguł heurystycznych, mających na celu wychwytywanie najnowszych zagrożeń.

Użyliśmy KSN do wyśledzenia Flame’a, opierając się na fakcie, że szkodnik został stworzony z wykorzystaniem pewnych nazw, które są wyjątkowe. W późniejszym czasie zdobyliśmy próbkę kodu złośliwego oprogramowania i wykorzystaliśmy ją do śledzenia dystrybucji na całym świecie.

Bieżące statystyki KSN dla Flame’a:

To oczywiste, że większość celów znajduje się na Bliskim Wschodzie. Należy podkreślić, że niektóre ofiary mogły stosować VPN / usługi proxy. W takich przypadkach, zainfekowana maszyna mogła pokazać się z np. europejskim adresem IP znajdując się fizycznie na Bliskim Wschodzie. Należy mieć również świadomość, że niektóre „ofiary” mogły być w rzeczywistości maszynami innych badaczy. Ogólnie jednak, statystyki są na tyle dokładne, aby odzwierciedlić rzeczywisty rozkład geograficzny infekcji.

Poniżej zilustrowaliśmy rozmieszczenie geograficzne celów Flame’a:

A co z systemami operacyjnymi, które padły ofiarą Flame’a? Oto reprezentacja infekcji z punktu widzenia konkretnej wersji systemu Windows, na której „zagościł” Flame:

Większa część maszyn zainfekowanych Flame’m pracowała pod kontrolą 32 – bitowego systemu operacyjnego Windows 7. Tuż za nim uplasował się Windows XP. W tym miejscu należy zaznaczyć, że Flame nie działa pod 64 – bitowym Windowsem 7, który to system już wcześniej wskazaliśmy jako dobre rozwiązanie zabezpieczające przed infekcjami różnymi typami szkodliwych programów.

Statystyki z leja / OpenDNS:

Nasz partner, OpenDNS, stworzył oś czasu rejestracji w ostatnich latach domen centrum kontroli Flame’a. Animowany diagram można zobaczyć pod adresem: https://www.opendns.com/flame-timeline/

W zeszłym tygodniu nasz lej zarejestrował wielokrotne zgłoszenia z zainfekowanych komputerów: poniżej widać podział według lokalizacji. Należy zaznaczyć, że większość infekcji została już wyleczona przez produkty antywirusowe, więc to, co obserwujemy, pochodzi od użytkowników nieposiadających aplikacji antywirusowych lub używających przestarzałych wersji takich produktów.

Dodatkowo, udało się zlokalizować infekcje w Wielkiej Brytanii, Hiszpanii, Rosji i Rumunii.

Poniżej znajduje się 10 domen najczęściej używanych przez zainfekowane komputery do komunikowania się z naszym lejem:

Aktualnie do leja Kaspersky Lab udało się zassać następujące 28 domen: flashupdates.info, nvidiadrivers.info, nvidiasoft.info, nvidiastream.info, rendercodec.info, syncstream.info, videosync.info, dnslocation.info, dnsmask.info, dnsportal.info, dnsupdate.info, flushdns.info, localgateway.info, pingserver.info, serveflash.info, serverss.info, autosync.info, bannerspot.in, bannerzone.in, micromedia.in, mysync.info, newsync.info, syncdomain.info, synclock.info, syncprovider.info, syncsource.info, syncupdate.info oraz ultrasoft.in.

Dane ładowane do leja

Kiedy Flame łączy się z lejem, wysyła zgłoszenie POST identyfikujące szkodnika. Następnie przesyła większy fragment danych, który zawiera dużo „interesujących” informacji, takich jak: wersja szkodliwego oprogramowania, konfiguracja szkodnika, historia działań wykonanych w systemie, dane wydobyte z dokumentów itd.

We wszystkich obserwowanych przez nas konfiguracjach użyte było to samo hasło – „LifeStyle2”. Hasło jest przechowywane w pliku konfiguracyjnym Flame’a i może zostać zmienione.

Pakiety danych ładowane do leja zawierają zaszyfrowane dzienniki i inne skompresowane dane. Odszyfrowując dane można poznać dokładną wersję, jaką Flame zgłasza swojemu operatorowi.

Rozkład wersji Flame’a komunikujących się z naszym lejem wygląda następująco:

Większość ofiar została zainfekowana wersją 2.242, która jest jednocześnie wersją wykrytą i analizowaną przez nas. Wygląda na to, że jest to najbardziej popularny wariant. Co ciekawe, nie jest to najnowsza wersja. Mamy już sygnały od ofiar zainfekowanych wersją 2.243!

Interesująca jest również wersja 2.080 – jest to dużo mniejszy plik “mssecmgr.ocx” (około 890 KB), który nie posiada wielu modułów obecnych w wersjach o rozmiarach 6 MB. Mamy kopie tego wariantu i analizujemy je równolegle z wersjami o większym rozmiarze.

Jeżeli chodzi o komputery łączące się z naszym lejem - istnieją trzy arcyciekawe przypadki: komputery w Libanie, Iraku i Iranie. Podczas operacji zasysania domen wersje Flame’a na tych maszynach zmieniły się, co sugeruje, że szkodnik uaktualnił się samoczynnie. W dwóch przypadkach wersja 2.212 stała się wariantem 2.242. Wskazuje to na obecność nieznanego jeszcze centrum kontroli, które działało podczas procesu sinkholingu, lub na wykorzystanie przez Flame’a nieznanego mechanizmu aktualizacji.

Pośród danych wyprowadzanych z systemów ofiar ogromne zainteresowanie cyberprzestępców budziły projekty aplikacji AutoCAD. Jest to interesujące ze względu na fakt, że szkodnik Duqu również „gustował” w plikach AutoCADa. Dodatkowo do plików formatu DWG, który jest macierzystym formatem aplikacji AutoCAD, szkodnik przeczesuje również pliki PDF, pliki tekstowe i inne dokumenty, a następnie sporządza raporty podsumowujące wyniki swoich działań. Poluje również na wiadomości e-mail i inne typy „interesujących” (wartościowych) plików, zdefiniowane w ustawieniach konfiguracyjnych Flame’a.

Dane przesyłane do centrum kontroli są szyfrowane z użyciem prostego szyfru XOR sprzężonego z szyfrem substytucyjnym. Dodatkowo, wiele bloków wewnątrz jest skompresowanych z użyciem bibliotek kompresji zlib i ppdm.

Co ciekawe, dane ładowane do leja dzielone są na pakiety o rozmiarze 8 192 bajtów. Jest to prawdopodobnie rozwiązanie mające na celu przeciwdziałanie błędom - wiadomym jest, że internet w krajach Bliskiego Wschodu jest bardzo powolny i zawodny.

Kolejną ciekawą cechą Flame’a jest używanie do wyprowadzania danych połączeń SSH. Choć nie byliśmy w stanie odtworzyć tego zachowania, zdaje się, że kiedy połączenie z internetem jest dostępne, ale serwery kontroli nie są osiągalne przez SSL, Flame używa połączenia SSH.

Połączenie SSH jest nawiązywane przez w pełni zintegrowaną bibliotekę, opartą na Putty. W chwili obecnej adres IP serwera i schemat nazwy użytkownika / hasła nie są znane. Możliwe, że są uaktualniane przez centrum kontroli i używane, jeśli wystąpią chwilowe problemy z SSL. Jedną z przyczyn używania połączeń SSH może być ogólny zakaz stosowania ruchu SSL / HTTPS w krajach takich jak Iran. Jeżeli połączenie SSL zostanie zerwane, Flame z powodzeniem może wykorzystać SSH do komunikacji z centrum kontroli.

W ostatnim tygodniu eksperci z Kaspersky Lab skontaktowali się wieloma zespołami powołanymi do reagowania na zdarzenia naruszające bezpieczeństwo w sieci internet, informując grupy w wielu krajach o domenach i adresach IP serwerów centrum kontroli Flame’a. Chcielibyśmy podziękować im za wsparcie naszego dochodzenia.

Zespoły reagujące na naruszenia bezpieczeństwa w sieciach należących do instytucji rządowych, chcące uzyskać szczegółowe informacje na temat domen centrum kontroli Flame’a, zapraszamy do kontaktu z nami pod adresem e-mail: theflame@kaspersky.com.

Podsumowanie i wnioski:

  • Infrastruktura centrum kontroli Flame’a, która działała od lat, stała się nieaktywna natychmiast po naszym zeszłotygodniowym ujawnieniu istnienia tego szkodliwego oprogramowania.
  • Zidentyfikowaliśmy około 80 domen, które zdają się przynależeć do infrastruktury centrum kontroli Flame’a.
  • Domeny centrum kontroli Flame’a zostały zarejestrowane z użyciem obszernej listy fałszywych tożsamości i przy pomocy różnych rejestratorów. Proces rozpoczął się już w roku 2008.
  • Napastnicy wykazują duże zainteresowanie dokumentami PDF, Office i rysunkami AutoCad.
  • Dane ładowane do centrum kontroli są szyfrowane z użyciem stosunkowo prostych algorytmów. Skradzione dokumenty są kompresowane z użyciem Zlib i zmodyfikowanej kompresji PPDM.
  • Do wyprowadzania danych Flame używa połączeń SSH (jako alternatywy dla SSL). Połączenie SSH jest ustanawiane przy pomocy w pełni zintegrowanej biblioteki opartej na Putty.
  • 64 – bitowy system operacyjny Windows 7, który wcześniej wskazaliśmy jako dobre rozwiązanie opierające się infekcji różnymi złośliwymi programami, jest skuteczny również w przypadku Flame’a.

Źródło:
Kaspersky Lab