Pravděpodobně neexistuje nikdo z IT oboru, kdo by nezaznamenal chybu v knihovně OpenSSL nazvanou Heartbleed. Mnoho z nás si s ní užilo své, ať již při patchování serverů, vydávání nových certifikátů či při pomoci uživatelům se změnami jejich hesel.
V CSIRT.CZ jsme se navíc zaměřili také na prevenci, protože i když byla tato chyba skutečně značně medializovaná, stále mohou existovat služby, které jsou vůči ní zranitelné. Proto jsme se ve spolupráci s Laboratořemi CZ.NIC pustili do skenování českých webů právě na tuto zranitelnost. Po dokončení skenování bychom rádi kontaktovali příslušné správce a informovali je o riziku, které by mohla tato zranitelnost pro jimi provozované služby a jejich uživatele představovat.
Bezpečnostní incident v číslech: napadení známé webové stránky
Včera jsme zaznamenali napadení serveru nevyhazujto.cz. Útočník, jak bývá v těchto případech obvyklé, použil úmyslně nečitelný javascript kód, který po dekódování přidával do stránky tento kód:
<script type="text/javascript">
var now = new Date().getTime();
if (now%7 == 0) {
window.location = "http://bit.ly/1glIErF";
}
</script>
Smysl je jednoduchý: v jednom ze sedmi případů přesměrovat uživatele na adresu https://bitly.com/1glIErF. Z této adresy je pak uživatel přesměrován řetězcem dalších webů, které můžou konečný cíl měnit. V jednom případě jsem skončil na bearshare.com, v druhém na torchbrowser.com s nabídkou ke stažení jejich programů (a téměř určitě bude cílů více). Kdo by za nimi hledal malware, tak bude možná překvapen, alespoň Virustotal je tak nehlásí. Monetizace v tomto případě útočníkovi plyne z affiliate programů daných webů, protože součástí odkazu je i jednoznačný identifikátor, který má útočník zaregistrovaný a sbírá přes něj provize z provedených instalací, uskutečněných nákupů apod.
Jak Heartbleed poukázal na slabiny certifikačních autorit
Nejspíše jste zaznamenali objevenou zranitelnost v OpenSSL nazvanou Heartbleed, která může vést nejen k odcizení privátních klíčů z SSL certifikátů. Pro odstranění tohoto problému je potřeba aktualizovat knihovnu OpenSSL a vyměnit klíče a certifikáty. Samotná aktualizace není dostatečná, neboť tato chyba byla v dotčené knihovně dva roky a není způsob jak zjistit, zda došlo k odcizení klíčů. Proto je nutno přistupovat ke všem serverům se zranitelnou knihovnou jako ke kompromitovaným.
V Polsku se objevil nový a obzvlášť záludný útok na domácí uživatele
Akademický CSIRT tým CERT Polska upozornil předminulý týden na nový a velmi nebezpečný útok, který zneužívá nedávno nalezené chyby v domácích routerech. Útočníci při něm změní DNS servery v routeru na DNS servery ovládané útočníky. Pokud si pak oběť vyžádá například adresu www.skvelabanka.cz, útočník ji může přesměrovat na jím ovládané webové stránky. Tento útok postihne všechna zařízení, která jsou v koncové síti připojena, lhostejno, zda se jedná o mobilní telefon, tablet s OS Android, MAC či PC s OS Linux nebo Windows. Takto se útočníkům efektivně podařilo překonat problém s multiplatformním prostředím, které obvykle brání rozšíření klasického bankovního malwaru na více platforem. Na druhou stranu je útok omezen přítomností zranitelného routeru v dané síti.
Stav přístupnosti webů našich zdravotnických zařízení
Přístupnost webů je důležité téma, které řeší především tvůrci webových stránek určených hlavně lidem s různými schopnostmi a zdravotními postiženími. Jsou-li webové stránky správně navrženy, vyvinuty a upraveny, pak k informacím a funkcionalitám mají přístup všichni uživatelé víceméně bez rozdílu. Dostupný web vychází vstříc různým potřebám, například vizuálním, motorickým a potřebám mobility, sluchovým, nebo kognitivním.
Skener webu – skúsenosti a štatistiky za prvých päť mesiacov
V roku 2013 sa tým CSIRT.CZ rozhodol, že rozšíri svoje portfólio ponúkaných služieb a zároveň sa pokúsi vytvoriť akýsi obraz zabezpečenia českých webov. A tak vznikla služba Skener webu.
Co nám říká aféra kolem Yahoo?
Ti z Vás, kteří čtou naše aktuality z bezpečnosti, možná před časem zaznamenali informaci týkající se nebezpečné reklamy, která byla součástí stránek yahoo.com. Klienti, kteří navštívili yahoo.com, obdrželi jako součást stránek také reklamy ze serveru ds.yahoo.com.
Některé z těchto reklam však byly nebezpečné. Tyto reklamy byly vložené jako rámce, které odkazovaly na další domény, z nich pak vedlo přesměrování na další adresu obsahující exploit kit zaměřený na chyby v Javě. V případě úspěšné exploitace byl pak na počítač návštěvníka stránek yahoo.com nainstalován některý z následujících malwarů:
– ZeuS
– Andromeda
– Dorkbot/Ngrbot
– Advertisement clicking malware
– Tinba/Zusy
– Necurs
Podle odhadů postavených na návštěvnosti stránek yahoo.com a obvyklé percentilové úspěšnosti v případě těchto útoků (okolo devíti procent) se odhaduje, že každou hodinu, po níž byly tyto reklamy na yahoo.com poskytovány, bylo některým z uvedených virů nakaženo 27 000 návštěvníků.
Proč o tom píši? Protože jsme tentokrát měli štěstí. Zdá se, že čeští uživatelé nebyli cílovou skupinou tohoto útoku (reklama byla primárně zaměřena na Rumunsko, Velkou Británii a Francii). Navíc yahoo.com nepatří v ČR mezi nejpoužívanější služby. Jenže nikde není řečeno, že příště se podobný útok nebude šířit ze stránek, které jsou v České republice populární.
Každá společnost, která prodává reklamu, může být podobným způsobem zneužita. Proto je potřeba, aby konečně koncoví uživatelé vzali na sebe zodpovědnost za správu a údržbu svých počítačů.
Devítiprocentní úspěšnost těchto útoků je prostě příliš vysoké číslo a je jasné, že se útočníkům podobné akce stále vyplatí. Přitom by stačilo, kdyby uživatelé udržovali své programové vybavení aktualizované, protože v případě použití různých exploit kitů se v drtivé většině případů jedná o již známé a záplatované zranitelnosti.
Bohužel nejde jen o soukromí a finance těchto nezodpovědných uživatelů. Jejich nezájem může mít v propojeném světě Internetu dopad na další uživatele. Otázkou je, jak přimět uživatele, aby se sami starali o stav svých počítačů.
Pavel Bašta
Postfix dostal podporu pro DANE protokol
Podporu pro protokol DANE již nějakou dobu můžete v prohlížeči používat pomocí rozšíření DNSSEC Validator dostupné pro prohlížeče Firefox, Chrome/Chromium a Internet Explorer. A hned na začátku tohoto roku bych rád přivítal prvního zástupce serverové aplikace s podporou protokolu DANE, jelikož 15. ledna vyšla nová stabilní verze poštovního démona Postfix, která mimo jiné přináší podporu pro protokol DANE. Autoři Postfixu se rozhodli, že pro poštovní servery, které ve valné většině používají self-signed certifikáty, nemá moc smysl podporovat duální kontrolu CA + DANE a tudíž implementace v Postfixu podporuje pouze Certifikate Usage 2 – „Vlastní kořen důvěry (CA)“ a 3 – „Vlastní self-signed certifikát“. Certificate Usage 0 – „Omezení na konkrétní CA“ a 1 „Omezení na konkrétní certifikát od CA“ se mapují na typy 2 a 3.
Pojďme si nyní rychle ukázat, jak takovou podporu na Vašem serveru zapnout.
Na straně přijímající je potřeba mít vygenerovaný certifikát a zapnuté TLS. A jelikož toto není nic nového a dokonce možná toto za Vás udělal rovnou instalační balíček Vaší distribuce, odkázal bych Vás jen na dokumentaci.
Ta zajímavější část přichází ve chvíli, kdy do DNS chceme umístit TLSA záznam, kterým dáme světu vědět, že s námi může komunikovat zabezpečeně, a náš certifikát má odpovídat tomu, který jsme vygenerovali na serveru. Na generování mohu s klidným srdcem doporučit utilitu swede, případně utilitu hash-slinger.
TLSA záznam pomocí utility swede vygenerujeme následujícím způsobem:
swede create --port 25 --protocol tcp --output rfc --usage 3 --selector 1 --mtype 1 --certificate
Vygenerovaný záznam, který bude vypadat například takto:
_25._tcp.mail.rfc1925.org. IN TLSA 3 1 1 5afe6a99c7d658a5cee951da6ebe7a21e0d7604f831248177f4283ecf639fad6
vložíte do příslušného zónového souboru a DNS server reloadnete. Pokud Váš DNS server nepodporuje TLSA záznamy, máte dvě možnosti: buď server vyměníte za nějaký modernější (např. Knot DNS) nebo místo volby --output rfc použijete volbu --output generic, která vygeneruje TLSA záznam v obecném formátu, který by měly podporovat i DNS servery bez přímé podpory pro TLSA záznamy.
Tímto jsme zapnuli podporu pro DANE protokol na straně serveru, který poštu přijímá. Jak tedy nastavit ověřování TLSA záznamů na straně odesílajícího serveru?
Předně musíte mít nainstalovaný postfix 2.11.0 a vyšší. Balíčky pro Ubuntu jsou k dispozici například v tomto PPA. Konfigurace je pak velmi jednoduchá, do konfiguračního souboru přidáte tři řádky:
postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"
postconf -e "smtp_tls_loglevel = 1"
a restartujete Postfix.
Následně se stačí podívat do mail.logu, kde by se měl objevovat pro servery s podporou DANE protokolu následující záznam:
Aug 2 10:35:49 jedi postfix/smtp[24161]: ***Verified*** TLS connection established to mail.nic.cz[217.31.204.67]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
a pro servery bez podpory:
Aug 2 10:46:54 jedi postfix/smtp[24300]: ***Untrusted*** TLS connection established to aspmx.l.google.com[2a00:1450:4001:c02::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
Na závěr bych chtěl poděkovat Viktoru Dukhovnimu, za jeho práci na implementaci protokolu DANE v Postfixu a Vám popřát šťastné a veselé šifrování v novém roce :).
Ondřej Surý
Brusel mírní návrh na regulaci SSL certifikátů
Je tomu již více než rok, co jsem zde psal o snaze Evropské komise regulovat pod hlavičkou revize rámce pro elektronické podpisy a eID (tzv. eIDAS) rovněž oblast certifikátů pro webové stránky, tzv. SSL certifikátů. O tom, že projednávání návrhu tohoto nařízení bude běh na dlouhou trať, svědčí mimo jiné to, že i po roce a půl od jeho představení jsme stále daleko od jeho schválení. To se v ideálním případě očekává až před volbami do Evropského parlamentu, tj. v květnu 2014, s tím, že v platnost by tato, pro členské státy přímo účinná, legislativa vstoupila v platnost 1. ledna 2015.
V rámci projednávání návrhu na půdě Rady byla Česká republika mezi těmi, kteří hned na úvod projednávání nesouhlasili s rozšířením současné regulace rovněž o SSL certifikáty s tím, že postupně se k nám přidaly další státy. V současné době litevské předsednictví dokonce navrhuje vypuštění textu, jisté zmírnění požaduje rovněž Evropský parlament, konkrétně výbor ITRE (Výbor pro průmyslu, dopravu, výzkum a energetiku). Ten na svém říjnovém zasedání navrhl (viz tučný text) zohlednit rovněž zapojení internetové komunity (skrývající se v euro-slangu pod pojmem stakeholders) a vypracování analýzy dopadu.
|
Article 37 Requirements for qualified certificates for website authentication
|
Ponechme nyní stranou, zda by evropská legislativa měla obsahovat spojení jako „nejlépe“ (preferably) a raději se zaměřme na zohlednění zájmu internetové komunity. Text totiž v tomto ohledu hovoří o jejím zapojení, na druhou stranu však Evropská komise „znovu vynalézá“ kolo, když se v příloze č. IV snaží definovat obsahové náležitosti SSL certifikátů. Na tomto místě by však měla být zohledněna práce IETF a již existující RFC (Request For Comments), které jsou v prostředí Internetu obdobou klasických standardů.
Zmiňovaným SSL certifikátům se věnuje zejm. RFC 5246 a RFC 3039, které definuje mj. obsah certifikátů, tj. tu samou věc, o kterou se Komise snaží v příloze IV. Na tuto skutečnost upozornil na svém říjnovém zasedání rovněž RIPE, který svoji pozici vyjádřil v dopise adresovaném Evropskému parlamentu.
V rámci nadcházejících jednání bude důležité, aby se členské státy za návrh Předsednictví postavily, při jednání s Evropský parlamentem i Komisí regulaci certifikátů jasně odmítly a podpořily tím principy správy Internetu i dosavadní práce na IETF.
Jiří Průša
Služba CAPTCHA Help se dočkala řady změn
Službu CAPTCHA Help provozuje CZ.NIC od srpna tohoto roku. Za tuto poměrně krátkou dobu si už ale stihla najít své věrné uživatele; těch je aktuálně více než 200 a stále přibývají. Když k tomu přidáme cca 10 vyřízených požadavků týdně, můžeme směle tvrdit, že si své místo a zájemce našla. A právě proto, že se služba ukazuje jako perspektivní, pracují vývojáři na jejím vylepšování.
Vývojáři proto nedávno zveřejnili dokument nazvaný S CAPTCHA Help doplňkem o krok dál. Ten je rozdělený do jednotlivých kapitol – Instalace, Nastavení a Použití, předposlední díl je potom věnovaný roli operátora a poslední budoucnosti. V této závěrečné části vývojář Petr Závodský kromě jiného píše: „Ke službě CAPTCHA Help velice brzy přibudou doplňky pro další prohlížeče: Internet Explorer, Mozilla Firefox, Safari. Doplňky prohlížečů chceme také vylepšit o některé další funkcionality, např. dát uživateli možnost zvolit si rozsah screenované části kolem CAPTCHA obrázku. Služba bude také postupně optimalizovaná tak, aby uživatel obdržel odpověď do několika desítek sekund. CAPTCHA Help také začínají využívat zahraniční uživatelé a i na ně se proto postupně začínáme zaměřovat.“
Celý dokument je proložen řadou obrázků a postupů, jak se službou efektivně pracovat. Měl by tedy bez problémů posloužit všem, kteří se chystají nové funkcionality využívat.
Vilém Sládek