Aplikaci MDM rozšířila nová služba

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.

Celý článek

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

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á.

  1. 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
  2. Nainstalujeme modul rt:
    (env-rt)$ pip install rt
  3. Spustíme Python v interaktivním režimu:
    (env-rt)$ python
  4. 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')
  5. 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'])
  6. 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
  7. 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
  8. Důležitá je také možnost na požadavky reagovat:
    >>> tracker.reply(113, text='Do you know Starbucks?')
    True
  9. 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

CSIRT.CZ předával zkušenosti CERT-RO (Národnímu CSIRT týmu Rumunska)

Jak jsme již informovali v této novince, v pátek 1.června se v sídle sdružení CZ.NIC uskutečnilo setkání v jehož rámci došlo k předání zkušenosti s provozováním národního CSIRT týmu zástupcům týmu CERT-RO (ten je stejně jako my akreditován u úřadu Trusted Introducer). Organizátorem akce byla Evropská agentura pro síťovou a informační bezpečnost (ENISA), jejímž primárním cílem je dosažení vysokého stupně informační a síťové bezpečnosti mezi členskými státy EU.

Na začátku setkání zazněly informace o historii budování CSIRT.CZ a jeho cestě do pozice Národního CSIRT České republiky, o organizační struktuře týmu, ale také sdružení CZ.NIC samotného, o práci Laboratoří CZ.NIC, které se ve svých projektech bezpečností také intenzivně zabývají, Akademii CZ.NIC a jejích vzdělávacích projektech atd. Kolegové z CERT-RO také ocenili informace o pracovní skupině CSIRT.CZ,  jejímiž členy jsou zástupci významných provozovatelů sítí, poskytovatelů obsahu, rizikových služeb, bezpečnostních složek České republiky, Českého telekomunikačního úřadu, sdružení CZ.NIC i NIX.CZ a akademického sektoru. Tato pracovní skupina umožňuje setkávání bezpečnostních expertů z uvedených organizací a také vzájemné předávání informací a zkušeností souvisejících s počítačovou bezpečností.

Během setkání jsme zástupce týmu CERT-RO informovali také o nástrojích, které používáme při řešení incidentů, ať už ticketovacího systému OTRS, různých linuxových utilit, rozšíření pro Firefox, či různých nástrojů dostupných on-line. Nejvíce však členy národního CSIRT týmu Rumunska zaujala aplikace, kterou vyvinuly naše laboratoře  a jako open source nabídli k používání i dalším registrům. Je to aplikace MDM, o níž jsme již psali zde  a jejíž nasazení pomohlo také k lepšímu postavení České republiky v různých statistikách phishingových stránek.

Kolegy z CERT-RO také zaujala prezentace životního cyklu incidentu od jeho vzniku až po jeho vyřešení. Během této přednášky jsme poreferovali o některých zajímavých, či zásadních incidentech, které jsme za poslední rok řešili. Hojně diskutovanou se stala také otázka proaktivního přístupu a úzké spolupráce na úrovni národních CSIRT týmů.

Setkání se zúčastnil také zástupce týmu CESNET-CERTS, který provozuje sdružení CESNET pro dohled nad sítí národního výzkumu a vzdělávání. Oba české bezpečnostní týmy spojuje dlouhodobá a velice úzká spolupráce na poli internetové bezpečnosti v této zemi. Zástupce CESNET-CERTS na tomto setkání prezentoval systém pro efektivní sdílení informací o bezpečnostních událostech. Jeho nasazení je ve spolupráci s CSIRT.CZ plánováno i na národní úrovni.

Dlužno říci, že i náš tým získal zajímavé nové informace. V Rumunsku je existence Národního týmu  zakotvena v zákoně a na jeho provozu se podílejí například i kmenoví zaměstnanci bezpečnostních sil. Rumunský národní CERT tým se také momentálně ve spolupráci s vládním sektorem pokouší o spuštění vlastního rozsáhlého IDS systému. Také je zajímavé, že registr rumunské národní domény .RO nezobrazuje a ani nepředává žádné údaje o držitelích domén, pokud jsou tito fyzickými osobami. Z pohledu práce CSIRT týmů je toto jasná nevýhoda při řešení incidentů. A zajímavost na závěr – pokud by někdo z vás toužil pracovat v Národním CSIRT týmu Rumunska, pak vězte, že minimálním požadavkem pro práci v tomto týmu je úspěšné složení certifikace Certified Ethical Hacker (CEH).

