Zdroje útoků v dubnu 2012

Mapa je obarvena sytější barvou tam, odkud jsme zaznamenali více spojení. Není velkým překvapením, že vede Rusko, druhý za ním je potom Írán. Pokud se ale podíváme na žebříček nejčastějších IP adres, je vidět, že tyto země se do vedení dostaly zásluhou jednotlivců, navíc šlo o jednorázové skenování. Mimo těchto dvou případů je vidět, že zdroje útoků jsou velmi pestré a vyrovnané.

Nejčastější útočníci (duben 2012)

O jaké služby je největší zájem? Nejčastěji se útočníci zkouší připojit na port 80 (HTTP server), následně port 135 (služba Microsoft Remote Procedure Call), 5060 (protokol SIP), 3389 (Remote Desktop Protocol) a 1080 (SOCKS server). Není to nic překvapivého, protože všechny tyto služby se dají v případě napadení dobře zpeněžit nebo alespoň posloužit k dalšímu šíření virů.

Cílové porty (duben 2012)

Poslední statistika ukazuje pravděpodobné operační systémy útočníků (ten určuje pasivně utilita p0f z charakteristik TCP/IP komunikace): Systémy s různými verzemi OS Windows má celkem 39,5 % útočníků, systémy založené na Linuxu s jádrem verze 2.6 16,7 %, ostatní systémy zůstaly neurčené.

Operační systémy útočníků (duben 2012)

Jiří Machálek

Úkolem nového centra, jenž by fungovalo v rámci Europolu, by mělo být především shromažďovat informace o kyberkriminalitě, podporovat členské státy či vystupovat jménem vyšetřovatelů z celé Evropy, kteří se touto formou trestné činnosti zabývají. V hledáčku pozornosti této instituce by pak měly být trestné činy, jako jsou podvody na internetu páchané organizovanými skupinami, pohlavní vykořišťování dětí či útoky proti kritické informační infrastruktuře.

Podle plánu EK by mělo být centrum zřízeno již v průběhu příštího roku a v plném provozu by mělo být o rok později, tedy od roku 2014. Do té doby však návrh čeká projednávání Radou EU i Evropským parlamentem. Budeme tedy moci sledovat, co se z na první pohled „nevinných formulací“ typu „podpora vazeb na skupiny CERT“ či „spuštění internetové aplikace pro hlášení případů kybernetické kriminality a napojení ohlašovacích kanálů pocházejících od různých aktérů včetně podniků“ vyklube. Zajímavé bude jistě i nastavení kompetencí ve vztahu k Evropské agentuře pro bezpečnost sítí a informací (ENISA), jejíž stávající mandát vyprší 13. září 2013 a při projednávání nového mandátu na půdě Rady i Evropského parlamentu zaznívají hlasy, které by ENISA rády přiřkly rovněž pravomoci v oblasti kybernetické kriminality.

Jiří Průša

Takto vysoký počet žádostí znamená, že posuzování bude rozděleno do nejméně čtyřech dávek. Jak jsem již vysvětloval v článku na Lupě, ICANN totiž již dříve avizoval, že dokáže posuzovat nejvíce 500 žádostí v jednom okamžiku. Délka úvodní části posuzování žádosti byla odhadnuta na přibližně pět měsíců. Tedy jenom úvodní fáze posuzování nebude pro některé domény hotova dříve než v půlce roku 2014.

V této souvislosti si stále kladu otázku, proč bylo tak nutné zastavit proces pouhých 12 hodin před ukončením řádné lhůty. ICANN ohlásil, že důvodem byl únik informací. Ale s ohledem na to, že se všechny žádosti mají stejně brzy zveřejnit, v tom až tak velký problém nevidím. Ano, někdo mohl v systému zjistit, jakou doménu chystá jeho konkurence, ale zjistit to 12 hodin před uzavřením podávání žádostí by mu už nijak nepomohlo – žádost by už stejně nestihl podat. Velice podezřele působí i fakt, že systém je odstaven již téměř měsíc. Teď naopak lidé, kteří nějaké informace nelegálně získali, mají čas s nimi pracovat. Takže mi to připadá velmi podezřelé. No těším se, až budu moci na meetingu v Praze položit zástupcům ICANNu několik otázek.

Ondřej Filip

