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.

Celý článek

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.

Celý článek

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.

Celý článek

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.

Celý článek

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 název.serveru

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

  1. Qualified certificates for website authentication shall meet the requirements laid down in Annex IV.
  2. Qualified certificates for website authentication shall be recognised and accepted in all Member States.
  3. The Commission shall be empowered to adopt delegated acts in accordance with Article 38 concerning the further specification of the requirements laid down in Annex IV.
  4. The Commission may, by means of implementing acts, establish reference numbers of standards for qualified certificates for website authentication. The Commission shall ensure, that stakeholder input is duly considered,preferably in form of an impact assessment, when defining standards to be used for the purpose of this Regulation. Compliance with the requirements laid down in Annex IV shall be presumed where a qualified certificate for website authentication meets those standards. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 39(2). The Commission shall publish those acts in the Official Journal of the European Union.

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

Jak ochránit svou doménu před chybou registrátora a neskončit jako avg.com?

Možná jste zaznamenali útok na doménu známého výrobce antivirového softwaru. Pokud ne, zde je krátké shrnutí.

Před několika dny byl palestinskou hackerskou skupinou KDSM v dopoledních hodinách změněn obsah stránky avg.com a dalších. Na stránce se objevilo politické prohlášení této skupiny, které se vztahovalo k problematice Palestiny a Izraele. Nutno dodat, že poškozených doménových jmen bylo údajně více, dalším z potvrzených je doména jiného antivirového produktu avira.com.

Prohlaseni

Prohlášení na stránce avg.com

Pro nás bezpečáky i pro držitele doménových jmen je však asi nejdůležitější vědět, co se stalo na pozadí a jak se proti takové situaci co nejlépe chránit. Podle dostupných informací se opakovala podobná situace, k jaké došlo v říjnu minulého roku u domény google.ie.

Útočníkům se tedy opět podařilo přes registrátora změnit informace o DNS serverech, na kterých je doména spravována. Na DNS serveru ovládaném útočníky pak již útočníci nasměrovali záznam na své webové stránky, tedy na stránku s již zmiňovaným prohlášením.

Podle prohlášení společnosti Avira se zdá, že v tomto případě buď zafungovalo sociální inženýrství nebo nějak selhala logika aplikace, která je u registrátora Network Solutions používaná při resetování hesel. Doufejme, že se společnost Network Solution k celé věci později vyjádří, abychom si mohli o útoku udělat co nejpřesnější obrázek.

A jak se tedy podobné chybě na straně registrátora bránit? Již v odkazovaném blogpostu o únosu domény google.ie jsem upozorňoval, že pomocí formuláře na našich stránkách je možné požádat o zablokování veškerých změn na konkrétní doméně v registru .cz domén. V té době však bylo možné blokaci i odblokování provést pouze pomocí žádosti s úředně ověřeným podpisem, či pomocí e-mailu podepsaného kvalifikovaným certifikátem. Díky nové službě doménový prohlížeč se však situace velice zjednodušila a samotnou blokaci či odblokování lze provést on-line a to dokonce nad více objekty najednou. Výhodou je, že stačí jednou validovat váš účet služby mojeID a získáte možnost kdykoliv zapnout či vypnout rozšířenou ochranu vaší domény v centrálním registru. Při původní metodě bylo potřeba se pro každou změnu autorizovat zvlášť.

Možnost zablokovat provádění změn na doméně se ve světle množících se útoků na registrátory domén ukazuje jako čím dál důležitější. Nově zavedená možnost provádět tyto změny on-line pomocí služby doménový prohlížeč usnadňuje používání této služby a přímo vybízí k jejímu většímu využívání. Pokud je pro vás vaše doména a její správné fungování důležité, měli byste využití této nově nabízené možnosti co nejdříve zvážit.

Pavel Bašta