Mailová kampaň zneužívající Českou poštu sloužila k šíření nového a velmi nebezpečného malwaru

Nový a velmi efektivní bankovní trojský kůň míří na uživatele v České republice, Portugalsku, Turecku a ve Velké Británii. Pokud jste zaznamenali e-mailovou kampaň, před kterou jsme před časem varovali na našich stránkách Aktuálně z bezpečnosti, pak Vám určitě neuniklo, že tento e-mail, který předstíral, že byl odeslán jménem České pošty, ve skutečnosti vedl ke stažení neznámého malwaru. Nyní se ukazuje, že se jedná o rozsáhlou akci, při které jsou ve čtyřech evropských zemích zneužívány etablované společnosti, jejichž jménem je šířen nový a podle bezpečnostních analytiků velmi sofistikovaný trojský kůň.

Ukazuje se, že Win32/Spy.Hesperbot je velmi silný bankovní trojský kůň s mnoha „užitečnými“ funkcemi, jako je logování zmáčknutých kláves, vytváření screenshotů a nahrávání videa. Dokáže také spustit vzdálenou proxy, vytvořit skrytý VNC server umožňující vzdáleně ovládat infikovaný počítač  a další „vychytávky“. Samozřejmě, jak je u bankovních trojanů obvyklé, dokáže sledovat síťový provoz a za běhu injektovat HTML.

Cílem útočníků je získat přihlašovací údaje do bankovních účtů obětí a zároveň donutit oběti k instalaci dalšího malwaru na jejich Android, Symbian, či Blackberry telefony.

Kampaň šířící tento malware začala v České republice 8. srpna. Rozesílaná zpráva se tvářila jako služba sledování balíku poskytovaná Českou poštou. Útočníci si za tímto účelem pořídili doménu ceskaposta.net, na kterou vedl skutečný odkaz z e-mailu, ve kterém bylo samozřejmě napsáno www.ceskaposta.cz, avšak odkaz směřoval právě na doménu www.ceskaposta.net. Podle informací z blogu společnosti Eset  jdou v České republice počty obětí tohoto nového trojského koně v řádu desítek. Došlo však prý k významným finančním ztrátám v souvislosti s infikováním tímto novým malwarem.

Nakonec ještě připojím tabulku se seznamem českých bank, jejichž klienti jsou zatím terčem útoku tohoto nového viru. Tento seznam byl pořízen na základě analýzy konfiguračních souborů používaných injektovacími a odposlouchávacími moduly nového malwaru.

seznam_bank

Zdroj http://www.welivesecurity.com/2013/09/04/hesperbot-a-new-advanced-banking-trojan-in-the-wild/

Uživatelům, kteří na odkaz z uvedené e-mailové zprávy reagovali, doporučujeme provést důkladnou antivirovou kontrolu a další kroky vedoucí k zabezpečení jejich bankovního konta (změny hesla, PINu) konzultovat s jejich bankovním ústavem.

Pavel Bašta

Proč je opravdu zapotřebí DNSSEC?

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ý

Nové gTLD o další krok blíže, český .UNICORN stále ve hře

V pátek ICANN oznámil tradiční schválení dalších žádostí o nové gTLD. Mezi zpracovanými žádostmi se objevila i jediná doména od českého zájemce: .UNICORN. V procesu počátečního hodnocení (Initial Evaluations) pak zbývá posledních dvacet devět žádostí.

Podle výsledků zveřejněných na stránkách ICANNu prošlo počátečním hodnocením celkem 1760 žádostí, 121 zájemců svoji žádost stáhlo a dvě žádosti (.AFRICA a .GCC) nebyly schváleny. Za povšimnutí stojí, že téměř čtvrtina stažených žádostí se uskutečnila v průběhu července a srpna, tedy na téměř samém konci procesu.

Ani žádosti, které prošly procesem hodnocení, však nemají zatím vyhráno. Více než třetina žádostí totiž obsahuje konflikt s dalšími žadateli – nejvíce zájemců je o doménu .APP, .ART a .HOME (viz. tabulka).


Nejžádanější nové gTLD

Tab_domeny


* Do počtu konfliktů jsou zahrnuty i domény, které jsou stále v hodnocení.

Jediná česká doména .UNICORN se dostala do poměrně malé skupiny žádostí, u které si ICANN vyžádal dodatečné informace, které budou následně postoupeny do tzv. rozšířeného hodnocení (Extended Evaluation). Podle hodnocení zbývá UNICORNu v žádosti upřesnit zejména technické a provozní informace jako je podpora IPv6 či ochrana práv z průmyslového vlastnictví, zejm. majitelů registrovaných ochranných známek.

