V několika předešlých příspěvcích jsme vás informovali o naší open source aplikaci Malicious Domain Manager (MDM), která pomáhá zjišťovat škodlivý obsah umístěný na doménách .cz. Od roku 2011, kdy jsme poprvé tento projekt představili na konferenci Internet a Technologie 11, uběhlo pět let, v průběhu kterých jsme na vývoji této bezpečnostní aplikace intenzivně pracovali.
Aplikace MDM oslavila třetí narozeniny sto tisíci „vyčištěnými“ URL
Když jsme v polovině roku 2011 uvedli do testovacího provozu naši aplikaci Malicious Domain Manager (MDM), nikoho z nás nejspíš nenapadlo, že o tři roky později bude mít tato aplikace podíl na nápravě více než 100 000 URL v doméně .CZ. Dovolte mi tedy u příležitosti „narozenin“ této aplikace ve zkratce přiblížit její úspěchy.
Zprávy ze světa: MDM pomáhá s bezpečnostními incidenty na Slovensku
O aplikaci MDM jsme na tomto blogu již několikrát psali. Tentokrát se s vámi chci podělit o informace, které mě velmi potěšily. Před několika týdny jsem mluvil o MDM s kolegy z CSIRT.SK. Při tom jsem se dozvěděl, že u nich naše aplikace zaznamenala velký úspěch.
V polovině roku 2012 si kolegové ze Slovenska dali za úkol najít nástroj, který by jim zkrátil čas při vyhodnocování a následné správě incidentů, které obdrží od zahraničních partnerů. Trh s těmito nástroji je opravdu veliký a každému vyhovuje jiný model na správu incidentů. Mezi testovanými aplikacemi bylo i naše MDM, které kolegy zaujalo doslova na první pohled; sympatie si získalo i díky tomu, že je open source.
Slovenský bezpečnostní tým se rozhodl používat aplikaci MDM nejen pro zpracování informací o hrozbách v doméně .sk, ale také jako základní nástroj pro zpracovávání všech incidentů přijatých tímto národním CSIRT týmem. Proto změnili původní zpracování a zobrazení incidentů v samotné aplikaci a rozšířili také možnost administrovat jak incidenty s URL, tak i bez URL, například na základě IP adresy.
První testovací verze MDM byla na Slovensku nasazena od 24. září loňského roku do konce prosince. V tomto období zkoumali v CSIRT.SK funkčnost a přijímali připomínky a návrhy na zlepšení tohoto softwaru. Od 1. ledna mají naši aplikaci již pevně pod kontrolou. Aktuálně se jedná o verzi 2.0. a počet incidentů, které touto aplikací spravují, převýšil 27 tisíc.
Rádi bychom tedy našim slovenským „bratrům“ (jmenovitě kolegovi Martinu Jurčíkovi) poděkovali nejen za poskytnuté informace k tomuto článku, ale také za spolupráci. A samozřejmě také přejeme jen samá pozitiva a sociální jistoty :-) při používání naší aplikace.
Michal Prokop
Knot DNS – správa zóny
V předchozím díle jsme si vytvořili jednoduchou zónu ve formě zónového souboru a dnes si povíme, jak s takovým souborem pracovat. Jedná se o nejčastější uživatelskou operaci a je užitečné jí porozumět.
Co nám ukázal sken 10 000 domén?
V rámci našeho působení provozujeme aplikaci Malicious Domain Manager. S její pomocí se snažíme informovat držitele domén v zóně .CZ o úspěšné kompromitaci jimi provozované webové prezentace. Nejčastějším scénářem, který se v rámci napadení webových aplikací pravidelně opakuje, je situace, kdy si útočníci pronajmou web či IP adresu a provozují na ní nějaký exploit kit, který útočí na známé zranitelnosti komponent, jež uživatelé obvykle využívají při procházení webových stránek (tedy prohlížečů, Javy, Flash playeru apod.). Tuto adresu, kde je exploit kit provozován, pak například pomocí tagu iframe vkládají do napadených webových stránek jako jejich součást. Již delší dobu si klademe otázku, zda nemůže ve skutečnosti v zóně .CZ být více napadených domén, než o kterých jsme schopni se dozvědět s pomocí naší aplikace. Zkusili jsme proto reverzní postup: Vzali jsme množinu náhodných domén a sledovali, z jakých dalších domén si tyto stránky stahují své komponenty. Potom jsme v kupce agregovaných výsledků pátrali po jehlách a červech… Co myslíte, povedlo se nám v malém českém rybníce identifikovat nakažené stránky, na které ještě nepřišel Google Safebrowsing? A případně kolik?
Testování verzí CMS aneb Co se povedlo a na co si dát příště pozor
Testování verzí CMS (Content Management System), ke kterému jsme přistoupili začátkem léta, vzbudilo poměrně značný ohlas v odborné komunitě. Zaznamenali jsme jak hlasy, které naši iniciativu vítaly, tak také ty, kterým z nějakého důvodu vadila. V tomto blogpostu bych chtěl na některé výtky reagovat bližším vysvětlením naší motivace i kroků v pozadí. Byla to naše první zkušenost s podobnou plošnou akcí a je třeba přiznat, že jsme se také dopustili některých přehmatů. I o těch se chci zmínit a omluvit se komunitě za případné negativní dopady, které to mohlo způsobit. Z ohlasů také víme, že některé z vás by zajímalo, jaké byly výsledky této akce. I na ty se tedy podíváme a zkusím také nastínit další věc, která by měla navazovat. Pojďme ale pěkně popořádku.
Nejvýznamnější útoky řešené bezpečnostními týmy v Podunají
Dne 15. března 2016 proběhla závěrečná konference projektu „Kybernetická bezpečnost v podunajském regionu“ (CS Danube). Hlavním cílem projektu, na kterém se vedle našeho CSIRT.CZ podíleli zástupci bezpečnostních týmů a organizací z Chorvatska, Rakouska, Slovenska, Srbska a Moldavska bylo především posílení kapacit jednotlivých týmů a spolupráce v oblasti kybernetické bezpečnosti.
Zajímavý případ od kolegů z polského CERTu
Polský bezpečnostní tým CERT Polska uveřejnil 31. července na svých stránkách http://www.cert.pl zprávu, ve které jeho členové popisují, proč NASK (správce registru národní domény .pl) ukončil spolupráci s jedním z registrátorů domén .pl, společností Domain Silver, Inc.
Tento registrátor, jehož oficiálním sídlem byly Seychelské ostrovy, zahájil svou činnost v květnu roku 2012. Od té doby začal CERT Polska pozorovat velký nárůst škodlivých domén .pl. Většina těchto domén byla zaregistrována právě u tohoto registrátora.
Ze všech registrovaných domén (641, stav k 9. červenci tohoto roku) byla pouze jedna doména neškodná. Tou byla přímo doména tohoto registrátora – domainsilver.pl.
Z celkového počtu 404 domén, které obsahovaly škodlivý kód, bylo 179 domén pod správou C&C serverů. Domény, které byly pod správou některého z botnetů, také tyto botnety nebo škodlivý kód distribuovaly. Jednalo se například o malware nebo botnet Citadel, Dorkbot, ZeuS Ice IX, Andromeda, RunForestRun nebo ransomware. Bližší informace jsou k dispozici na stránkách polského CERT týmu.
V doméně .CZ jsme sice zatím nenarazili na případ, kdy by se na podobné záležitosti přímo specializoval registrátor (a doufejme, že i díky podmínkám pro přijímání registrátorů ani nenarazíme), ale i u nás se sem tam objeví podobné případy nakažených domén, resp. stránek. Není jich ale zdaleka tolik jako jinde. Možná je za tím náš nástroj MDM (Malicious Domain Manager), který používáme pro čištění zóny .CZ. Od spuštění pilotní verze této aplikace uběhly více než dva roky a počet opravených nebo chcete-li vyčištěných domén za tu dobu překročil počet 5000.
Michal Prokop
Přístup k systému Request Tracker z Pythonu
Závěrem loňského roku Laboratoře CZ.NIC vydaly první verzi modulu python-rt. Ten umožňuje přistupovat z Pythonu k API systému pro správu požadavků Request Tracker. Původně byl tento modul vyvinut v rámci projektu MDM, nakonec je ovšem použitelný i samostatně. Podrobnosti o modulu naleznete na stránce projektu a v jeho dokumentaci.
Co vlastně je Request Tracker a kde se podobné systémy uplatní? Jedná se o webové aplikace, které přehledně evidují požadavky (typicky nahlášené e-mailem) a umožňují skupině lidí spolupracovat na jejich řešení. Běžně takové tyto systémy používají například oddělení zákaznické podpory. Veřejně dostupné demo systému Request Tracker si můžete vyzkoušet zde. A právě na něm si ukážeme, jak se modul používá.
- Na testování si vytvoříme nové virtuální prostředí v adresáři env-rt, přesuneme se do něj a aktivujeme jej:
$ virtualenv env-rt $ cd env-rt $ source bin/activate
- Nainstalujeme modul rt:
(env-rt)$ pip install rt
- Spustíme Python v interaktivním režimu:
(env-rt)$ python
- Importujeme modul rt a vytvoříme instanci jeho třídy rt (tři parametry: adresa REST API systému Request Tracker., uživatelské jméno, heslo):
>>> import rt >>> tracker = rt.Rt('http://rt.easter-eggs.org/demos/stable/REST/1.0', ... 'mike.bar', 'mike.bar') - Přihlásíme se do systému a vyhledáme všechny vlastníky požadavků ve frontě Helpdesk:
>>> tracker.login() True >>> set(map(lambda x: x['Owner'], tracker.search(Queue="Helpdesk"))) set([u'admin', u'john.foo', u'Nobody', u'mike.bar'])
- Dále například můžeme vytvořit nový požadavek:
>>> tracker.create_ticket(Queue='Helpdesk', ... Subject='Coffee (important)', Text='Help I ran out of coffee!') 113
- Vrácené číslo je ID požadavku, které můžeme využít pokud chceme například požadavek editovat:
>>> tracker.edit_ticket(113, Requestors='addicted@example.com') True
- Důležitá je také možnost na požadavky reagovat:
>>> tracker.reply(113, text='Do you know Starbucks?') True
- Na konci se odhlásíme:
>>> tracker.logout() True
Pokud se rozhodnete modul používat, budeme rádi za vaši zpětnou vazbu.
Jiří Machálek
Útoky pomocí iframe, jejich maskování útočníky a obrana
Při práci s naší aplikací MDM musíme občas řešit žádosti o pomoc týkající se nalezeného vadného kódu na webových stránkách. Je to celkem pochopitelné, stránky jsou často v provozu roky, nikdo na ně za tu dobu nesáhl a nebo si je držitel nechával od někoho dělat a dnes už třeba na tvůrce webu nemá ani kontakt. Zkrátka důvodů, proč se na nás oběti útoků obrací, existuje celá řada. Proto jsem se rozhodl napsat tento článek, abych mohl názorně demonstrovat, s jakými problémy se nejčastěji setkáváme, jak lze zamaskovaný javascript v kódu stránky nalézt a jak dále postupovat po jeho odhalení.
Jako první krok je vhodné zkusit tento on-line nástroj, který vám může ušetřit hodně času. Obsahuje databázi skriptů a technik používaných útočníky a pokud je na vašich stránkách rozpozná, ukáže vám také zdrojový kód, který je původcem problému. Další podobný nástroj, který Vám může hodně pomoci, je urlquery.net. Ten totiž provede analýzu stránky automaticky a ukáže Vám například, odkud se které části stránky stahovaly. Pokud pak ve výpise uvidíte neznámou doménu, tak máte jasno, odkud se malware vzal. Pokud ani toto nepomůže, je potřeba hledat jiným způsobem, tedy podívat se do zdrojového kódu webových stránek.
Nejčastěji se při útocích setkáváme s použitím tagu iframe. Ten se používá pro vnoření webové stránky do jiné. Konkrétní vložení kódu se pak provádí tagem <iframe>. Snahou útočníků je samozřejmě dosáhnout toho, aby vložený prvek nebyl na napadeném webu snadno viditelný, proto použijí atributy, kterými se vložený frame zmenší na nejmenší možnou velikost a zároveň mu nastaví jeho neviditelnost. Samotné nastavení neviditelnosti by nestačilo, protože vložený prvek by na cílové stránce okupoval určitý prostor, což by bylo nápadné. Proto útočník obvykle použije nějakou takovouto konstrukci:
Pokud tedy na podobný kód směřující na vám neznámou doménu při zkoumaní html kódu narazíte, bude to pravděpodobně to co hledáte. Takovýto zřejmý odkaz by však dokázal i trochu zkušenější uživatel v kódu html najít, obzvlášť, pokud přihlédneme k tomu, že je tento odkaz obvykle směřován na pro nás přece jen trochu exotičtější domény typu .cn. Proto útočníci přistupují i k dalším metodám zmatení kódu. Bohužel takto zamaskovanou změnu již není možné snadno odhalit. Proto se také obvykle setkáváme s částmi kódu, které vypadají asi takto:
Zde již není možné na první pohled jednoznačně určit, zda byl kód vložen dodatečně útočníkem, či zda tam tento kus kódu vložil původní tvůrce stránek. Ve spodní části je v závorce velká řada čísel a písmen. Podle použitých čísel a písmen můžeme usuzovat na použití hex kódu k zamaskování skutečné URL. Jedná se o obvyklou taktiku používanou útočníky. Nyní tedy použijeme on-line dekódovací nástroj, upozorňuji, že je potřeba vzít pouze tuto část skriptu:
Po dekódování získáme takovýto výsledek:
Opět i bez hlubší znalosti JavaScriptového kódu vidíme, že script vkládá do webové stránky iframe odkazující na gstats.cn. Upozorňuji, že se jedná o skutečný kód použitý na jednom z napadených webů. Proto nedoporučuji zkoumat obsah webu http://gstats.cn. Toto platí i pro všechny další ukázky.
Další metodou, jak odhalit pravou funkci podezřelého skriptu, je jeho spuštění. Toto však doporučuji pouze zkušeným uživatelům a pouze v k tomu účelu vytvořeném virtuálním PC nebo v některém sandboxu. K samotnému provedení této akce lze použít například nainstalovaný Firefox a v něm plugin firebug. Řekněme, že máme takovýto skript:
Pro jeho zpřehlednění můžeme použít on-line nástroj jsbeautifier(). Zkopírujeme vše mezi tagy script a na stránce jsbeatifier.org si jej necháme upravit tak, aby pro nás byl více přehledný. Získáme takovýto výstup:
Nyní změníme ve skriptu příkaz document.write(str); na alert(str);. Tím zajistíme, že se výsledek scriptu nepřidá jako součást stránky, ale vypíše se v jednoduchém dialogovém okně jako text. Nyní spustíme firebug, zvolíme konzole a vložíme předupravený skript. Zvolíme spustit a vyskočí na nás okno, kde vidíme kód, který se jinak vkládá do webové stránky. Jak můžete vidět na obrázku, je to náš starý dobrý známý, tag iframe.
A nyní malá soutěž. Na následující kód jsme narazili nedávno. Je na něm zajímavé například to, že obsahuje záměrně zbytečné části, které mají ztížit orientaci v jeho kódu. Kdo první napíše v diskuzi doménu, na kterou se skriptem vkládaný iframe odkazuje, ten od nás obdrží poštou tričko. Malá rada na závěr, zkuste to pomocí funkce console.log a pozor, opět se jedná o ukázku skutečného kódu, je tedy potřeba se skriptem zacházet opatrně. Prohlédnout si jej můžete zde (původní txt soubor byl nahrazen png obrázkem). Kromě správné odpovědi nezapomeňte připojit také Vaši e-mailovou adresu, ať Vás můžeme ohledně výhry kontaktovat.
Na závěr bych rád uvedl ještě pár rad, kterými je dobré se řídit, pokud již takovouto havěť na svém webu najdete. Jak jste mohli vidět, útočníci jsou opravdu velmi vynalézaví a je proto poměrně obtížné se s těmito způsoby útoku vypořádat. Pokud však odhalíte takovýto kód ve vaší webové aplikaci, doporučujeme následující postup:
1. Odpojte webové stránky, případně změňte úvodní stránku, aby zobrazovala pouze informace o údržbě. Předejdete tak dalšímu napadení uživatelů vašeho webu.
2.Než začnete odstraňovat kód, o němž si myslíte, že do vašich stránek nepatří, udělejte si zálohu, pokud ji nemáte.
3. Pokud máte čistou zálohu stránek, použijte ji. Pokud ne, musíte najít a odstranit škodlivý kód ručně.
4. Zkontrolujte, že na žádném z počítačů, ze kterých web upravujete pomocí FTP, nemáte viry, či jiný malware. Dle našich zkušeností je toto častá cesta, kterou se útočníci k heslům dostanou. Pak pro ně samozřejmě není těžké do stránek přidat svůj vlastní kód.
5.Změňte všechna hesla, která mají nějaký vztah k napadenému webu. Hesla k FTP, SSH, heslo admina aplikace (WordPress, Joomla) atd.
6. Například pomocí již zmiňovaného on-line nástroje zkuste otestovat, zda je Váš web již skutečně v pořádku. Posledním krokem je pak nalezení způsobu, kterým byl kód do stránky vložen. Nejčastějšími příčinami jsou již zmiňovaná krádež hesel pomocí viru na počítači správce webu, dále se může jednat o zastaralou verzi CMS, například WordPress, Joomla a další. Může se jednat také o zranitelnost samotného serveru, na kterém webové stránky běží.
Rozhodně radíme tento problém nepodceňovat, protože na vložené stránce se mohou vyskytovat skripty, které mohou uživateli stáhnout do počítače nebezpečné soubory, či například hledat zranitelnosti používaného prohlížeče.
Pavel Bašta