Krátká přednáška Todda Underwooda (Google) na nedávném RIPE 64 mě ale přivedla k úvahám, zda bych neměl svůj postoj k OpenFlow a SDN přehodnotit. Google totiž používá OpenFlow switche ve dvou svých produkčních páteřních sítích, které propojují lokality na třech kontinentech. OpenFlow jim umožňuje pojímat tyto sítě jako systém pro transport dat a ne pouze jako soubor jednotlivých switchů a linek.

OpenFlow je postaven na myšlence oddělení forwardovací logiky (data plane) od směrovacích, filtrovacích a jiných algoritmů (control plane). Zatímco data plane zůstává „zadrátovaná“ ve switchi, control plane se přesouvá na samostatný počítač (controller), který může řídit jeden nebo více switchů. Jádrem OpenFlow je protokol a API umožňující kontroléru konfigurovat zacházení s pakety ve switchi.

OpenFlow předpokládá, že data plane je ve switchi implementována ve formě tabulky toků s využitím hardwarové asociativní paměti (TCAM). V tom ovšem vidím jistý problém: špičkové TCAM čipy mají kapacitu jednotek až desítek tisíc položek, takže se do nich rozhodně nevejde kompletní směrovací tabulka BGP. Mohli bychom sice zvolit alternativní strategii – plnit tabulku na základě toků, které switch skutečně přenáší – ale ani s tou se moc daleko nedostaneme, protože typické počty aktivních toků v páteřních internetových směrovačích kapacitu TCAM rovněž vysoko překračují. Zdá se tedy, že kombinace OpenFlow switche a směrovacího démona není v roli obecného BGP routeru příliš použitelná.

Myslím si ale, že i tak bychom se v Laboratořích CZ.NIC mohli OpenFlow trochu podívat na zoubek. Minimálně by stálo za to demonstrovat, že OpenFlow switch může fungovat i s BIRDem v pozici kontroléru (Google používá Quaggu). Je docela možné, že takový hardwarově akcelerovaný směrovač by se mohl v některých situacích dobře uplatnit.

Za pozornost stojí také standard OF-CONFIG 1.0, který se zabývá konfigurací a správou „provozního kontextu“ OpenFlow switche, tedy de facto všeho kromě tabulky toků. Standard pro tento účel používá protokol NETCONF a datové modely zapsané v jazyku YANG. Jde zřejmě o dosud největší otevřeně dostupnou aplikaci technologií NETCONF/YANG.

Ladislav Lhotka

Dále se ICANN ve své zprávičce věnuje hlavnímu důvodu, proč byl systém odstaven. Někteří uživatelé mohli částečně vidět data jiných uživatelů. Konkrétně u cca 100 z nich mohl někdo cizí vidět uživatelská jména a jména souborů. Ve zprávičce bohužel chybí to hlavní, a to datum znovuspuštění TASu. Tak doufejme, že to již bude brzy a celý proces vzniku nových domén se opět rozběhne.

Každopádně jako předseda pracovní skupiny pro přípravu ccNSO meetingu v ICANNu jsem požádal zaměstnance ICANNu o prezentaci k tomuto tématu. Takže pokud budete mít zájem zúčastnit se pražského ICANN meetingu, můžete se o tomto problému dozvědět více.

Ondřej Filip

do-release-upgrade

případně pro přechod z předchozí LTS verze doplněn o přepínač -d

do-release-upgrade -d

Po jejich zadání se dozvíme,… že žádné nové verze nejsou k dispozici. Jak je to ale možné? Při bližším zkoumání komunikace zjistíme, že tento nástroj se snaží komunikovat na adresu http://changelogs.ubuntu.com/, která má ale bohužel pouze IPv4 překlad. Na tento problém již téměř rok existuje bug report, který je bohužel stále otevřený, i když by vše spravila drobná oprava v DNS. Řešení tohoto problému jsou v podstatě dvě (pokud zanedbáme reinstalaci, ale komu by se chtělo vše znova nastavovat). Je možné použít NAT-64, pokud ho máme nasazený, nebo dočasně pustit do sítě „zastaralou“ IPv4.

