Hovorí sa, že zdieľaná radosť je dvojnásobná radosť. Rovnako rastie zdieľaním užitočnosť dát z honeypot systémov. Vďaka projektu hpfriends, súčasti The Honeynet Project, je zdieľanie týchto dát veľmi jednoduché a podnecuje k ďalšiemu využívaniu. My sme vďaka tomuto projektu vizualizovali útoky na náš honeynet. V tomto článku sa môžete pozrieť na našu skúsenosť so zapojením do hpfriends.
Naša honeymapa
Systém hpfriends je evolúciou staršieho hpfeeds. Cieľom projektu je umožniť používateľom jednoducho rozhodovať o právach k odoberaniu ich udalostí. Podľa nich potom systém zaslané udalosti distribuuje na základe autentifikačných údajov k ďalšiemu spracovaniu.
Podrobný návod na použitie spísal Johannes ‚heipei‘ Gilger. V skratke – dá sa prihlásiť pomocou GitHubu, Googlu, alebo Facebooku. Užívateľ si vygeneruje svoj (jeden alebo niekoľko) autentifikačný kľúč a nastaví, do ktorých kanálov môže publikovať a ktoré môže odoberať (Sub). Potom v honeypote na jednej strane, alebo v software, ktorý spracováva prijate udalosti na druhej strane, použije tento kľúč.
Dá sa nastaviť zdieľanie kľúča s iným používateľom alebo skupinou. Tieto vzťahy sú uložené v grafovej databáze Neo4j. Viac o implementačných detailoch nájdete tu.
Hpfeeds vytvoril Mark ‚rep‘ Schloesser, sú dostupné implementácie v go, a ruby. Zdrojové kódy hpfriends nie sú verejné.
Kód v Pythone na publikovanie udalostí je veľmi jednoduchý:
import hpfeeds
import json
import sys
try:
hpc = hpfeeds.new('hpfriends.honeycloud.net', 20000, "ident", "secret")
print("Connected to {0}".format(hpc.brokername))
channels = ["artillery", ]
data = {"local_host": "168.192.1.1", "connection_protocol": "smbd",
"remote_port": 2714, "local_port": 445, remote_host": "168.192.1.2"}
hpc.publish(channels, json.dumps(data))
except:
print format(sys.exc_info())
hpc.close()
Na odoberanie udalostí používame feed.py z redmine na honeynet.org :
python ./feed.py --host hpfriends.honeycloud.net -p 20000 -c test -c dionaea.capture -i ident -s secret subscribe
Ak niečo nefunguje, najskôr sa treba pozrieť do logu na hpfriends, či kľúču nechýbajú práva.
Príkladom použitia je Honeymap. Žlté bodky na mape sú mestá so senzormi, červené sú zdroje útokov. Čím viac útokov pochádza z danej krajiny, tým je krajina viac modrá. V logu v dolnej časti stránky vidno informácie o real-time útokoch (čas, zdroj, cieľ, ich súradnice, typ senzoru, pri type dionaea.capture je uvedený aj MD5 hash súboru, ktorý použil útočník spolu s linkom na virustotal.com).
Naše senzory v Prahe sú tiež pridané do mapy, ale mapa nezobrazuje všetky udalosti z nich. Mapu udalostí len z našich senzorov nájdete tu. Databázy geolokácie nie sú nejak obzvlášť presné, tak máme Prahu nastavenú ako cieľ ručne. Inak by bol cieľ v strede republiky.
Ďalšie mapy:
– Nemecký Telekom
– Luxemburský CIRC (Computer Incident Response Center)
S hpfeeds komunikujú všetky naše honeypoty (Dionaea, Kippo, Glastopf, Artillery, Conpot). Počas tohtoročného Google Summer of Code sa podpora hpfeeds dostala aj do spampotu SHIVA. Viac na blogu.
Za zmienku stojí blogpost od Marka Schloessera, kde vysvetľuje základné otázky, ako „Odkiaľ sa berú dáta?“, „Sú dáta reprezentatívne?“, „Prečo sa zdá, že celý svet útočí na Aachen?“.
Z vlastnej skúsenosti môžeme povedať, že zapojenie so hpfriends je jednoduché. Napadá vás ďalšie zaujímave využitie živých dát okrem vizualizácie? Napíšte nám do komentárov.
Katarína Ďurechová, Jiří Machálek
E-Business Forum 2013: Máte jistotu, že neprodáváte alkohol dětem?
Obecně je rozlišována věková hranice pro nákup a konzumaci alkoholu. V některých státech světa najdeme odlišnosti od nejčastější hranice, tj. 18ti let. Zákonnou úpravu představuje zákon č. 379/2005 Sb., o opatřeních k ochraně před škodami působenými tabákovými výrobky, alkoholem a jinými návykovými látkami.
Často se setkáváme v médiích s výsledky namátkových kontrol prodeje alkoholu nezletilým v kamenných prodejnách a restauracích. Zde je ale kontrola velice snadná. Prodávající je schopen vizuálně posoudit věk nakupujícího, případně si vyžádat doklad s uvedeným datem narození.
Ale jak je tomu v případě elektronických obchodů? V loňském roce provedl dTest průzkum u 22 eshopů prodávajících alkohol. Pouze ve dvou případech neshledal závadu! Naprostá většina eshopů nabízejících alkohol nekontroluje, kdo je kupující! Obchody se většinou spokojí pouze s tím, že kupující na dotaz, zda je plnoletý, odpoví, že ano. Podle zákona je zakázán zásilkový prodej a veškeré další formy prodeje, při kterých není možno ověřit věk kupujícího. Prohlášení o plnoletosti není kontrola data narození, je tedy nevyhovující.
Řešení jsou v zásadě dvě. Prvním je dodání zboží kurýrní službou zajišťující ověření věku nebo osobní odběr zboží. Tento způsob je pro provozovatele nákladný a pravděpodobně i s vysokým procentem vrácených zásilek.
Lze to ale zajistit i jinak. Prostřednictvím služby mojeID může dojít k ověření věku hned při přihlášení do eshopu nebo následně při odeslání objednávky. Pokud neumožníme nezletilému nakoupit, nevznikají pak další náklady na doručení zboží, ani zátěž logistických procesů. Je vysoká pravděpodobnost, že zásilka bude doručena.
V současné době připravujeme rozšíření našim OS modulů a partnerských komerčních řešení o podporu kontroly zletilosti. Díky tomu naše služba mojeID může přispět k zlepšení situace při zásilkovém prodeji alkoholu dětem.
Původní prezentace na toto téma zazněla na letošní konferenci E-Business Forum.
Radim Ponert
Doménový prohlížeč – vaše okno do registru domén
Minulý týden jsme představili novou službu nazvanou Doménový prohlížeč. Formát tiskové zprávy, kterou jsme k tomu vydali, pochopitelně neumožňuje příliš se rozpovídat o vlastnostech této služby. Proto bychom rádi tiskovou zprávu doplnili tímto blogpostem, ve kterém Doménový prohlížeč popíši trochu podrobněji. Funkce této služby bych rozdělil na tři části. První část tvoří osobní WHOIS, druhou částí je editor údajů kontaktu souvisejících s registrem a třetí částí jsou bezpečnostní zámky na objektech v registru.
Doménový prohlížeč jako osobní WHOIS
Služba WHOIS je standardní součástí snad všech doménových registrů a v našem podání umožňuje veřejnosti nahlédnout do údajů o doménách, kontaktech, sadách jmenných serverů a sadách DNSSEC klíčů, které v registru evidujeme. Chce-li nějaký držitel zobrazit seznam všech svých domén, musí se obvykle přihlásit do systému svého registrátora a tam své domény uvidí. Situace se ale komplikuje, pokud z nějakého důvodu jsou domény zaregistrovány přes více registrátorů. A tady právě může pomoci Doménový prohlížeč.
K vyřešení problému je ale nutné jednoznačně identifikovat a autentizovat příslušný kontakt držitele v doménovém registru. Tuto možnost jsme v registru dlouho neměli. Nyní ale máme mojeID, jehož podstatnou vlastností je jeho propojení s doménovým registrem. MojeID tak vlastně kontaktům v registru přiřazuje autentizační údaje. Bez mojeID by tedy Doménový prohlížeč nemohl fungovat. Díky tomuto propojení můžeme uživateli zobrazit nejen všechny domény, kde je držitelem, ale také domény, kde je administrativním kontaktem, nebo sady jmenných serverů a sady klíčů, kde je technickým kontaktem. Další důležitou vlastností Doménového prohlížeče je, že u těchto sad jmenných serverů a sad klíčů si jejich správce může zobrazit všechny domény, které na ně jsou navázány a například pomocí toho ověřit, zda má správně nakonfigurované své jmenné servery. V seznamu domén hraje klíčovou roli sloupeček „Následující stav“, podle kterého jsou domény standardně setříděny a který ukazuje, co se v nejbližší době stane s doménami. Díky tomu je možné na první pohled vidět, které domény vyžadují držitelovu pozornost, protože mohou být deaktivovány nebo dokonce zrušeny.
Z uživatelského pohledu aplikace obsahuje standardní sadu ovládacích prvků. Seznamy objektů je možné libovolně třídit, stránkovat s volitelným počtem objektů na stránku a filtrovat přes zvolený podřetězec v názvu objektu. Pokud uživatel požaduje zobrazení velkého množství objektů, standardně se jich zobrazí jenom prvních několik tisíc. Pokud chce držitel získat všechny objekty, musí použít funkci exportu do CSV formátu, což je textový tabulkový formát. V rámci implementace uživatelského prostředí jsme se snažili o dodržení techniky „responsive design“, a tak by neměl být problém používat Doménový prohlížeč na tabletech a chytrých telefonech.
Doménový prohlížeč jako editor kontaktu
Spuštěním služby mojeID jsme se stali de-facto registrátorem některých kontaktů v doménovém registru a proto jsme v editoru profilu mojeID museli nabídnout plnou funkcionalitu, kterou každý registrátor u kontaktu umožňuje. Kromě přirozené správy osobních údajů to je také možnost změnit si heslo pro převod kontaktu k jinému registrátorovi (tzv. auth info) a možnost nastavit si příznaky zveřejňování údajů kontaktu ve službě WHOIS. Vzhledem k tomu, že mojeID po startu získalo mnohem větší popularitu mezi uživateli, kteří nejsou zároveň držitelé domén, setkávali jsme se často se složitým vysvětlováním, k čemu jsou tyto údaje dobré a proč je mají nastavovat. Rozhodli jsme se nakonec tuto situaci řešit odebráním těchto údajů z editoru profilu mojeID a vložili jsme je právě do doménového prohlížeče. Ten je primárně určen pro uživatele, kteří mají vztah k doménovému registru a význam těchto údajů znají. V záložce „Můj kontakt“ tedy uživatelé najdou kromě zobrazení údajů kontaktu také možnost zobrazit nebo změnit tyto dvě skupiny údajů. Změna hesla pro převod kontaktu má přirozeně smysl pouze pokud by uživatel již nechtěl mojeID používat a rozhodl se přejít znovu k jinému registrátorovi. Je zde jedno podstatné omezení, které ale platilo i v editoru profilu mojeID. Tyto údaje může měnit pouze uživatel, který je plně ověřen zasláním dopisu na jeho adresu. Pokud uživatel požaduje změnu i ostatních údajů, dostane se jednoduše přes tlačítko „Upravit osobní údaje“ do editoru profilu mojeID a tam může změnu provést.
Doménový prohlížeč jako rozhraní k blokacím a ke zjištění hesla pro převod objektů
Přestože primárním místem pro řešení problémů s doménami jsou registrátoři, vždy existovali požadavky, se kterými bylo nutné se obrátit přímo na nás jako správce doménového registru. Prvním problémem, který s námi držitelé domén řeší, je převod domény k jinému registrátorovi. K jeho provedení je nutné znát heslo, které by mělo být možné zjistit z rozhraní stávajícího registrátora. Je ale možné, že stávající registrátor se bude chtít odchodu zákazníka bránit a toto heslo držiteli neprozradí. V takovém případě se pak vždy mohl držitel obrátit na nás a my jsme mu heslo poskytli. Druhým typem žádosti, a zároveň jednou z prvních změn, které jsme v roce 2007 při spuštění domového registru implementovali na žádost uživatelů, je zablokování domén proti změnám. Přestože registrátoři mají v podmínkách uvedeno, že změny u domén mohou dělat pouze se souhlasem držitele nebo administrativního kontaktu, může dojít k porušení tohoto pravidla. Nemusí se jednat vyloženě o zlý úmysl registrátora, například může být jeho systém napaden. Proto jsme v doménového registru umožnili držitelům domén požádat buď o zablokování převodu k jinému registrátorovi nebo o zablokování všech změn nad doménou. Tato žádost je opět zasílána přímo k nám do registru a nikoliv prostřednictvím registrátora.
Pro řešení těchto problémů máme na našich webových stránkách formulář, kde je možné žádost vyplnit a zaslat. Pro její zpracování je ale nutné přirozeně odesílatele žádosti nějak autentizovat. K tomu jsme vždy používali dvě možnosti a to buď opatření žádosti notářsky ověřeným podpisem a její zaslání v papírové podobě, nebo zaslání žádosti emailem podepsaným digitálním podpisem. A zde opět přichází na scénu výhoda propojení mojeID a doménového registru. Kromě autentizačních údajů, pomocí kterých se může držitel vůči nám identifikovat a o kterých jsem psal výše, obsahuje služba mojeID také kontrolu údajů na srovnatelné úrovni jakou poskytne notář nebo certifikační autorita. Pokud tedy držitel splňuje podmínku nejvyššího stupně ověření, není důvod nutit ho k složitému ověřování znovu při každé žádosti přes webový formulář. Proto jsme do Doménového prohlížeče vložili takto ověřeným uživatelům i možnost provádět tyto žádosti online. Blokováni a odblokání domén je dokonce možné provádět hromadně nad více objekty.
Budoucnost
Doménový prohlížeč vnímáme jako rozhraní držitelů domén k doménovému registru a tato skutečnost nabízí velký potenciál pro jeho rozšiřování do budoucna. Rád bych zmínil některé myšlenky, které nás při těchto úvahách napadají:
- Zobrazování historie objektů – Pravidla registrace již nějaký čas umožňují oprávněným žadatelům zobrazit historii nějaké domény. Doménový prohlížeč by se tedy mohl rozšířit o historická data.
- Zobrazování komunikace s uživatelem – V průběhu života domény zasíláme držiteli spoustu informací, např. pokud si vyplní email pro notifikaci je zasílána informace o každé změně, nebo kontaktujeme držitele v případě významné změny stavu (expirace domény, deaktivace domény, atd..). Někdy posíláme email, někdy dokonce dopis. Občas naše klientské centrum řeší dotazy, zda byl email nebo dopis odeslán a kdy. Zde by každý uživatel mohl mít přehledně seznam komunikace zobrazen.
- Slučování kontaktů – Může nastat situace kdy uživatel má několik kontaktů u různých registrátorů a tak není možné je jednoduše sloučit automaticky. V doménovém prohlížeči by mohl být přehled kontaktů v registru se stejnými údaji a možnost přepojení všech domén navázaných na tyto duplicitní kontakty na kontakt, pod kterým je uživatel přihlášen. To by vyřešilo i palčivý problém některých držitelů domén, kteří nemohou svůj kontakt převést do mojeID z důvodu formátu identifikátoru kontaktu. Takto by si založili kontakt nový se stejnými údaji a poté si na něj jednoduše převedli.
Toto je jen malý výtah z toho co by se dalo dělat. Rádi bychom do diskuze o požadovaných vlastnostech zapojili i komunitu a proto nám prosím, dejte vědět, pokud máte nějaké vlastní nápady případně který z navrhovaných bodů se vám nejvíce líbí a měli bychom ho zvažovat přednostně. Budeme rádi za jakékoliv podněty, které se v komentářích objeví.
Jaromír Talíř
IPv6 postupuje
Jak vypadá situace adopce protokolu IPv6 z hlediska alokací jsem na tomto blogu již glosoval mnohokrát. Dnes mi dovolte připomenutí překročení jednoho milníku z pohledu reálných IPv6 toků Internetu. Google totiž nedávno oznámil, že podíl IPv6 překročil 2 %. To sice nezní jako nějaké ohromující číslo, ale na druhou stranu se podíl IPv6 meziročně více než zdvojnásobil, protože loni v této době byl tento poměr nižší než 1 %. Trend tedy vypadá velmi pozitivně, což je vidět i z následující křivky.
Podíl IPv6 22.9.2013
Dále je potřeba si uvědomit, že díky technikám jako happy eyeball poměr IPv6 nikdy nemůže být 100% ani v případě plné implementace IPv6.
Situace se pochopitelně výrazně liší v jednotlivých zemích. Světovou jedničkou je Švýcarsko s 9 %. Druhé místo obsadilo trochu nečekaně Rumunsko s o něco méně než 8 % a třetí je Francie s 5 %. Česká republika, která má poměrně hodně obsahu přístupného po IPv6, bohužel za průměrem zaostává. U nás se podíl IPv6 pomalu blíží k 1,5 %. To je pochopitelně způsobeno situací u ISP, kteří se k nasazování IPv6 pro koncové uživatele zatím tolik nehrnou, byť toto rozhodně neplatí pro všechny.
Každopádně bude zajímavé sledovat, zdali si IPv6 udrží takto pozitivní růstový trend. Pokud by tomu tak bylo, mohli bychom IPv4 opustit poměrně brzy.
Ondřej Filip
Fotoblogpost: Už brzy
Okřídlené »obraz vydá za tisíc slov« platí v tomto případě 100%. Řadě z vás jistě není třeba cokoliv přibližovat.
Prostě už brzy tu bude pokračování úspěšného seriálu Jak na Internet.
Vydržte ještě pár dní; fotky níže slouží pouze jako ochutnávka. Zůstaňte s námi a dozvíte se víc (tento slogan trochu klame :)). Těšte se s námi na 1. říjen!
Klapka POPRVÉ!
Klapka PODRUHÉ!
Klapka POTŘETÍ!
Tomasz Hatlapa
Crimeware Zeus: funkce a použití (seriál, 2. díl)
V minulém úvodu, kde jsme si řekli, jak je crimeware používán a jak na sebe jednotlivé „specializace“ v rámci kyberzločinu mohou navazovat, jsem slíbil, že si ukážeme, jak jeden z těchto programů, konkrétně trojský kůň Zeus funguje.
Zeus spadá mezi crimeware s nejasnou definicí, někdo jej považuje za trojského koně, protože na počítači oběti získává citlivá data pro útočníka, někdo o něm zase hovoří jako o botnetu, protože útočník může napadené počítače na dálku ovládat a zároveň využívá řídící server, který k tomuto ovládání používá. Možná je to postupným vývojem, kdy původně sloužil Zeus především jako Keylogger, což však způsobovalo útočníkům problémy u bankovních aplikací používajících další autorizační mechanismus, například kód zaslaný pomocí SMS. Proto se postupně vyvinul až do dnešní podoby, kdy umožňuje za běhu měnit data posílaná do banky a data zobrazovaná uživateli. Útočník tak může za běhu měnit obsah a vzhled stránek, které se uživateli zobrazí. Ať tak či onak, množství počítačů napadených jen tímto softwarem dosahuje miliónů. Proto je důležité vědět, jak celý proces funguje a jak, poměrně jednoduše, se mohou uživatelé nejen této hrozbě bránit.
Z čeho se tedy Zeus skládá? Je to především webové rozhraní, přes které může útočník napadené počítače ovládat. V tomto webovém rozhraní může útočník sledovat informace o napadených počítačích a především jim může posílat další příkazy.
Webové rozhraní pro ovládání botnetu
Útočník si samozřejmě může napadené počítače různě filtrovat, například podle země, aktuálního stavu(on-line, offline), či třeba dle toho, zda je počítač za NATem.
Za zmínku stojí i nastavování skriptů, které si následně jednotlivé nakažené počítače na útočníkově řídícím serveru vyzvednou a vykonají. Útočník tak může nechat nahrát a spustit na počítači nějaký soubor, nechat si nahrát všechny certifikáty uložené v daném PC na jeho server, blokovat konkrétní URL (třeba stránky výrobců antivirů) či třeba vypnout počítač.
Nastavování skriptu, příkazů umí Zeus vykonat pro svého pána podstatně více
Kromě tohoto webového rozhraní, kterým celý botnet ovládá, však útočník také musí vytvořit samotný soubor, obsahující trojského koně. Ani toto není nic složitého. Před vygenerováním spustitelného souboru, který obsahuje trojského koně si útočník musí pouze nastavit několik statických informací, jako například, kde je jeho řídící server, jméno botnetu, do kterého bude vytvořený bot spadat, časový interval pro stahování konfiguračního souboru z C&C serveru, či šifrovací klíč.
Konfigurační soubor pro nově vytvářeného bota
Při vytváření již také může být zahrnut soubor s předpřipravenými HTML injekcemi pro jednotlivé banky. Na následujícím obrázku tak můžete vidět zvýrazněnou část kódu, která vloží do přihlašovací stránky internetového bankovnictví formulářové pole dožadující se zadání PINu platební karty.
Soubor WebInjects obsahuje velké množství předdefinovaných útoků na nejrůznější banky
Mimochodem, i psaním těchto „HTML injekcí“ se někteří „programátoři“ živí. Na ruském fóru prologic.su můžete narazit na následující pěkný inzerát. Pro ty z nás, kteří již ve škole neměli azbuku – jedná se o nabídku již hotových „injekcí“, případně možnost nechat si napsat vlastní na míru.
Tato starší nabídka z ruského fóra je prostě neodolatelná…
Pak už stačí útočníkovi pouze spustit aplikaci, která na základě těchto konfiguračních souborů vytvoří nový soubor s tímto nebezpečným kódem.
Aplikace pro generování souborů obsahujících malware Zeus
V adresáři aplikace se pak objeví nový exe soubor.
Nově vzniklý bot.exe
Nyní má útočník k dispozici soubor, který po spuštění na počítači oběti infikuje systém, na kterém se tak definitivně Zeus uhnízdí. Jak jej však dostane na počítač oběti? V podstatě má dvě možnosti. Buď využije nějaké formy sociálního inženýrství a své oběti nějak přesvědčí, aby si soubor nainstalovaly samy. K tomu většinou využije hromadně rozeslanou nevyžádanou zprávu a pak už jen ve webovém rozhraní sleduje, kolik lidí že se zase nechalo nachytat, a nebo hůře, použije další crimeware, s přiléhavým názvem blackhole. A o něm bude můj příští a závěrečný blogpost.
Slovníček pojmů:
Crimeware: škodlivý software vyvíjený specificky za účelem automatizace kybernetické kriminality
Trojský kůň (trojan): program umožňující útočníkovi získat kontrolu nad napadeným počítačem, např. získávat uložená hesla, osobní dokumenty, mazat soubory atd.
Botnet: síť počítačů infikovaných speciálním software, tato síť je centrálně řízena z jednoho centra
Bot: v kybernetické bezpečnosti obvykle jeden člen botnetu, jednotlivý boti tvoří dohromady botnet.
Řídící server botnetu: anglicky command-and-control server (C&C), je centrálním uzlem botnetu, přes který jej jeho majitel ovládá
Keylogger: software zaznamenávající stisky jednotlivých kláves, například do souboru, kde si je pak může přečíst útočník
HTML injekce: anglicky HTML Injection, vkládání vlastního obsahu do existující webové stránky, obvykle bez vědomí uživatele.
Sociální inženýrství: manipulativní techniky používané za účelem získání určité informace, či vynucení určité akce.
Pave Bašta
K čemu slouží crimeware (seriál, 1. díl)
V jednom z mých předchozích blogpostů jsem popisoval, proč má někdo zájem nečestným způsobem získávat „lajky“ pro svou facebookovou stránku. V tomto mini seriálu, bych chtěl na tento článek nepřímo navázat a opět názorně zodpovědět jiné běžné otázky uživatelů typu: proč bych měl dodržovat všechna ta otravná bezpečnostní pravidla, jak by se někdo dostal zrovna do mého počítače a proč by to dělal.“
Předně je potřeba říci, že počítačová kriminalita je dnes velmi dobře organizována. Slyšeli jste někdy pojem „crimeware“? Jedná se o softwarové nástroje, speciálně určené pro počítačové zločince, které jim usnadňují jejich útoky a umožňují jejich efektivní provádění. Autoři tohoto „speciálního“ softwaru s ním obchodují na k tomu určených fórech. Zajímavé je, že i tyto aplikace se rozdělují dle své funkce a dle toho se pak dělí také „živnost“ kriminálníků, kteří je používají.
Abych to lépe vysvětlil, jedním z nejznámějších nástrojů pro získávání přístupu do cizích počítačů pomocí zranitelností souvisejících s prohlížením webových stránek, je nástroj Blackhole. Ten umožňuje vygenerovat speciální stránku, která, pokud ji navštívíte, okamžitě začne zkoušet všechny možné zranitelnosti ve vašem počítači. Zkouší útočit na webový prohlížeč, jeho rozšíření jako je Flashplayer, ale třeba také na Acrobat Reader. Pokud tedy některá z těchto komponent není pravidelně aktualizována, je na malér zaděláno. Možná si teď říkáte, jak vás někdo naláká na nějaký pochybný web. Proto také tito kriminálníci většinou vkládají tuto svou stránku do cizích stránek s pomocí techniky rámů. Na tyto stránky předtím získali díky jinému nástroji neoprávněně přístup. Takovou stránkou může být váš oblíbený vyhledávač, e-shop, blog či jakákoliv jiná stránka. Ovšem skutečně zajímavé je, že toto propojení mohou tito útočníci také nakoupit jako službu od jiné kriminální skupiny, která se právě na získávání přístupů na cizí weby specializuje.
Takže teď tu máme dvě zajímavé oblasti pro „podnikání“ v počítačové kriminalitě. To ale není vše, existují další nástroje, které jsou zaměřeny na další využití jednou ovládnutých počítačů. Pod názvem Silence Of winLocker můžete na ruských fórech již delší dobu zakoupit nástroj pro generování policejního ransomware. Pro šíření tohoto ransomware si pak útočníci mohou pronajmout právě síť vzniklou na základě útoku pomocí Blackhole. Dalším příkladem crimeware je Zeus, známý bankovní trojan, který opět může využít Blackholem dříve ovládnuté počítače a uživatele těchto počítačů okrást o peníze, či třeba o jejich přístupové údaje k různým službám. Zeus je stále hojně používán, jak se můžete přesvědčit na této adrese.
Aktuální mapa rozmístění řídících serverů Zeusu (Zdroj:https://zeustracker.abuse.ch/)
Všimněte si prosím, že už se jedná v podstatě o malý kriminální ekosystém, provozovatel Blackhole kitu nakupuje od jiné skupiny prostor na touto skupinou ovládnutých webových stránkách, které zneužívá k napadání počítačů domácích i firemních uživatelů. Přístup do těchto počítačů, který takto získá, pak může prodat další skupině, která operuje třeba nástrojem Zeus, či jiným. A samozřejmě nesmíme zapomínat na tvůrce těchto nástrojů, tedy programátory, kteří tyto aplikace vyvíjejí a prodávají dalším skupinám. Aby to však nebylo jen teoretické povídání, slibuji, že se v dalších dvou dílech podrobněji podíváme právě na Blackhole a Zeus.
Slovníček pojmů:
Crimeware: škodlivý software vyvíjený specificky za účelem automatizace kybernetické kriminality
Zranitelnost: slabé místo zneužitelné pro narušení bezpečnosti. Může se jednat například o chybu konfigurace, či chybu v programu.
Trojský kůň (Trojan): program umožňující útočníkovi získat kontrolu nad napadeným počítačem, např. získávat uložená hesla, osobní dokumenty, mazat soubory atd.
Rámy: umožňují rozdělit stránku do dvou nebo více obdélníkových oblastí (rámů), do kterých se načítají jiné stránky
Policejní Ransomware: škodlivý software, který blokuje přístup k funkcím počítače a uživatele vydírá smyšleným obviněním (například z držení dětské pornografie, či nelegálních kopií filmů). Za odblokování počítače požaduje zaplacení údajné pokuty, ve skutečnosti však peníze putují do kapes podvodníků.
Pavel Bašta
Uhodnutí hesla díky Facebooku je mnohem jednodušší, než se zdá
Je to stále stejná písnička. Každý rok publikují zpravodajské servery žebříčky nejpoužívanějších hesel. V anglických verzích vede „password“ či podobně nápadité „123456“. V rámci nejnovější studie Googlu, jejíž výsledky přinesl prestižní časopis TIME, patří mezi nejoblíbenější hesla jména zvířecích miláčků, snadno zapamatovatelná data (např. datum svatby či narozeniny členů rodiny) nebo rodná příjmení a jména blízkých příbuzných.
V této souvislosti studie připomíná, že mnoho z těchto údajů lze najít na sociálních sítích, zejména Facebooku. Například datum svatby se většině uživatelů zobrazuje na veřejné části profilu. Podobné je to i se jmény příbuzných či čtyř (případně i více :o) nohých mazlíčků. Z průzkumu rovněž vyplynulo, že 48 % uživatelů sdílí svá hesla s někým jiným a 3 % si hesla píší na žluté postity, které nechávají v blízkosti počítače (např. zadní straně klávesnice).
Podle nedávného průzkumu Univerzity Palackého v Olomouci se však zdá, že čeští uživatelé jsou poučenější a od roku 2009 se situace značně zlepšila. Snad k této situaci přispěl i jeden z dílů našeho seriálu „Jak na Internet“. Podle studie olomoucké univerzity by totiž z 3749 zkoumaných hesel bylo jen 6,9 % možné odhalit pomocí slovníku a heslo „12345“ využíval pouze jeden uživatel. U mladých Čechů pak mezi nejoblíbenější hesla patří jméno města (tj. opět věc, kterou je u většiny uživatelů možné najít na Facebooku), křestní jméno a slova „slunicko“, „maminka“ a „lokomotiva“.
V rámci kurzů základů počítačů, které připravuji pro skutečně začínající uživatele Internetu, připodobňuji heslo k zámku na dveřích jejich obydlí či skříně. Zdá se, že zatímco většina z nás si své klíče od domu či auta chrání, je mezi námi stále mnoho těch, kteří si neuvědomují, jak cenný klíč počítačová hesla představují.
Jiří Průša
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.
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ý