V současné době existuje velký počet botnetů[1], které se liší velikostí, kvalitou, účelem nebo stářím. Dnes a denně se pak na různých portálech dozvídáme, že ten či onen botnet vykazuje nadprůměrnou aktivitu nebo že se zrušením ISP povedlo eliminovat Command&Control několika velkých botnetů, čímž se celosvětově snížil objem spamu o x procent.

Když jsem před pár dny zase narazil na jeden takový článek, přečetl si ho, přemýšlel o něm a zároveň pročítal databázi chyb ve webových aplikacích, napadl mě koncept botnetu, který by byl postaven na kombinaci JS/PHP/SQL. Možná teď někdo přemýšlí: „Proč, proboha, zrovna tato kombinace? Vždyť takový kód nebude mít nejmenší šanci na úspěch.“ S postupujícím časem, kdy budu pomalu objasňovat celý koncept poznáte, že to není zase až tak špatná a nereálná věc. Asi většina programátorů si neuvědomuje obrovskou sílu, kterou v sobě ukrývají skriptovací jazyky. A tuto skutečnost se pokusím, alespoň teoreticky, ukázat.

Jako úplně první věc, která bude potřeba, je PHP infektor. Jeden ukázkový už jsem zde publikoval[2]. Nejedná se o nic jiného, než kopírování těla PHP infektoru do stránky oběti. Zde se musíme zastavit a uvědomit si několik věcí:
1. Má se jedna o prepender, appender nebo jiné?
2. Jakou zvolit infekční značku?
3. Jak celý kód úspěšně schovat?
Jak vidno, některé body spolu souvisí.

Pokud to vezmu po řadě:
ad 1. Když se bude jednat o appender (kód infektoru se přidává na konec skriptu), jeho odfiltrování bude každý administrátor řešit jednoduše: Přidá volání funkce exit() před tělo infektoru, čímž se vyhne jeho vykonání. Zvolíme-li prepender (kód se přidá na začátek skriptu), bude na první pohled jasně viditelný v celém kódu skriptu. Jestliže bychom se rozhodli ukrýt kód někam do středu kódu, zvyšuje se pravděpodobnost, že infektor umístíme do části, která bude vykonávána jen za určitých podmínek. Osobně se asi přikláním k použití jednoduché EPO[3] techniky: Kód infektoru umístit na konec skriptu a obalit ho definicí funkce s náhodným jménem. V samotném cílovém skriptu bych si pak vložil volání funkce (té, kterou je obalen kód infektoru) před prvním voláním funkcí jako jsou while, for, if, goto, die, exit, return, switch, break, continue. Tyto funkce totiž ovlivňují proud vykonávání skriptu, takže se může stát, že by kód infektoru nebyl nikdy vykonán, vložíme-li kód například do špatné větve podmínky.

ad 2. Pokud zvolíme některou ze statických značek, samotná jejich detekce bude hračka. Bude lepší zvolit nějakou generickou. Můžeme zvolit komentář v němž bude, ve formě řetězce, například MD5 hash domény, jež právě infikujeme infikována.

ad 3. Metod existuje opět velké množství. Základem je náhodně generovat názvy proměnných, aby byly v každé generaci infektoru odlišné a hlavně: Nastavit datum poslední změny na původní hodnotu. Infekce se tak nedá detekovat pouhým porovnáním časů poslední změny. Asi nejčastěji používaný způsob využívá zakódování celého infektoru do BASE64[4] (není nejvhodnější), využití kompresních funkcí, vyxorování celého infektoru náhodndnou hodnotou a podobně. Přidání generátoru komentářů (hlavně víceřádkových, ty mohou být použity kdekoliv), stejně jako Trash Generatoru[5] zvyšuje celkovou kvalitu kódu. Trash Generator produkuje funkční kód (jenž v kódu dříve nebyl), ale nemění výslednou funkčnost kódu. Za vhodné bych považoval zvolit i strategii infekce, aby nedocházelo ke kumulativnímu volání stejného kódu, například vlivem inkludování skriptů do sebe. Pokud zvolíme nejjednodušší formu v podobě infikce pouze index souborů, těmto problémům se vyhneme. Složitější kód již může kontrolovat, které soubory se inkludují a ty z procesu infekce úplně odstranit.

Splní-li kód výše popsané body, lze ho považovat za polymorfní EPO infektor, který již bude náročnější detekovat pomocí řetězců a wildcards. Nyní tedy máme kód, jenž by se měl v každé generaci tvářit úplně jinak, ale měl by se chovat téměř totožně a je schopný infikovat soubory jednoho webového účtu (v případě nastavených direktiv jako jsou safe_mode[6] nebo open_basedir[7]) nebo všech účtů na serveru. Jestliže nebudeme uvažovat ideální případ, kdy budou deaktivovány obě dříve zmíněné direktivy (safe_mode a open_basedir), „dovybavíme“ infektor sadou exploitů/bypassů.

