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

Flame: replikacja przez serwer proxy utworzony w wyniku ataku MITM

Aleksander Gostiew
Kaspersky Lab Expert
Dodany 8 czerwca 2012, 12:53 CEST

Szkodliwy program Flame używa do replikacji wielu metod. Najbardziej interesujące wydaje się być wykorzystywanie usługi Microsoft Windows Update, zaimplementowane w trzech modułach szkodnika ("SNACK", "MUNCH" i "GADGET"). Jako części składowe Flame'a, moduły te są łatwo rekonfigurowalne. Zachowanie modułów jest nadzorowane przez globalny rejestr Flame'a - bazę danych, która zawiera tysiące opcji konfiguracji.


SNACK: spoofing NBNS

Moduł SNACK tworzy gniazdo sieciowe RAW dla wszystkich (lub tylko uprzednio zdefiniowanych) interfejsów sieciowych i rozpoczyna odbieranie wszystkich pakietów sieciowych. SNACK poszukuje pakietów NBNS innych komputerów w sieci, które oczekują na swoje nazwy sieciowe. Gdy taki pakiet jest odbierany, zapisywany jest do zaszyfrowanego pliku dziennika (“%windir%\temp\~DEB93D.tmp”) i przekazywany do dalszego przetwarzania.

Kiedy nazwa w żądaniu NBNS pasuje do wyrażenia "wpad*" lub "MSHOME-F3BE293C", SNACK odpowiada własnym adresem IP. Jeżeli zmienna "SNACK.USE_ATTACK_LIST" posiada wartość "True", SNACK sprawdza również, czy pakiety pochodzą z adresów IP określonych na liście "SNACK.ATTACK_LIST" i zgłasza odpowiedź komputerom z tymi adresami.

"Wpad" to nazwa używana do automatycznego wykrywania proxy. Odpowiadając własnym adresem IP na żądania nazwy "wpad", moduł SNACK ogłasza zainfekowany komputer serwerem proxy dla swojej sieci lokalnej.

Moduły SNACK i MUNCH komunikują się również z modułem GADGET, który oferuje zaplecze funkcyjne do obsługi różnych zdarzeń pochodzących z innych modułów. Rejestr Flame’a zawiera moduły LUA do przetwarzania zdarzeń, takich jak: "MUNCH_ATTACKED", "SNACK_ENTITY.ATTACK_NOW".


MUNCH: fałszowanie wykrywania proxy i żądań Windows Update

"MUNCH" to nazwa modułu serwera HTTP. Uruchamiany jest tylko wtedy, gdy zmienna "MUNCH.SHOULD_RUN" zostanie ustawiona na "True" i nie ma uruchomionych programów, które mogłyby ostrzec ofiarę. Programy te (aplikacje antywirusowe, zapory sieciowe, programy do nasłuchiwania sieci itp.) zdefiniowane są w rejestrze Flame'a, na liście zwanej "SECURITY.BAD_PROGRAMS".

Kiedy MUNCH zostanie uruchomiony, odczytuje bufor ze zmiennej "MUNCH.WPAD_DATA", zastępuje wzór “%%DEFAULT%%” adresem IP swojego najbardziej odpowiedniego interfejsu sieciowego i oczekuje żądania HTTP.

Zawartość zmiennej "MUNCH.WPAD_DATA"

Bufor "MUNCH.WPAD_DATA" jest w rzeczywistości plikiem WPAD, który jest wymagany przez klienty sieciowe do implementacji automatycznego wykrywania serwera proxy. Kod w pliku WPAD pasuje do hasha MD5 nazwy hosta, z którym klient łączy się wbrew zawartości własnej listy. Jeżeli host zostanie znaleziony, rozgłasza się jako proxy HTTP. Udało nam się zidentyfikować niektóre z hashów:

download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com

Tak więc, kiedy maszyna skonfigurowana do automatycznego wykrywania proxy próbuje uzyskać dostęp do jednego z hostów Windows Update, otrzymuje od modułu SNACK adres IP zainfekowanego komputera, a następnie otrzymuje adres IP tego samego komputera jako serwera proxy z pliku "wpad.dat" dostarczanego przez moduł MUNCH. Od tej chwili zgłoszenia do usługi Windows Update przechodzą przez serwer MUNCH.

Kiedy klient sieciowy połączy się z serwerem MUNCH i zażąda URI (Uniform Resource Identifier) innego niż “/wpad.dat” oraz “/ view.php”, wówczas serwer:

1) Uruchamia "MUNCH.SHOULD_ATTACK_SCRIPT" – skrypt Lua, który sprawdza, czy nagłówek User - Agent odpowiada przynajmniej jednemu z wzorców określonych w "MUNCH.USER_AGENTS.CAB_PATTERN_*". Pliki rejestru Flame'a będące w naszym posiadaniu zawierają następujące wzorce:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Sprawdza, czy żądane URI pasuje do dowolnego wzoru określonego w wykazie ciągów znaków zwanym "MUNCH.GENERIC_BUFFERS.*.data.PATTERN". Jeżeli jedno z wyrażeń jest zbieżne, otrzymuje bufor określony w odpowiedniej wartości "MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA", odczytuje wartość ładunku "MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA" i wysyła ją do klienta.

Wszystkie ładunki są wymienione w rejestrze Flame'a - posiadają nazwy rozpoczynające się od "MUNCH.GENERIC_BUFFERS_CONTENT.nazwa_ładunku" i są kodowane z użyciem ustalonego 104-bajtowego klucza RC4.

