V posledních několika týdnech jsme byli zaneprázdněni zkoumá velení a řízení infrastruktury, kterou využívají Duqu.
Nyní je dobře známý fakt, že původní Duqu vzorky byly pomocí C & C serveru v Indii, který se nachází na poskytovatele služeb Internetu s názvem Webwerks. Od té doby další Duqu C & C byl objeven server, který byl umístěn na serveru v Combell Group NV v Belgii.
V Kaspersky Lab jsme v současné době katalogován a identifikovat více než 12 různých variantách Duqu. Jedná se připojit k C & C serveru v Indii, na jednom v Belgii, ale i na další C & C serverů, zejména dva servery ve Vietnamu a jeden v Nizozemsku. Kromě toho bylo mnoho dalších serverů používá jako součást infrastruktury, některé z nich jako hlavní C & C proxy, zatímco jiné byly používány útočníků na skok po celém světě a aby trasování obtížnější. Celkově odhadujeme, že byli více než tucet Duqu velení a řízení serverů aktivní během posledních tří let.
Než půjdete dál, dejme tomu, že stále nevíme, kdo je za Duqu a Stuxnet. I když jsme analyzovali některé servery, útočníci se zabývaly jejich stopy poměrně efektivně. Dne 20. října 2011 byl zahájen hlavní vyčištění provoz sítě Duqu. Útočníci otřel každý server, které použila již v roce 2009 - v Indii, Vietnam, Německa, Velké Británie a tak dále. Nicméně, i přes masivní vyčištění můžeme vrhnout trochu světla na to, jak C & C síť funguje.
Server '' - Vietnam
Server '' byl lokalizován ve Vietnamu a byl používán pro tlumení některých Duqu varianty nalezené v Íránu. To byl Linux server běží CentOS 5.5. Vlastně všechny Duqu C & C serverů Našli jsme dosud provozované CentOS - verze 5.4, 5.5 nebo 5.2. Není známo, zda je to jen náhoda, nebo v případě, že útočníci mají afinitu (exploity?) Pro CentOS 5.x.
Když jsme začali analyzovat serveru obraz, nejprve si všiml, že alespoň na 'root' složky a systém log soubory, složky '/ var / log / "má časové razítko je poslední upravený" 2011-10-20 18:07:28 v (UTC +3).
Nicméně, obě složky byly téměř prázdné. Přes úpravy datum a čas v kořenové složce, tam byly žádné soubory uvnitř upravené, i blízko k tomuto datu. To znamená, že některé operace (pravděpodobně mazání / čištění) se konala dne 20. října kolem 18:07:28 GMT +3 (22:07:28 Hanoj čas).
Je zajímavé, že na Linuxu je někdy možné obnovit smazané soubory, ale v tomto případě jsme nemohli nic najít. Bez ohledu na to, jak tvrdě jsme hledali, odvětví, kde by měly soubory byly umístěny byly prázdné a plné nul.
Tím bruteforce skenování malátný (nepoužité) prostor v oddílu na "/", jsme byli schopni obnovit některé části To sshd.log To souboru. To byl trochu nečekaný a je to výborná lekce o Linuxu a ext3 vnitřností systému souborů, smazání souboru neznamená, že tam nejsou žádné stopy nebo jejich částí, někdy z minulosti. Důvodem je to, že Linux stále přerozděluje běžně používané soubory na snížení roztříštěnosti.Proto je možné najít části starších verzí určitého souboru, i když byly důkladně odstraněny.
Jak je vidět z logu výše, uživatel root přihlášen dvakrát ze stejné IP adresy na 19. července a 20. října.Ten login je docela blízko v posledních modifikovaných časovými značkami v kořenovém adresáři, což znamená, je to osoba odpovědná za vyčištění systému - bingo!
Takže, co přesně dělá tento server? Nebyli jsme schopni odpovědět na tuto otázku, až jsme analyzovali serveru 'B' (viz níže). Nicméně, jsme najít něco opravdu zajímavého. Dne 15. openssh-5.8p1 (Sourcecode) Únor 2011 byl zkopírován do počítače a následně nainstalovat. Distribuce je "openssh_5.8p1-4ubuntu1.debian.tar.gz" s MD5 '86f5e1c23b4c4845f23b9b7b493fb53d "(stock distribuce). Můžeme předpokládat, že stroj byl spuštěn openssh-4.3p1, jak je uvedeno v původní distribuci CentOS 5.2. Dne 19. 07. 2011 OpenSSH 5.8p2 zkopíruje do systému. To bylo sestaveno a binární soubory byly nainstalovány do složky (/ usr / local / sbin). OpenSSH distribuce byl opět skladem jeden.
Datum 19. července je důležité, protože to znamená, když byl nový OpenSSH 5.8p2 sestaven v systému.Jen po tom, útočníci přihlášení, pravděpodobně zkontrolovat, zda je všechno v pořádku.
Jeden dobrý způsob, jak se dívat na serveru zkontrolovat vymazání souborů a dát je do grafu aktivit. Ve dnech, kdy tam byla pozoruhodná operace děje, vidíte Spike:
Pro náš konkrétní server, několik špičky okamžitě vzbudit podezření: 15. února a 19. července, kdy byly instalovány nové verze OpenSSH, 20 října, kdy serveru vyčištění došlo. Navíc jsme zjistili, bodce na 10. února a 3. dubna, kdy některé události došlo. Byli jsme schopni identifikovat "dovecot" nehod na těchto dat, i když nemůžeme být jisti, že byly způsobeny útočníků ("holubník" vzdálené napadení?) Nebo prostě nestability.
Samozřejmě, pro server 'a', tři velké otázky zůstávají:
- Jak se útočníci získat přístup k tomuto počítači na prvním místě?
- Co přesně byl její účel a jaké to bylo (ab-) používá?
- Proč útočníci vyměnit si OpenSSH 4.3 verzí 5.8?
Server 'B' - Německo
Tento server byl umístěn v datovém centru v Německu, který patří k bulharské hostingové společnosti.To bylo používáno útočníků se přihlásit do vietnamské C & C. Důkazy také nasvědčuje tomu, že byl použit jako Duqu C & C v dávné minulosti, i když jsme nemohli určit přesnou Duqu variantu, která učinila.
Stejně jako na serveru ve Vietnamu, i tento byl důkladně vyčištěn dne 20. října 2011. "Root" složku a "atd" složky mají časová razítka od tohoto data opět ukazuje na vymazání souborů nebo změny v tento den. Ihned po vyčištění serveru, útočníci ho restartoval a přihlášeni znovu zkontrolovat, zda všechny důkazy a stopy byly vymazány.
Opět tím, že skenování malátný (nepoužité) prostor v "/" partition, se nám podařilo obnovit části Hasičské sshd.log 'Soubor. Zde jsou uvedeny příslušné údaje:
Za prvé, o termínu - 18. listopadu. Bohužel, "sshd.log" neobsahuje rok. Takže nemůžeme vědět jistě, jestli je to 2010 nebo 2009 (víme to nebylo 2011) z této informace sám. Byli jsme však schopni najít jinou log soubor, který naznačuje, že termín byl 2009:
Jak můžete vidět výše, je fragment "logwatch" vstupu, který označuje datum porušení být 23. listopadu 2009, kdy uživatel root přihlášení z IP adresy, od 19. listopadu, v "sshd.log". Další dvě zprávy jsou také důležité - jsou to chyby z "sshd" upozorňující na port 80 a port 443 byl pokus o přesměrování, které však již byly plné ruce práce. Takže teď už víme, jak byly tyto servery jako C & C - port 80 a port 443 byl přesměrován přes sshd na serveru útočníků. " Tyto Duqu C & C se nikdy nepoužívají jako skutečný C & C - místo toho oni byli používáni jako proxy pro přesměrování provozu na skutečný C & C, jejíž umístění zůstává neznámý. Zde je to, co úplný obraz vypadá takto:
Odpovědi na otázky
Tak, jak se tyto servery si hacknutý na prvním místě? Jedno bláznivé teorie poukazuje na 0-day zranitelnost v OpenSSH 4.3 Vyhledávání "OpenSSH 4.3 0-day" na Google zjistí, některé velmi zajímavé příspěvky. Jedním z nich je ( https://www.webhostingtalk.com/showthread.php?t=873301 ):
Tento příspěvek od uživatele "Jon-F", která sahá až do roku 2009, naznačuje možný 0-den OpenSSH 4.3 na CentOS, dokonce zaslali přičichl protokoly exploitu v akci, i když je komunikace šifrovaná a není snadné analyzovat.
Mohlo by to být tento případ? Znát Duqu kluci a jejich nikdy nekončící pytel 0-day využije, to znamená, mají také Linux 0-den proti OpenSSH 4.3? Bohužel, nevíme.
Pokud se podíváme na "sshd.log" z 18. listopadu 2009, lze však získat nějaké zajímavé stopy. "Root" uživatel pokusí přihlásit pomocí hesla několikrát z IP v Singapuru, až se konečně podaří:
Všimněte si, jak "root" uživatel pokusí přihlásit v 15:21:11, nedokáže několikrát a pak 8 minut a 42 sekund později přihlášení úspěšné. To je více uvedením hesla bruteforcing spíše 0-day. Takže tou nejpravděpodobnější odpovědí je, že root heslo bylo bruteforced.
Nicméně, třetí otázka zůstává: Proč se útočníci vyměnit si OpenSSH 4.3 verzí 5.8? Na serveru v Německu jsme byli schopni obnovit části "bash_history." Soubor jen poté, co byl hacknut server:
Příslušné příkazy "yum install openssh5", pak "yum aktualizace openssh-server". Musí být dobrý důvod, proč jsou útočníci, takže obavy o aktualizaci OpenSSH 4.3 na verzi 5. Bohužel nevíme, odpověď na tuto otázku. Na zajímavou poznámku, jsme zjistili, že útočníci nejsou přesně obeznámeni s "iptables" syntaxi příkazového řádku. Kromě toho nejsou příliš jisti "sshd_config" formátu buď, takže potřebuje, aby se v návodu k ní ("muž sshd_config"), stejně jako pro standardní Linux klient ftp. A co "sshd_config" soubor, sshd konfiguraci "? Opět tím, že hledání slack prostoru se nám podařilo zjistit, co byli po. Zejména se změnilo následující dva řádky:
GSSAPIAuthentication ano
UseDNS ne
UseDNS ne
Zatímco druhý je relevantní pro rychlost, a to zejména při provádění portu směr přes tunely, první umožňuje ověřování Kerberos. Byli jsme schopni určit, že v jiných případech byly použity přesně stejné úpravy.
Závěr:
Máme v současné době analyzují pouze zlomek dostupných serverů Duqu C & C. Nicméně, jsme byli schopni určit některé skutečnosti o tom, jak infrastruktura provozována:
- V Duqu C & C servery provozovány již v listopadu 2009.
- Mnoho různých serverů byly hacknuty po celém světě, ve Vietnamu, Indii, Německu, Singapuru, Švýcarska, Velké Británie, Nizozemí, Belgii, Jižní Koreje ke jménu ale nemnoho umístění. Většina z hacknutých strojů běžely CentOS Linux. Oba 32-bit a 64-bitové stroje byly hacknuty.
- Servery Zdá se, že byly hacknuty pomocí bruteforcing heslo uživatele root. (Nevěříme v OpenSSH 4.3 0-day teorie - to by bylo příliš děsivé!)
- Útočníci mají palčivou touhu aktualizovat OpenSSH 4.3 na verzi 5, jakmile se dostanou kontrolu nad hacknutých serveru.
- Globální očista proběhla dne 20. října 2011. Útočníci otřel každý server, který byl použit i v dávné minulosti, např. 2009. Bohužel, byla nejzajímavější server, C & C proxy v Indii, čistí jen několik hodin předtím, než hosting společnost souhlasila, aby se obraz. Pokud je obraz byl vyrobený dříve, je možné, že nyní bychom vědět mnohem více o vnitřním fungování sítě.
- "Skutečné" Duqu Mateřská C & C Server zůstává záhadou, stejně jako totožnost útočníků. "
Chtěli bychom také poslat dotaz na Linux adminům a OpenSSH odborníků po celém světě - proč byste aktualizovat OpenSSH 4.3 na verzi 5.8, jakmile si hacknout počítač běžící verzi 4.3? Co dělá verzi 5.8 tak zvláštní ve srovnání s 4,3? Je to spojené s volbou "GSSAPIAuthentication ano" v konfiguračním souboru?
Doufáme, že prostřednictvím spolupráce a spolupráce můžeme obsadit více světla na toto obrovské tajemství Trojan Duqu.
Společnost Kaspersky Lab bych poděkovat firmy PA Vietnam, Nara syst a bulharské jednotky kyberkriminalitě za jejich laskavou podporu v tomto šetření. To by nebylo možné bez jejich spolupráce.
Můžete se obrátit na Kaspersky Duqu výzkumný tým na "stopduqu společnosti Kaspersky dot com".
Žádné komentáře:
Okomentovat