Poté, co jste systém přesvědčili o existence nové verze, stále nemáme vyhráno. Standardní mirror eu.archive.ubuntu.com má opět pouze IPv4 adresy. Situace je trochu lepší u národního archivu cz.archive.ubuntu.com, který má IPv4 i IPv6 adresy. U bezpečnostních oprav je situace obdobná, hlavní server security.ubuntu.com není dostupný po IPv6 a proto je nutno upravit seznam zdrojů. Jedna z možností je popsána například v tomo blogu, kde se řeší oba problémy.

Na všechny výše uvedené problémy jsou vytvořeny bugreporty, a tak nezbývá než doufat, že se jich někdo ujme a vyřeší je. Do té doby bude potřeba alespoň pro upgrade verze zajistit připojení po IPv4.

Petr Černohouz

Aktualizace 3.5.2012: Zaktualizován stav eu.archive.ubuntu.com a cz.archive.ubuntu.com.

• Při konverzi long -> int na x86_64 architektuře dochází k ořezání nejvyšších 32 bitů, výsledek se uloží do 32-bit integeru se znaménkem. Použitím DER-enkódovaného certifikátu, který má nějaký length-field s bitem 32 nastaveným, dojde k přetečení do záporných čísel.
• Funkce realloc() podle C99. standardu musí umět jak paměť alokovaného bloku zvětšit, tak zmenšit. Problém spočívá v tom, že obdobná funkce CRYPTO_realloc_clean() v OpenSSL nepodporuje zmenšení bloku. Pokud je nová délka alokovaného bloku menší než původní délka, část paměti za alokovaným bufferem se přepíše bajty navíc z původního bloku.

Kombinací obou chyb lze část paměti přepsat „speciálně formovaným“ certifikátem. Chybu je poměrně těžké zneužít, ale rozhodně to není nemožné. Týká se funkcí pojmenovaných d2i_*_bio a d2i_*_fp (a pár dalších pracujících s CMS a S/MIME).

Zatím probíhá šetření, který software používající OpenSSL je chybou ovlivněn. V tuto chvíli jsou chyby s největší pravděpodobností vyloučeny u:

• OpenSSH – používá vlastní kód pro parsování ASN.1
• Tor – používá in-memory d2i_* a PEM_* funkce, žádné z napadnutelných
• DNSSEC Validator – ASN.1 parsování se vůbec nepoužívá
• dslib – openssl se vůbec nepoužívá, ASN.1 parsování dělá pyasn1
• datovka – potenciálně zranitelná funkce OpenSSL.crypto.load_pkcs12 se nachází jen u načtení vašeho certifikátu z disku (tudíž dokud ho někdo nezmění, nic se nestane; navíc používá se jenom při přihlašovaní certifikátem)
• Knot DNS 1.0.3 – žádná zranitelná funkce se nevolá
• Firefox 11, Thunderbird 11.0.1 (komponenty NSS, NSPR a XulRunner) – Firefox i Thunderbird mají ale spoustu závislostí; je teoreticky možné, že jsem něco přehlédnul
• Apache 2.4.2, nginx 1.0.15 a 1.1.19, lighttpd 1.4.30 – používají některé ze zranitelných funkcí, ale jenom při čtení certifikátů z disku

Další pár očí pro kontrolu samozřejmě neuškodí. Statickou analýzou kódu jsem vytvořil call-graph a regexp, kterým lze ověřit, jestli nějaký kód volající funkce openssl používá potenciálně zranitelné funkce. Bugy jsou opraveny ve verzích openssl 1.0.1a, 1.0.0i or 0.9.8v. Jeden způsob, jak zmírnit dopad chyby v openssl (i budoucí), je použití stunnel v jail-u, ale má to některé další nevýhody jako těžší zpracování logů.

Další zajímavý fakt je, že tato konkrétní chyba (bez části o realloc()) byla publikována v roce 2006 v knize The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. Zde je fotografie stránek se zmíněnou chybou (konverze long -> int). Nicméně to není první ani poslední „znovuobjevený“ bug v softwaru.

Ondrej Mikle

• nové implementace IP musí obsahovat podporu pro IPv6
• aktualizace stávajících implementací by měly podporovat IPv6
• podpora IPv6 musí být srovnatelná nebo lepší, než podpora IPv4
• nové a aktualizované implementace by měly podporovat souběh IPv4 a IPv6 (dualstack) a nesmí mít IPv4 jako podmínku pro svůj běh
• implementátorům se doporučuje aktualizovat software a hardware pro podporu IPv6, pokud je to možné.