Wzorzec URI Nazwa ładunku
*v9/windowsupdate/redir/muv4wuredir.cab*
*v8/windowsupdate/redir/muv3wuredir.cab*
*v7/windowsupdate/redir/wuredir.cab*
*v6/windowsupdate/redir/wuredir.cab*
*ws03sp1/windowsupdate/redir/wuredir.cab*
WUREDIR
*/v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab*
WUSETUP
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab* XP_WUIDENT
*v5/redir/wuredir.cab* XP_WUREDIR
*download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/
AU/x86/XP/en/wusetup.cab*
XP_WUSETUP
*muauth.cab* MUAUTH
*muredir.cab* MUREDIR
*muident.cab* MUIDENT
*/version_s.xml VISTA_7_VERSION_S
*/version.xml VISTA_7_VERSION
*v9/windowsupdate/redir/muv4wuredir.cab*
*v8/windowsupdate/redir/muv3wuredir.cab*
*v7/windowsupdate/redir/wuredir.cab*
*v6/windowsupdate/redir/wuredir.cab*
*ws03sp1/windowsupdate/redir/wuredir.cab*
VISTA_7_WUREDIR
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab* VISTA_7_WUSETUPHANDLER
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab* VISTA_7_WUCLIENT
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab* VISTA_7_WSUS3SETUP
*v9/windowsupdate/selfupdate/wuident.cab* VISTA_7_WUIDENT

Większość ładunków to podpisane cyfrowo archiwa CAB. Archiwa zawierające szkodliwy kod zostały podpisane przez "MS" w grudniu 2010 roku i w listopadzie 2011 roku, natomiast inne archiwa zdają się pochodzić z prawdziwej usługi Windows Update i zostały podpisane przez "Microsoft Corporation".

Nazwa ładunku Zawartość Podpis / data
WUREDIR VISTA_7_WUREDIR wuredir.xml Microsoft Corporation
1 lipca 2009
WUSETUP Default/wuapplet2.ocx
Default/wuaucom.dat
Default/wuauinfo.ocx
Default/wuconf.ini
Default/wusetup.ocx
wsus3setup.cat
wsus3setup.inf
wuapplet2.ocx
wuaucom.dat
wuauinfo.ocx
wuconf.ini
wups2.cab
wups2.cat
wusetup.cat
wusetup.inf
wusetup.ocx
MS
10 listopada 2011
XP_WUIDENT wuident.txt Microsoft Corporation
25 maja 2005
XP_WUREDIR wuredir.xml Microsoft Corporation
16 czerwca 2005
XP_WUSETUP Default/ wuapplet2.ocx
Default/wuaucom.dat
Default/wuauinfo.ocx
wups2.cab
wusetup.cat
wusetup.inf
wusetup.ocx
MS
28 grudnia 2010
MUAUTH authorization.xml Microsoft Corporation
5 czerwca 2008
MUREDIR wuredir.xml Microsoft Corporation
1 lipca 2009
MUIDENT muident.txt MS
28 grudnia 2010
VISTA_7_VERSION_S pusty brak podpisu
VISTA_7_VERSION 92 bajty, plik inny niż CAB brak podpisu
VISTA_7_WUSETUPHANDLER WuSetupV.exe MS
28 grudnia 2010
VISTA_7_WUCLIENT update.cat
update.mum
MS
28 grudnia 2010
VISTA_7_WSUS3SETUP WUClient-SelfUpdate-
ActiveX~31bf3856ad364e35~x86~
~7.0.6000.381.mum
WuPackages.xml
MS
28 grudnia 2010
VISTA_7_WUIDENT wuident.txt MS
28 grudnia 2010

Ponieważ pliki CAB posiadają prawdziwe podpisy cyfrowe (aktualnie unieważnione przez Microsoft), usługa Windows Update odbiera je i przetwarza jako ważne uaktualnienia. Są one pobierane i instalowane, skutecznie wykonując swoją szkodliwą funkcję.

Główną zawartością ładunku plików CAB jest składnik downloadera zwany "Wusetup.ocx" lub "WuSetupV.exe". Zbiera on ogólne informacje o komputerze, z uwzględnieniem informacji o strefie czasowej, i próbuje pobrać obiekt "http://MSHOME-F3BE293C/view.php" z informacją hosta dołączoną do żądania URI. Ponieważ nazwa "MSHOME-F3BE293C" jest obsługiwana przez moduł SNACK, adres URL wskazuje na uruchomiony serwer MUNCH, który na tym URI "serwuje" główny moduł Flame'a ("mssecmgr.ocx").

WuSetupV pobiera plik, zapisuje go do "%windir%\Temp\~ZFF042.tmp" na docelowej maszynie, ładuje jako bibliotekę DLL i wywołuje eksport pliku jako "DDEnumCallback", co jest procedurą instalacyjną Flame'a. Nowa maszyna zostaje zarażona.


To lepsze niż zero-day!

Kiedy odkryliśmy Flame'a, rozpoczęliśmy przeszukiwanie jego kodu pod kątem istnienia chociaż jednego exploitu, który do rozprzestrzeniania Flame'a i infekowania innych komputerów wewnątrz sieci wykorzystywałby lukę zero-day. Biorąc pod uwagę stopień zaawansowania szkodnika, jego wyrafinowanie i fakt, że był w stanie zainfekować w pełni załatane maszyny Windows 7, powinien istnieć przynajmniej jeden taki exploit. To, co znaleźliśmy teraz, jest dużo lepsze od kodu, który wykorzystywałby lukę zero-day. To faktycznie wygląda bardziej jak kod "god mode" – poprawny kod podpisany z użyciem pęku kluczy pochodzących wprost od Microsoftu. Podpis został odkryty i natychmiast unieważniony przez Microsoft. Niezwłocznie opublikowane zostało zalecenie bezpieczeństwa wraz z aktualizacją KB2718704.