Nedávno jsme zjišťovali, jak často jsou navštěvované naše stránky CSIRT.CZ, konkrétně záložka Aktuálně z bezpečnosti. Při tom jsme celkem náhodou přišli na zajímavou věc, která je spojená s doplňkem pro prohlížeč Mozilla Firefox, konkrétně s toolbarem od společnosti Alexa.
Tato společnost je předním poskytovatelem svobodných, globálních webových metrik. Jejich toolbar vám umožní vyhledávat na internetu informace třeba podle klíčového slova, kategorie nebo země. Dále můžete využít i její další nástroje, například pro optimalizaci přítomnosti firemních stránek na webu, analýzu růstu přístupů na web, statistiku nejčastěji hledaných slov na webu vaší společnosti a mnoho dalších.
Tento toolbar používají také někteří naši kolegové, především pro zjišťování návštěvnosti webových stránek. Ukázalo se však, že i takovýto zdánlivě neškodný nástroj může skrývat bezpečnostní riziko. Alexa toolbar totiž funguje tak, že se při přístupu na URL zeptá uvedený toolbar na návštěvnost dané domény na serveru alexa.com. Toolbar Vám pak zobrazí návštěvnost právě navštívené domény a naopak server alexa.com si udělá u domény další čárku za návštěvu. A nyní se dostáváme k jádru problému. Pokud zkusíte na webu alexa.com vyhledat libovolnou doménu, najdete tam také část „Where Visitors Go on“, kde můžete vidět návštěvnost jednotlivých subdomén této domény. Problém nastává, pokud máte subdoménu, například interní.vasedomena.cz, jejíž existenci chcete spíš utajit, aby se například útočníci nesnažili na tuto adresu dostat. Pokud ale uživatelé ve vaší síti používají tento toolbar a zároveň z prohlížeče přistupují na takovouto interní subdoménu, máte na problém zaděláno. Ano, hádáte správně, subdoména se objeví v části „Where Visitors Go on“ u údajů o návštěvnosti vašeho webu.
Pokud jste právě našli vaši úzkostlivě střeženou subdoménu v seznamu subdomén u vaší domény, máte v podstatě dvě možnosti. Používání tohoto doplňku ve společnosti zakázat, nebo se obrátit na technickou podporu služby Alexa.
Nutno říci, že podpora funguje dobře a že je pravděpodobně na tyto situace proškolená. Když totiž založíte nový ticket nebo položíte dotaz, přijde vám potvrzení o přijetí vašeho požadavku. Za pár hodin dostanete další e-mail, kde naleznete také jméno osoby, která vaší situaci řeší.
Podle naší zkušenosti bylo do dvou dnů vše napraveno. Pokud by to šlo, dal bych jim palec nahoru ;-). Podotýkám ale, že společnost nebo žádající osoba musí mít u Alexy založený svůj vlastní účet.
Doporučujeme tedy všem bezpečákům, aby zkontrolovali, zda se na těchto internetových stránkách, nevyskytují také nějaké interní URL vaší společnosti a aby se případně zařídili podle svého nejlepšího vědomí a svědomí ;-).
Michal Prokop
Z IETF 84: SNMP data pod křídla NETCONFu?
Můj druhý postřeh z meetingu IETF 84 se také týká protokolů a nástrojů pro síťový management. Zatímco minulý příspěvek byl věnován konfiguračním datům, dnes bych se rád zmínil o jedné diskusi týkající se stavových dat, která jsou pro efektivní správu síťových zařízení také velmi důležitá. Čím se liší od těch konfiguračních? Rozdíl můžeme ukázat na jednoduchém příkladu IP adresy. Ta může být pro dané rozhraní buď statická, a pak je zapsána někde v konfiguračních datech, anebo se získává pomocí DHCP a její aktuální hodnotu může správce zjistit ze stavových dat. Za stavová data se obvykle považují i různé statistické čítače, kupříkladu počty bajtů přijatých a odeslaných přes dané rozhraní.
Pro práci s oběma typy dat jsou k dispozici dva konkurenční protokoly: SNMP a jeho mladší bratranec NETCONF. Pokud jde o konfigurační data, hovoří vše celkem jasně pro NETCONF, SNMP se v této oblasti neosvědčil a dnes se prakticky nepoužívá. U stavových dat je ale situace do velké míry opačná a SNMP tu zatím jednoznačně vládne. Síťovým operátorům už se ovšem dosti zajídá spravovat sítě pomocí dvou různých protokolů – a začínají se hlasitě ozývat.
Diskuse na toto téma propukla na IETF 84 poněkud nečekaně během jednání pracovní skupiny OPSAWG, když byl na programu Internet draft draft-schoenw-opsawg-vm-mib-01, který definuje část databáze SNMP MIB se stavovými daty pro virtuální počítače s hypervizorem. Rozbuškou však nebyl tento celkem nevinný dokument, ale osoba přednášejícího: byl jím Jürgen Schönwälder, který je jednou z vůdčích figur stojících za návrhem protokolu NETCONF. Dotaz z pléna zněl zhruba takto: „Jestli to s NETCONFem myslíte vážně, proč nás pořád zásobujete novými daty pro SNMP a neimplementujete raději stejná data v NETCONFu?“ Většina diskutujících se pak skutečně přiklonila k názoru, že by bylo velmi prospěšné toto schizma postupně odstranit a mít všechna stavová data k dispozici prostřednictvím NETCONFu.
To se snadno řekne, ale hůře udělá. Převod všech definic objektů z databáze MIB (zapsaných v jazyku SMIv2) na datový model pro NETCONF (v jazyku YANG) je sice možný, vzhledem k vysokému počtu MIB objektů je to ale práce pro vraha, a tak se do ní nikomu nechce. Druhou alternativou, která se již také testovala, je proto automatický převod. Pro tento účel dokonce existuje specifikace v RFC 6643, jehož autorem je shodou okolností rovněž Jürgen Schönwälder.
Jenže, jak víme i z jiných případů, výsledky strojového překladu nebývají zrovna ideální. V daném případě se naráží jednak na některé nekompatibility mezi jazyky SMIv2 a YANG (příkladem je rozdílný způsob indexace objektů v databázi), ale také na problém převodu důležitých informací zapsaných v MIB modulech volným textem – doplňujících popisů a implementačních instrukcí.
Momentálně tedy převládá názor, že automatický převod lze použít ad hoc v případě akutní potřeby přístupu k MIB datům pomocí protokolu NETCONF. Z dlouhodobého hlediska bude ale asi nezbytné podstoupit martyrium spojené s ruční konverzí. Vypadá to tedy, že internetová komunita má v této oblasti o práci postaráno na řadu příštích let.
Ladislav Lhotka
Z IETF 84: standardizace konfiguračních dat
Během posledního meetingu IETF, který měl pořadové číslo 84 a konal se v kanadském Vancouveru, se výsledky mých „kmenových” pracovních skupin NETCONF a NETMOD objevily v zajímavé diskusi na širších fórech, konkrétně v mailing listu ietf@ietf.org, při jednání pracovní skupiny OPSAREA (Operations and Management Area), jakož i v kuloárních debatách.
Diskusi zahájil svým příspěvkem polský kolega Robert Raszuk. Pozastavil se nad tím, že ve specifikacích nových protokolů chybí schéma konfiguračních dat, a navrhl, aby všechna RFC povinně obsahovala oddíl s takovým schématem, protože bez něho si každá implementace vytváří svůj vlastní způsob konfigurace, který nemusí být s ostatními zrovna kompatibilní. Problém je to reálný, kdo by tomu nevěřil, ať si zkusí mezi sebou převést netriviální konfigurace směrovačů různých výrobců (včetně našeho BIRDa).
Navrhované řešení, tedy zavést toto jako povinnost, se ovšem setkalo s jednoznačným odporem. Robertovi se též dostalo doporučení, aby se seznámil s výsledky pracovní skupiny NETMOD, kde se již datové modely pro některé základní protokoly a subsystémy vyvíjejí.
V této souvislosti se ale ukázalo, že datové modely NETMOD tak docela nenaplňují vizi unifikace konfiguračních schémat. Jsou totiž poměrně pružné a umožňují definovat schémata v různých podobách, od odlišností v pojmenování objektů (klasickým příkladem jsou třeba jména síťových rozhraní) až po menší či větší rozdíly v logice a uspořádání konfiguračních dat. Důvody jsou nasnadě: Nelze očekávat, že přední výrobci směrovačů a jiných zařízení po zveřejnění datových modelů srazí paty a překopou svá konfigurační rozhraní, která si po léta hýčkají a školí na nich své zákazníky. Jistá míra pružnosti proto dává naději, že by se konkrétní implementace datových modelů mohly naopak přizpůsobit existujícím konfiguračním rozhraním. Lze pak ovšem očekávat, že nebude možné jednoduše vzít konfiguraci jednoho boxu a instalovat ji beze změn na obdobném zařízení jiného výrobce.
Toto je docela složité dilema, uvidíme, jak se věci vyvinou. Rozhodně by ale bylo dobré, kdyby se specifikace konfiguračního schématu staly součástí standardů aspoň pro nové protokoly – byť třeba nepovinně.
Ladislav Lhotka
Odvrácená strana internetu
Úvodem článku musím říci, že jsem nějaký čas přemýšlel, zda k sepsání tohoto blogpostu přistoupit. Nakonec jsem se rozhodl, že to udělám, protože ten, kdo bude chtít tyto věci zneužít, ten si tyto informace stejně dokáže opatřit a naopak si myslím, že znalost toho, jakým způsobem a kde jsou obchodována ukradená data, může přispět k větší opatrnosti i u běžných uživatelů. Navíc lze očekávat, že s nedávným úspěšným zátahem FBI na prodejce kradených údajů o platebních kartách bude většina těchto obchodů již nadále probíhat pouze v níže popsaném prostředí. FBI totiž při zatýkání uspěla díky spuštění vlastního on-line webu na doméně carderprofit.cc, který měl výměnu a prodej informací o platebních kartách umožňovat.
Screenshot původního webu carderprofit.cc, před tím, než jej FBI letos v květnu vypnula
Jako důkazy pak použila i informace o IP adresách, ze kterých bylo k tomuto webu přistupováno. To by se jí v prostředí, o kterém dnes bude řeč, nejspíš tak snadno nepodařilo získat.
Pro cestu na odvrácenou stranu internetu jsou potřeba dva open source programy: Tor a Bitcoin. Ten druhý pouze v případě, že bychom chtěli skutečně něco kupovat. V našem případě je uveden proto, aby bylo patrné, jakým způsobem probíhá anonymní obchod. Bitcoin je digitální měna, která funguje od roku 2009. Měna je stejně jako běžná hotovost při dodržení určitých pravidel těžko vystopovatelná, tedy se hodí právě k nakupování na černém trhu. Nejprve je třeba nějaký ten bitcoin získat, bitcoin lze bez problémů směnit v příslušné směnárně například za Eura. Jakmile máme bitcoiny, můžeme se vydat nakupovat.
Bitcoinová peněženka
K tomu budeme potřebovat stáhnout Tor Browser ze stránek projektu Tor. Ten má hned dvě zásadní funkce. Jeho použitím zajistíte svou anonymitu a zároveň získáte přístup ke skrytým serverům v doméně .onion, ke kterým se z „běžného“ internetu nedostanete. Skryté servery jsou běžně používány k provozování široké plejády nelegálních aktivit, od šíření návodů na výrobu různých nelegálních chemických látek až po šíření dětské pornografie. Vzhledem k povaze této sítě je totiž velmi obtížné někoho chytit a obvinit. Je však zároveň potřeba říci, že tato její vlastnost je také důležitá a užitečná. Umožňuje uživatelům z nedemokratických režimů anonymně hledat, či naopak publikovat informace, jejichž hledání či publikování by pro ně jinak mohlo znamenat problémy.
Po spuštění tohoto prohlížeče tedy zkusíme přes Google vyhledat slovní spojení Tor Directories. Tím si najdeme v „běžném internetu“ seznamy adres existujících v doméně .onion. Na načtení stránek si ovšem chvíli počkáme, síť je obvykle dost pomalá. Asi nejznámější adresářová služba pro Tor je Nobody@Zerodays.
Nobody@Zerodays
Jeden ze zde nabízených odkazů je například na Hidden Wiki, kde se můžete dovědět spoustu informací, které obvykle lidé znát nepotřebují, od návodů na výrobu drog, až po to, jak si zařídit svůj vlastní server s ilegálním obsahem, tak abyste zůstali nepostižitelní.
Hidden Wiki
Najdete zde také rozcestníky na další nelegální weby, či obchody, kde si můžete koupit cokoliv, od zbraní, přes drogy až třeba po DDOS útok.
Na jedné z .onion adres pak najdete skutečně originální e-shop s názvem Black Market Reloaded. Pro možnost obchodování je potřeba se zaregistrovat, e-mailová adresa pro registraci může být smyšlená.
BlackMarket
Tento obchod nabízí snad úplně vše, co v běžných e-shopech nenajdete. Nástroje na výrobu vlastních platebních karet, odcizená čísla platebních karet, ukradené identity uživatelů, zbraně, drogy, či dokonce trhavinu na bázi C4. Dokonce nabízí i možnosti známé především z běžných bazarových a aukčních obchodů. Kupující tedy může například po realizaci obchodu ohodnotit prodávajícího.
Je libo trhavinu i s rozbuškou?
V doméně .onion by se dala jistě najít spousta dalších „zajímavých“ věcí, se kterými se na internetu běžně nesetkáte, ale pro představení tohoto svébytného prostoru byly myslím předchozí řádky více než dostatečné. Doufám, že tato malá exkurze na odvrácenou stranu internetu pro vás byla zajímavá. A pokud se po přečtení článku také zamyslíte, zda svá data před podobnými obchodníky dobře chráníte, pak článek splnil svůj účel.
Pavel Bašta
Honeynet: kdo se přilepil za poslední 3 měsíce
Jak jsme předesílali při zveřejnění minulého článku, chceme statistiky z našeho honeynetu zveřejňovat pravidelně. Zde jsou tedy výsledky, jak si útočníci vedli od května do konce července 2012.
Nejaktivnějšími útoky byly ze dvou tchajwanských IP adres. V obou případech se připojovali téměř výhradně na port 445 (protokol SMB pro sdílení souborů a složek v systémech Windows), více než 88000-krát. Více než 14000-krát nahrávali jednu variantu viru Conficker (viz analýza serveru Virus Total). Další významní útočníci byli z ruského subnetu 31.29.144.0/21 – v top 10 jednotlivců se objevili hned čtyři:
Nejčastější útočníci (květen – červenec 2012)
Při vykreslení na mapě světa sice vedoucí Tchajwan zaniká, zato jsou vidět i ostatní země. Tradičně hodně připojení míří z Ruska, další jsou počtem připojení vyrovnané USA a Čína. Díky jednotlivcům je vidět i Venezuelu a Kazachstán:
Zdroje útoků (květen – červenec 2012)
Pořadí portů, o které měli tentokrát útočníci zájem, vede zmiňovaný port 445, dále 139 (NetBIOS session service), 80 (HTTP), 1433 (Microsoft SQL Server), 3389 (Remote Desktop Protocol) a 5060 (SIP). Horizontální osa grafu používá logaritmickou škálu:
Cílové porty (květen – červenec 2012)
Proti minulé statistice výrazně narostlo procento rozpoznaných operačních systémů útočníků. Systémy s různými verzemi OS Windows má celkem 69,2 % útočníků, systémy založené na Linuxu s jádrem verze 2.6 9,4 %, ostatní systémy zůstaly neurčené:
Operační systémy útočníků (květen – červenec 2012)
Navíc tentokrát přinášíme přehled nejčastěji nahrávaných virů. Celkem jsme zaznamenali 33165 nahrání virů (z toho 600 unikátních). Průměrně tedy jeden virus každé 4 minuty. V tabulce je 10 nejčastějších s jejich identifikací podle antiviru Kaspersky. Kido, který je vidět osmkrát, je jiné označení viru Conficker. Zbylé dva viry jsou z rodiny Genome. Velké zastoupení viru Conficker lze připsat dobře simulované zranitelnosti MS08-067, díky které se šíří.
Nahraný malware (květen – červenec 2012)
Pro zajímavost nabízíme nakonec tabulku nejčastějších kombinací, které útočníci zkoušeli při přístupu na službu SSH v červenci. Osobně mě překvapilo heslo 1qazxsw2. Pokud vás taky, tak si ho zkuste napsat na klávesnici.
Přihlašování na SSH (červenec 2012)
Jiří Machálek
Tak už nejsme první
S počátkem vzniku technologie DNSSEC odstartovala mezi jednotlivými správci domén nejvyšší úrovně jakási neformální soutěž o to, kdo bude mít více podepsaných domén nižší úrovně. Zde je třeba připomenout, že poměrně dlouho dominovali Švédové, kteří nasadili tuto technologii jako úplně první. Na začátku roku 2010 jsme vedoucí místo získali my a díky úžasné práci našich registrátorů jsme si jej drželi až do tohoto měsíce. V české doméně je v současnosti podepsáno přes 350 tisíc domén. A ačkoliv jsme spíše čekali nový nástup Švédů, novým králem této disciplíny se stal registr Nizozemí. Holanďané mají v současnosti hodně přes půl miliónu podepsaných domén. Je to již druhá příležitost v poměrně krátké době ke gratulaci pro tuto doménu. Nedávno totiž překročili hranici 5 miliónů domén a řadí se tak k největším doménám světa.
V absolutních číslech jsme už tedy pozici ztratili, ale zatím jsme špičkou alespoň v procentuálním podílu podepsaných domén. Dovolte mi ještě jednou českým registrátorům poděkovat za úctyhodných 37 % podepsaných domén. Jen tak dál, snad brzy překročíme i těch magických 50 % a počet podepsaných domén převýší počet těch nezabezpečených.
Ondřej Filip