Při příležitosti (téměř) ukončeného počátečního hodnocení (IE) ICANN zároveň informoval o podpisu dalších 12 smluv se zástupci registrů nových gTLD. Ty se tak zařadí k již stávajícím registrům nových gTLD v IDN: شبكة (arabský výraz pro síť či Internet), онлайн (ruský ekvivalent pro slovo online), сайт (v azbuce webová stránka) a čínský výraz pro hru.

Jiří Průša

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ů.

Blogpost_ZD_1

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ů.

Blogpost_ZD_2

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.

Blogpost_ZD_3

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.

Blogpost_ZD_4

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.

Phishing_v_domene_CZ


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

S ohýbáním rohů v knihách je konec

Náš svět je plný zkratek. A o světě IT to platí dvojnásob. Abyste se v tom „doménovo-technologicko-internetovém“ prostředí vyznali, připravili jsme pro vás knižní záložky, na nichž najdete ty nejčastější zkratky s vysvětlením.

zalozka_2

Jen pro ilustraci vybírám například DNS, PKI, VoIP nebo IPv6 (celkem je jich 32). Po pravdě, nevybral jsem tyto zkratky náhodou. Všechny mají něco společného s Akademií CZ.NIC a s nabízenými kurzy. Právě při návštěvě některého z nich můžete tuto záložku získat a s ní i některou knihu Edice CZ.NIC.

zalozka_3

P.S.: Čtenáři elektronických knih mají bohužel smůlu. Elektronické záložky se zatím nekonají.

Igor Kytka

Honeynet: problematické autonomní systémy se příliš nemění

Po půlroční pauze se pojďme opět podívat na statistiky z našeho honeynetu. A začněme rovnou přehledem největších „hříšníků“ – autonomních systémů, z kterých se k nám útočníci od května do konce července připojovali.

Nejčastější útočníci (květen 2013 – červenec 2013)

Nejčastější útočníci (květen 2013 – červenec 2013)

Tentokrát vede brazilská síť AS28573, která od poloviny července intenzivně šířila tento typ viru Conficker a s více než 30 tisíci uploady mu zajistila první místo v další tabulce zachyceného malware. Tato síť už se v minulosti v našich statistikách objevila a není to vůbec překvapivé, protože podle statistik Shadowserver jí aktuálně patří 12. místo (řazeno podle absolutního počtu IP adres šířících vir Conficker). Infikované je celé 1 % jejího adresního prostoru.

Podobně smutná situace je u tchajwanské sítě AS3462, která se v našich statistikách objevuje taky pravidelně a tentokrát skončila na 6. místě (celosvětově jí patří místo sedmé). Za sledované období se snažila rozšířit 93 různých virů.

Ani třetí v pořadí v naší tabulce není výjimkou. Venezuelská síť AS8048 se snažila šířit 42 virů, z toho čtyři se dostaly i do tabulky deseti nejčetnějších. Tato síť je celosvětově na 29. místě.

Naopak jako výjimky se dají označit polská síť AS196927 a bulharská síť AS42431, které si své umístění zasloužily díky jednotlivcům. V případě polské IP trval útok dva týdny, v případě bulharské osm dní. Osobně mě překvapilo umístění chorvatské akademické sítě AS2108, kde útok trvá s menšími přestávkami stále. Podle zkušeností s naším CESNETem bych očekával rychlejší řešení incidentu.

Pro zajímavost ještě znázornění na mapě, kde je výrazně vidět Brazílie s Polskem. Očekávatelné Rusko zdaleka není tak zajímavé.

Zdroje útoků (květen 2013 - červenec 2013)

Zdroje útoků (květen 2013 – červenec 2013)

V přehledu portů, na které se útočníci připojovali, vede 445 (SMB protokol), výrazně méně připojení pak směřovalo na porty 5060 (SIP), 3306 (databáze MySQL), 1433 (Microsoft SQL Server) a 80 (HTTP).

Cílové porty (květen 2013 - červenec 2013), horizontální osa má logaritmickou škálu

Cílové porty (květen 2013 – červenec 2013), horizontální osa má logaritmickou škálu

V přehledu zachyceného malwaru vedou různé varianty viru Conficker. Platí, že většinou jednu variantu šíří jeden autonomní systém.

Zachycený malware (květen 2013 - červenec 2013)

Zachycený malware (květen 2013 – červenec 2013)