Hlavně třetí bod je v současné době zanedbáván. I když se zařízení chlubí podporou IPv6, může nastat situace, kdy je například firewall funkční pouze pro IPv4 a pro IPv6 jsou k dispozici jen dvě záložky nastavení základních parametrů. Zajímavé bude také sledovat, jak se výrobci vypořádají s bodem čtyři, který znamená možnost běhu v IPv6 only síti (pokud máte pocit, že to vaše zařízení zvládne, můžete navštívit naši IPv6 laboratoř a vyzkoušet to v praxi). Ačkoliv poslední bod by nám měl dávat naději na lepší stav IPv6, uvidíme, jak to bude vypadat v praxi a zda výrobci vydají aktualizace s podporou IPv6 k již existujícím zařízením. 

Zbývá jen doufat, že tyto doporučení vezmou výrobci za svá a na trhu se objeví dostatek domácích routerů a modemů s podporou IPv6. Odstranila by se tak jedna z překážek pro zavedení IPv6, případně by byla odstraněna v rámci přirozené výměny dosluhujících zařízení.

Petr Černohouz

Jak už je na IETF zvykem, je neděle věnovaná tutoriálům. Mezi ně byl trochu narychlo zařazen i tříhodinový tutoriál na OpenID Connect. To ještě více umocnilo fakt, že tato konference byla problémům digitálních identit věnovaná víc než jsem sám čekal. V zajímavé souhrnné prezentaci bylo zmíněno i probíhající vzájemné testování existujících implementací. Zájemcům o OpenID Connect bych určitě doporučil blogy jeho autorů, zejména články OpenID Connect in a nutshell a Designing a Single Sign-on system using OAuth 2.0. A pokud někdo stále nerozumí rozdílům mezi OpenID a OAuth, existuje i Dummy’s guide. Na závěr byl prezentován i projekt AccountChooser jako nástroj pro poskytovatele služeb, kteří chtějí implementovat jednotné přihlášení napříč technologiemi. Jak udělat správně uživatelské prostředí na straně poskytovatele služeb je zjevně oříšek a nikdo není spokojen s tím co se nazývá NASCAR UI – desítky barevných tlačítek s různými poskytovateli, mezi kterými si uživatel musí nalézt toho svého.

Z pondělních pracovních skupin zaujala NETMOD, jejíž cíl je vydefinovat univerzální datové modely pro vzdálenou konfiguraci různých prvků pomocí protokolu NETCONF. Na datovém modelu pro konfiguraci routingu totiž pracuje Láďa Lhotka z našich laboratoří. Odpolední technické „plenary“ začalo připomenutím druhého dne IPv6, na který se připravujeme i my. Potom už byly hlavními tématy TLS, problémy certifikačních autorit a zabezpečení webu obecně, které se lehce vyhrotilo při kritice tvůrců prohlížečů spočívající v tvrzení, že napadené nebo pochybné certifikační autority neodstraňují z prohlížečů flexibilně.

Avizovaná panelová diskuze o OpenID a OAuth pořádaná organizací ISOC v úterý před polednem byla pro auditorium, ve kterém seděli zástupci různých (číselných i doménových) registrů, spíše seznamovací. Její obsah nejspíš jen vyvolal v posluchačích otázky, které jsme si my položili již dříve a odpověděli na ně v podobě služby MojeID. V navazující pracovní skupině KITTEN, o které jsem se zmiňoval dříve v souvislosti s použití OpenID pro zabezpečení dalších internetových protokolů, se pouze probral stav existujících dokumentů bez nějakého zásadního posunu. To na WEIRDS se očekávala bouřlivá diskuze o podobě nového WHOIS protokolu. Překvapivě se ozvali pouze jednotlivci, kteří mají obavy o zbytečně vynaložené úsilí. Navržený „charter“ pro připravovanou pracovní skupinu tedy bude poslán ke schválení příslušným orgánům IETF. V podvečer ještě zasedla pracovní skupina DNSEXT. Na ní Ondra Surý z našich laboratoří prezentoval navrhovanou úpravu protokolu IXFR. Tato pracovní skupina se pravděpodobně setkala naposledy; její odsouhlasené rozpuštění již čeká pouze na administrativní proceduru.