Nyní, když disponujeme několika boty, jež budeme chtít hromadně ovládat, je na čase navrhnout komunikaci s Command&Control centrem (samotný návrh C&C nechám na svobodné úvaze každého čtenáře 🙂 ). Pokud bude infektor spuštěn při každém načtení infikované stránky, hrozí nebezpečí zahlcení C&C. Nejsnáze tomu předejdeme například tak, že hned po infekci souboru vytvoříme soubor s nějakým nenápadným jménem (.htacess, .htpaswd), do kterého uložíme timestamp nejbližšího příštího dotazu na C&C. Ve chvíli, kdy se tento okamžik naskytne, přejmenuje první přistupvší instance infektoru tento soubor (.htacesss, .htpaswdd), čímž bude pro ostatní instance nedostupný (pro ně nebude existovat soubor s názvem .htacess nebo .htpaswd). Stáhne všechny potřebné příkazy z C&C, vypočítá nový timestamp příštího nejbližšího dotazu a přejmenuje soubor zpět tak, aby byl opět viditelný pro všechny případné instance. Jako druhou použitelnou možnost bych použil nastavení času vytvoření indexu na čas příštího vyzvednutí příkazů z C&C. Tím ale poruším třetí bod ze začátku kapitoly.

Nyní jsme tedy schopní ovládat několik botů z jediného místa. To je sice skvělé, ale co když se stane, že bude toto místo odhaleno a smazáno a my příjdeme o všechny boty. Zde se nabízí možnost měnit dynamicky v pravidelných časových intervalech adresu C&C. Naskýtá se například možnost využít datumu: Pokud bude počet dnů v roce dělitelný deseti beze zbytku, vytvoří se na jednom (nebo více) z X hostingů nová doména ve tvaru MD5 hashe stringu „dd.mm.yy“. Tak může každý bot, i v případě delší odmlky, pohodlně najít aktuální umístění C&C. Problémem nastává, když má server špatně nastavený systémový čas (dalo by se vyřešit v kombinaci s JS) nebo update výpočtu adresy nového C&C (např. z „dd.mm.yy“ na „yy.dd.mm“). Samotný dotaz na C&C pomocí socketů nemusí vždy projít, například kvůli nastavení/filtraci portů pomocí iptables. S využitím neviditelného/překrytého iframu a javaskriptu nám příkazy obstará návštěvník infikovaného webu.

Klíčové pro všechny takové boty je jejich šíření internetem. Zde se dostává na scénu výše zmiňovaný bugtrack (například exploit-db[8]). Když se do něj pořádně podíváme, uvidíme poměrně velké množství chyb typu remote code execution, local file inclusion nebo remote file inclusion. Přesně tyto chyby lze úspěšně využít k šíření. Stačí pouze vytvořit search engine, který bude náhodně využívat dorks z vlastní databáze a snažit se vyhledávat potenciální cíle přes google, yahoo, bing a další vyhledávače a tyto cíle následně exploitovat přes použité chyby. Někdo může namítnout, že příliš mnoho dotazů z jedné domény na vyhledávače boti nedokážou zaslat. Pokud ale využijeme kombinaci neviditelného iframu s dotazem na vyhledávač a javaskript, může nám pomoci každý návštěvník infikovaného webu, aniž bychom ztroskotali na počtu dotazů (teď neberu v úvahu filtraci na potenciálně nebezpečné dotazy, kdy je uživatel donucen vyplnit CAPTCHA, ale i to by se dalo s velkým klidem vyřešit).

Nyní bych očekával dotaz: „Nebude samotný infektor příliš veliký?“ a odpovídám: „Může a nemusí“. Vezmu-li za příklad notoricky známý php shell C99/C100, říkám s klidným svědomím: „300kB není moc, pokud to není problém pro C99/C100“. Když bude autor navíc chytrý, navrhne celý kód modulárně tak, aby se v okamžiku samotného útoku na nový cíl využily jen nezbytně nutné části a zbytek si stáhne později.

Zběhleší programátoři mi jistě za pravdu, že podobný koncept bude efektivně fungovat i přes některé možné problémy. Vezmu-li navíc v potaz mizernou úroveň zabezpečení hostingů a defaultní nastavení webových serverů na uživatelských stanicích, dostávám vysoce třaskavou kombinaci, jenž může postihnout dosti velkou část internetu. Odpověď, zda se jedná jen o výplod bujné představivosti nebo „reálné hrozby“ nechám na posouzení každého čtenáře.

Odkazy:

[1] – http://cs.wikipedia.org/wiki/Botnet
[2] – http://bflow.security-portal.cz/greedy-bee-jednoduchy-infektor-php-souboru/
[3] – http://vxheavens.com/lib/vrg05.html
[4] – http://cs.wikipedia.org/wiki/Base64
[5] – http://vx.netlux.org/vx.php?id=es30
[6] – http://navody.c4.cz/safe_mode
[7] – http://help.godaddy.com/article/1616
[8] – http://www.exploit-db.com/