Na našem webovém honeypotu mě vedle běžných hledání skriptu setup.php pro phpMyAdmin (viz CVE-2010-3055) zaujal dotaz na soubor /phppath/php metodou POST s tělem <?php echo "Content-Type:text/html\r\n\r\n";echo "___2pac\n"; ?>. Jedná se o pokus zneužít zranitelnost CVE-2013-4878 v  Parallels Plesk Panel, která byla zveřejněna 5. června. První útok tohoto typu jsme zachytili v sobotu 8. června, tedy jen o 3 dny později. Ukazuje to, že je důležité neodkládat bezpečnostní aktualizace až po víkendu :-).

Jiří Machálek

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!

rodokmen

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.

prodej_fan

 

Poptávka po stránce s více než 50 tisíci fanoušky.

prodej

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

Zajímavý případ od kolegů z polského CERTu

Polský bezpečnostní tým CERT Polska uveřejnil 31. července na svých stránkách http://www.cert.pl zprávu, ve které jeho členové popisují, proč NASK (správce registru národní domény .pl) ukončil spolupráci s jedním z registrátorů domén .pl, společností Domain Silver, Inc.

Tento registrátor, jehož oficiálním sídlem byly Seychelské ostrovy, zahájil svou činnost v květnu roku 2012. Od té doby začal CERT Polska pozorovat velký nárůst škodlivých domén .pl. Většina těchto domén byla zaregistrována právě u tohoto registrátora.

Ze všech registrovaných domén (641, stav k 9. červenci tohoto roku) byla pouze jedna doména neškodná. Tou byla přímo doména tohoto registrátora – domainsilver.pl.

Z celkového počtu 404 domén, které obsahovaly škodlivý kód, bylo 179 domén pod správou C&C serverů. Domény, které byly pod správou některého z botnetů, také tyto botnety nebo škodlivý kód distribuovaly. Jednalo se například o malware nebo botnet Citadel, Dorkbot, ZeuS Ice IX, Andromeda, RunForestRun nebo ransomware. Bližší informace jsou k dispozici na stránkách polského CERT týmu.

V doméně .CZ jsme sice zatím nenarazili na případ, kdy by se na podobné záležitosti přímo specializoval registrátor (a doufejme, že i díky podmínkám pro přijímání registrátorů ani nenarazíme), ale i u nás se sem tam objeví podobné případy nakažených domén, resp. stránek. Není jich ale zdaleka tolik jako jinde. Možná je za tím náš nástroj MDM (Malicious Domain Manager), který používáme pro čištění zóny .CZ. Od spuštění pilotní verze této aplikace uběhly více než dva roky a počet opravených nebo chcete-li vyčištěných domén za tu dobu překročil počet 5000.

Michal Prokop

Weby sdružení v novém kabátě

Dosud nejdéle používaný layout webu sdružení CZ.NIC se téměř po šesti letech dočkal faceliftu. Ten dosavadní byl nasazen u příležitosti migrace na nový systém správy domény .CZ v říjnu roku 2007 a s drobnými úpravami plnil svou funkci až do července 2013.

Spuštění redesignovaného webu je zároveň posledním krokem v procesu změny vizuálního stylu sdružení, která byla zahájena loni na podzim spolu s televizní premiérou první série osvětového seriálu „Jak na Internet“.

Kromě hlavního webu www.nic.cz se změna projeví také na všech ostatních webech používajících jednotný vizuální styl sdružení, jako např. labs.nic.cz, edice.nic.cz, www.dnssec.cz, nebo háčkyčárky.cz. Do konce roku 2013 se nového designu dočká také Blog a stránky Akademie CZ.NIC.

Malá exkurze do minulosti

O prvním webdesignu lze v souvislosti s webem www.nic.cz hovořit od poloviny roku 2001.

Obr_1

Roky 2001 – 2004

Tehdy spuštěný web nahradil webové prezentace do té doby kladoucí důraz především na obsahovou stránku (1998, 1999, 2000).

Faceliftu se dočkal o tři roky později v roce 2004.

Obr_2

Roky 2004 – 2006

K významnému redesignu došlo v polovině roku 2006, kdy stěhování sídla sdružení z Prahy 6 na Vinohrady doprovázela také změna vizuálního stylu a s ní i spuštění zbrusu nového webu.

Obr_3

Roky 2006 – 2007

Zatím předposlední a dosud nejdéle používaný layout byl za téměř šest let svého „života“ svědkem celé řady významných momentů v životě sdružení, počínaje úspěšnou migrací na vlastní systém pro správu domén, přes podepsání zóny .cz DNSSEC, spuštění autentizační služby mojeID, až po registraci milionté domény .cz a dvě letošní významná výročí.

Obr_4

Roky 2007 – 2013

Ondřej Písek