Pavel Bašta

Jak si vede Česká republika v boji proti phishingu?

Minulý měsíc se objevila zpráva pracovní skupiny APWG (Anti-Phishing Working Group), která se zaobírá problematikou phishingu snad ze všech možných úhlů, tedy i monitorováním phishingových stránek. Její zpráva obsahuje mimo jiné také různé zajímavé statistiky za druhé pololetí uplynulého rok vztahující se k jednotlivým národním a generickým doménám. Porovnáme-li tyto zprávy za poslední tři pololetí, tedy 2/2010, 1/2011 a 2/2011, zjistíme, že podle těchto statistik počet phishingových útoků na stránkách v doméně .cz postupně klesá, z 222 případů v 2/2010 až k 171 případům v druhém pololetí roku 2011. Průměrný uptime (tedy průměrná doba, po kterou jsou phishingové stránky dostupné) byl v druhém pololetí roku 2010 64 hodin a 33 minut. Toto číslo pak v dalším půlroce kleslo a v druhém pololetí uplynulého roku jsme se dostali na 41 hodin a 10 minut. Stále se ale bohužel jedná o poměrně vysoké číslo, neboť phishingové útoky mají obvykle nejvyšší výtěžnost do 24 hodin od jejich spuštění. Doufejme tedy, že se i díky naší práci podaří průměrný uptime snížit tak, aby se provozování phishingu v doméně .cz pokud možno ekonomicky nevyplácelo. Na druhou stranu je potřeba říci, že medián uptimu byl za loňský rok pouhých 14 hodin a 46 minut, což je velmi pěkné číslo. I další ukazatele, jako například Score (počet domén zneužitých k phishingu na 10 tisíc registrovaných domén) nevychází pro naši doménu nijak špatně: pro doménu .cz je to 1.2. I když to není vůbec špatné číslo, stále je co zlepšovat, a tak doufám, že příští rok již bude toto číslo pro doménu .cz menší než 1. Určitě to není nemožné, neboť například doména .se má scóre rovnající se právě tomuto číslu.

Zajímalo mě také, jak jsou na tom z hlediska phishingu IP adresy delegované do České republiky. I pro toto lze nalézt zajímavé statistiky, pro změnu na stránkách databáze Phistank, která sbírá data o phishingových stránkách a je mimo jiné využívána prohlížeči při posuzování obsahu stránek. Snažíme se aktivně pomocí naší aplikace MDM (viz článek na našem blogu) oslovovat držitele domén .cz, jimiž držené domény se nejen v této databázi objevily. I proto jsem byl velmi zvědavý, zda se to v jejich statistikách nějak projevilo. Tuto aplikaci jsme spustili v pilotním provozu v červnu 2011, proto jsem v následujícím grafu zaznamenal data od tohoto měsíce. Jedná se o percentuální podíl IP adres v dané zemi na celkovém množství phishingových stránek v daném měsíci.

Bohužel jsou však v těchto statistikách zobrazovány pouze státy, ve kterých je množství phishingových stránek větší než dvě procenta. A teď to přijde (tramtadadá :)) – poslední dostupné statistiky za měsíc leden 2012 již nezobrazují pro ČR žádné údaje. Podíl množství phishingových stránek provozovaných v naší zemi na celkovém objemu phishingu tedy klesl pod 2 procenta.

Z obou výše rozebraných statistik vyplývá, že se v České republice dlouhodobě daří bojovat proti nelegálním internetovým aktivitám, k čemuž jak pevně věříme přispívají i aktivity našeho týmu CSIRT.CZ.

Pavel Bašta