Středeční program nabídl mimo jiné pracovní skupinu TLS. Ta probírala rozšíření mechanismů pro získání certifikátů při navazování TLS spojení, např. z DNS, jak bylo schváleno v rámci pracovní skupiny DANE. Tato pracovní skupina již všechny svoje dokumenty dokončila a jsou v procesu schvalování, takže pro ni nebyl důvod se tentokrát scházet.

A opět ty identity. Na čtvrteční ráno byl naplánován BOF týkající se protokolu SCIM (Simple Cloud Identity Management). Velcí poskytovatelé cloudových služeb by si rádi standardním způsobem synchronizovali data o uživatelích. Navrhli tedy protokol, který má standardizovány operace pro založení, zobrazení, změnu a zrušení (CRUD) vzdáleného kontaktu spolu s univerzální datovou strukturou v XML a JSONu. Jestli vám to připomíná EPP, které používáme v našem doménovém registru, tak mně také. To jen ukazuje, že staré nápady jsou neustále recyklovány a možná není daleko doba, kdy místo EPP protokolu budeme také používat nějaký REST protokol nad HTTP. Následovala druhá panelová diskuze týkající se OpenID, OAuth a tentokrát i BrowserID. Je více než zřejmé, že BrowserID nemůže OpenID aktuálně plnohodnotně nahradit. Pracovní skupina OAUTH poté řešila hlavně tzv.“rechartering“, tzn. změnu svých cílů. Pro OpenID Connect bude důležité, jestli si pracovní skupina vezme za své některé osiřelé specifikace, na kterých je závislý jako např. Simple Web Discovery. Proti tomu se zvedl částečný odpor, neboť se opět jedná o alternativní přístup k něčemu, na co již existují v IETF jiné standardy host-meta a webfinger.

Závěrečnou tečku za konferencí udělala v pátek pracovní skupina DNSOP. Hlavním tématem bylo TTL a jeho snižování nebo zvyšování. Inženýři z Verisign navrhují jeho výrazné zvýšení jako ochranný mechanismu proti případné nedostupnosti autoritativních serverů. Jejich japonští kolegové naopak doporučují výrazné snížení jako ochranný mechanismus z důvodu rychlého zotavení z případné chyby např. v souvislosti s technologií DNSSEC. K tomu se samozřejmě ještě přidává zákaznický pohled, neboť uživatelé samozřejmě chtějí vidět svoje požadované změny okamžitě. Jednoznačná odpověď asi neexistuje.

Jaromír Talíř

Jednodenní vzdělávací (čti informativní) kurz pro učitele IT předmětů na gymnáziích, středních a vyšších odborných školách se uskuteční v naší akademii 14. června. Pásmo se bude skládat z přednášek o tom, jak funguje internet, jak je to s doménami a s přechodem na IPv6, co je DNS, DNSSEC, IDN nebo mojeID. Chybět nebude ani část o projektech, které v CZ.NIC pro školy a jejich návštěvníky připravujeme, nebo diskuse na závěr o tom, co by od nás pedagogové uvítali.

Tento kurz je pro pedagogy, a to zdarma. Doporučujeme proto přihlásit se co nejdříve, aby bylo ještě místo. V případě, že se utrhne lavina zájmu a my budeme zahlceni přihláškami (na to se v duchu těšíme ), vypíšeme samozřejmě náhradní termín. Jestli nás tedy čtete i na školách a tato nabídka vám přijde zajímavá, neváhejte a přihlaste se. Čas máte do 14. května včetně. Pokud máte kolem sebe kolegy, které by to všechno kolem internetu mohlo zajímat, dejte jim vědět nebo je rovnou přihlaste.

A pro vás ostatním, kterým jsou už školní lavice malé. Měli byste o takové jednodenní posezení zájem? Dejte nám vědět v komentářích, jestli se máme myšlence zařadit takový kurz do naší nabídky dále věnovat. Přeci jen, do akademie jsou zvyklí chodit spíše odborníci s praxí. V tomto případě jde jednoznačně o kurz méně odborný.

Aktualizováno 12. dubna 2012:
Protože se tato nabídka setkala s dobrou odezvou, otevřeli jsme ještě jeden běh tohoto kurzu; ten je od dnešního dne vypsaný na 31. května. Pokud mě ale dosud někdo nepředběhl, na 14. června jsou ještě dvě nebo tři místa volná. Zájem účastníků nás velice těší.

Vilém Sládek