Hlavní navigace

Kradení hesel z eduroamu, řešení phishingu a ochrana soukromí v DNS

Petr Krčmář

Proč vám můžou při špatné konfiguraci připojení k síti eduroam uniknout přihlašovací údaje? Jak má vypadat dostatečně bezpečné heslo? Co má správce dělat při detekci phishingu? Nejen o tom se mluvilo na BSS19.

Doba čtení: 11 minut

Sdílet

Poslední lednový den proběhl Seminář o bezpečnosti sítí a služeb pořádaný sdružením CESNET. Hovořilo se o aktuálních bezpečnostních problémech, hrozbách a technologiích k jejich řešení. O jednom z tématu jsme vydali samostatný článek, zbytek zápisků z toho nejpodstatnějšího, co na semináři zaznělo, se dočtete v tomto textu.

Jan Tomášek: Obrana proti krádeži eduroam identity

Federační síť eduroam při autentizaci navazuje TLS spojení a používá protokol MSCHAPv2. Základem je challenge-response autentizace, heslo není přenášeno v čitelné podobě. Je to pěkně vymyšlené, ale je tam několik chyb, které snižují entropii.

Ukrást přihlašovací údaje tak není problém, stačí k tomu malý čínský router používající OpenWRT. AP se připojuje na upravený RADIUS server, který se představí nevalidním certifikátem a špatně nastavený klient jej přijme a autentizuje se. Pomocí slovníkového útoku je pak možné odhalit uživatelské heslo. Slabé heslo nebo jen číselné heslo je k ničemu, prolomit ho trvá pár sekund.

Jan Tomášek je správcem národního RADIUS serveru a provádí podobné penetrační testy. Z několika tisíc pokusů o ukradení účtů zjistil, že jen 14 % zařízení je nastaveno správně. Průměrná délka hesla je 10 znaků, nejdelší odhalené mělo 24 znaků a nejkratší jen 4. Není to vůbec dobré, ale čekal jsem to ještě horší.

Problém je v samotných platformách, které ve výchozím stavu prozradí heslo komukoliv. Nejtragičtější jsou Linux a Android, s těmi je nejvíce problémů. Ověření probíhá tak, že se klient představí místnímu přístupovému bodu, prozradí svou domovskou instituci a sestaví TLS tunel proti RADIUS serveru.

Jedinou ochranou je kontrola použitých certifikátů, aby byl klient ochoten komunikovat jen s oprávněným RADIUS serverem. To je možné provést manuálně: stáhnout a nainstalovat certifikát CA RADIUS, kontrolovat hostname nebo alespoň doménu a nastavit autentizační metodu na MSCHAPv2. Když přijdete někam, kde se nemůžete přihlásit, rozhodně nevypínejte ověřování certifikátů.

Lepší je použít automatickou konfiguraci na cat.eduroam.org, kde jsou nástroje pro automatickou konfiguraci mnoha různých platforem. Po instalaci uživatel vybere svou instituci, vyplní přihlašovací údaje a vše se samo nastaví. Velmi rychle se tak připojíte bezpečně. Nástroj CAT je k dispozici pro 85 institucí, ale další zatím do systému nejsou zaregistrované nebo neposlaly konfiguraci.


Autor: CESNET

Jan Tomášek

Ukradení identity může pro uživatele znamenat, že se za něj bude někdo vydávat a může skrze akademickou síť pod jeho jménem páchat trestnou činnost. Může to skončit trestním oznámením a pro vás bude ten výslech velmi nepříjemnou zkušeností. Někteří uživatelé také používají stejné heslo k různým službám, takže únik identity z eduroamu může vést k mnohem větším škodám.

Michal Kostěnec: Hesla

Hesla jsou v poslední době hodně diskutované téma, ani odborníci se často neshodnou na tom, jak by se mělo k heslům vlastně přistupovat. Michal Kostěnec se na své přednášce hesly zabýval z pohledu penetračního testera. Během penetračních testů obvykle vystupujeme jako běžní internetoví útočníci a potřebujeme nejprve posbírat informace.

Nejprve je potřeba získat uživatelská jména, na která se bude útočit. Použít je možno firemní webové stránky, vyhledávače či třeba sociální sítě. Pak se snažíme dostat k osobním údajům o uživatelích: jména, rodná čísla, jména dětí a podobně. Řeknete si, že tohle se na internetu nepovaluje, ale na sociálních sítích najdete často hodně informací.

Důležitým zdrojem informací jsou dokumenty s politikou hesel. Organizace často zveřejňují informace o tom, jak mají vypadat hesla: kolik mají mít znaků, jestli tam musí být číslo a podobně.

Statistiky ukazují, že ve 40 % případů mají hesla první písmeno velké či mají jako poslední znak číslici. Dvě číslice na konci má 25 % hesel a nejčastějším kořenem hesla jsou slova: heslo, martin, jana, tereza, eliska. Hesla se čtyřmi číslicemi na konci obvykle obsahují: 1234, 2015, 1994, 2016 a 1993. Takhle si uděláme přípravku, abychom mohli začít efektivně hesla hádat.

Poté je potřeba najít aplikaci, ve které je možné heslo použít. LDAP, webové aplikace, IMAP, SMTP, VPN, SSH a další. Služby mají často limit na počet pokusů a čas, takže je nutné hádat velmi pomalu. Přinejlepším to budou stovky hesel za sekundu, což je pro slovníkový útok hodně málo.

Pokud se podaří do organizace dostat, pokusí se penetrační testeři ukrást haše hesel a poté je v offline útoku prolomit. Mají k dispozici 7GB soubor s hesly, ve kterém je přibližně miliarda slov. Na slovník se pak použijí různá pravidla pro změnu velikosti, čísla na konci, l33t, kombinaci slov a podobně. Slovník se tím ještě dále zvětší, takže by jeho projití trvalo příliš dlouho. Použijeme pak masku, kterou popíšeme obecný tvar hádaného hesla. Tím prostor efektivně zmenšíme, protože hesla jsou si obvykle docela podobná.

K samotnému crackování hrubou silou se pak dnes nejčastěji používají grafické karty, které jsou výrazně výkonnější než CPU. Důležité je, že výpočet můžeme paralelizovat a počítat na více kartách. Forenzní laboratoř sdružení CESNET má k dispozici nový server s osmi výkonnými grafickými kartami.

Tradičním nešvarem je opakované použití hesel na více službách. Pokud je uživatel ve stejné organizaci zároveň administrátorem, často má druhý účet s předponou adm-, u kterého má ale stejné heslo. Testeři se často setkávají také s minimálními úpravami hesla pro různé služby, například: Sup3rh3slo.Windows a Sup3rh3slo.Linux.

Pro přihlášení ani není často potřeba heslo v otevřeném textu znát. U mnoha služeb se stačí prokázat pomocí haše, který vlastně funguje místo hesla. Stačí nám získat roli administrátora a přečíst si haše hesel, které pak použijeme u dalších služeb. Problém je to například na Windows, kde obvykle v organizaci má na všech počítačích lokální admin stejné heslo. Správce většinou uvažuje tak, že má velmi dobré a silné heslo, které nikdo neuhádne. Nám ale stačí získat jen jeho haš a můžeme se procházet po všech počítačích.

Hesla bývají také často v počítačích špatně uložená, uživatelé často spoléhají na textové soubory. Ty se ale často objevují v zálohách nebo obrazech disků, kde je možné je dohledat. Uživatelé si také často posílají hesla v e-mailové komunikaci.

Část hesel není vůbec možné šifrovat nebo hašovat, protože se musí používat v otevřeném textu. Typicky Total Commander má uložená hesla, která pak používá k FTP serverům a musí je mít v otevřené podobě. Chyba je vůbec v tom, mít takto heslo v počítači nebezpečně uložené. Špatně zabezpečená jsou i hesla v prohlížečích. To je pro nás svatý grál, v prohlížeči nejsou hesla dobře chráněná a lze je snadno získat.

Na počítačové síti je možné použít útok Man-in-the-middle, kdy je možné se podívat do obsahu nešifrovaných protokolů: SMTP, FTP a další. Tam můžeme pohodlně odposlechnout hesla, která pak můžeme často využít i u jiných služeb. Stejně tak je možné úspěšně použít například phishing.

Aleš Padrta, Radomír Orkáč: Postup při řešení incidentu: Phishing

Phishing je stále velmi často používaná metoda, také v loňském roce jsme zaznamenali spoustu různých incidentů. Nejvíce se útočilo na univerzitní Office365, ale i na další služby. Často je používají studenti, kteří nebývají v informačních technologiích příliš kovaní.

Podvodné e-maily je možné rozdělit do několika skupin: vyžadující odpověď s citlivými údaji, nabízející odkaz na falešný přihlašovací formulář a konečně zprávu se závadnou přílohou. V každém případě ale útočník vytvoří e-mail, pošle ho na uživatelské účty a uživatelé pak reagují. Mohou používat firemní počítač, soukromý počítač a stejně tak různá připojení k internetu. Nepoučený uživatel pak může na phishing reagovat a předat útočníkovi citlivá data.


Autor: CESNET

Aleš Padrta

Phishing je incident a je potřeba se jím zabývat. Postup při řešení mívá obvykle pět kroků: příprava, zjištění a nahlášení, vyhodnocení a analýza, izolace a neutralizace a závěrečná činnost. K závěrečné činnosti patří i zpětná vazba směrem k uživatelům, na kterou se často zapomíná.

Velmi často se podceňuje samotná příprava. Pokud zaspíte při přípravě, jste připraveni selhat. Nemůžete pak nic dělat, jen sledujete, jak se váš svět hroutí. Správná příprava nám může pomoci minimalizovat pravděpodobnost výskytu samotného incidentu. Poučení uživatelé se do pasti nechytí a incident vůbec nevznikne.

Dobrá příprava může minimalizovat dopady při výskytu incidentu a usnadnit cestu k řešení. Základem je dobře nastavené prostředí, aby dobře fungovalo a umožnilo hladce problém vyřešit.

Při přípravě je potřeba také definovat pravomoci při řešení incidentu. To obvykle upravuje interní firemní směrnice či pokyny vedoucího. Ve velkých firmách je zvykem mít vyčleněný tým CSIRT, který rozhoduje samostatně a mívá pravomoci k monitoringu sítě a nutným zásahům. Má široké pravomoci, ale musí zpětně doložit, proč musel zasáhnout a třeba zablokovat konkrétního uživatele.


Autor: CESNET

Radomír Orkáč

Bezpečnostní tým by měl používat robustní systém pro správu požadavků, který do práce přinese přehlednost a umožňuje prohledávat historii. Obvykle se používají open-source nástroje jako Request Tracker, OTRS a další. Každý incident má založen samostatný lístek, do kterého přicházejí jednotlivá hlášení a interní komunikace. Vzniká tak koordinační prostředí včetně kompletního záznamu historie řešení incidentu.

Důležitá je také dokumentace, která kodifikuje standardní operační postupy. Zabráníte tím nekonzistenci, kdy jednoho uživatele zablokujete a druhému jen zavoláte a upozorníte ho. Dokumentaci je potřeba samozřejmě průběžně aktualizovat. Stejně tak je dobré udržovat si šablony pro e-mailovou komunikaci. V nich máte připravené seznamy údajů pro získání od uživatele, abyste vše potřebné mohli vyřešit jednou zprávou.

Pro řešení bezpečnostních incidentů je zásadní sběr dat, jen tak můžete zjistit, kdo používá vaši síť. Vzniká vazba IP – čas – uživatel. Adresy u nás přiděluje DHCP server a máme registrační systém pro pevné příděly. Pro ostatní uživatele používáme autentizaci pomocí 802.1×. Ze záznamů je pak možné přesně dohledat jednotlivé toky a přiřadit je k uživatelům.

Logování je pasivní zdroj informací, ale je dobré na síti provozovat také monitoring. Ten odhalí podezřelé chování zařízení či uživatelů. Automaticky je tak odhaleno například skenování sítě, rozesílání spamu, anomální časy a zdroje přihlašování a podobně. Monitorovat můžete úplně všechno, na co vám stačí kapacita a peníze.

Na odhalený incident je potřeba také rychle a efektivně reagovat – blokovat IP adresy či domény, blackholing a podobně. K tomu patří také zabezpečení koncových stanic, které si například mohou stahovat seznamy problémových domén. K síťovým prvkům mají běžně přístup jen síťaři, ale i bezpečnostní tým by měl mít k dispozici nějaké API, přes které dokáže prvky nastavit pro své potřeby.

Po nahlášení je potřeba také posoudit závažnost situace a rozhodnout o její prioritě. Důležitou roli tu hraje zkušenost toho, kdo hodnocení provádí. Hodnotícími kritérii jsou: rozpoznatelnost, rozsah a možnost reakce. Už z počtu hlášení můžete odhadovat, jak je situace vážná. Čím víc hlášení dorazí, tím je incident rozsáhlejší.

Je potřeba neutralizovat škody a najít kompromitované účty a zařízení. Uživatel je buď sám nahlásí nebo je možné použít monitoring a sledovat související anomálie: rozesílání spamu, telefonáty na nevhodná čísla, kontaktování konkrétních domén či IP adres a podobně.

Výsledkem řešení incidentu by mělo být také dostat phishingovou stránku na obecný blacklist. Je potřeba ji nahlásit na safebrowsing.google.com a na phishtank.com. Tyto blacklisty používají webové prohlížeče, služby a třeba také CZ.NIC pro oznamování problémů vlastníkům domén.

Ondřej Caletka: Ochrana soukromí v DNS

Edward Snowden v roce 2013 odhalil, že tajné služby jsou ve své činnosti výrazně intenzivnější než se myslelo. IETF na to reagovalo vydáním BCP188, které říká, že i odposlech je útokem. DNS je veřejný telefonní seznam, takže jej není jak a proč chránit. Ale při komunikaci se servery vzniká spousta metadat o uživatelích a je dobré se tím zabývat.

V roce 2014 vznikla při IETF pracovní skupina DPRIVE, která se zabývala tím, jak chránit komunikaci mezi uživatelem a DNS resolverem. Na začátku byla myšlenka do DNS přidat šifrování, ale opravdu potřebujeme nový protokol? Ano a rovnou dva! Bylo rozhodnuto, že DNS bude šifrován pomocí tunelu.

Vzniklo tak RFC 7858 s názvem DNS-over-TLS, které balí DNS do TLS a běží na TCP portu 853. Problém je s ověřením doménového jména serveru, protože nemůžeme server nakonfigurovat doménovým jménem. Tím by vznikl problém, jak resolvovat adresu tohoto serveru. Proto se používá oportunistické šifrování, kdy se doménové jméno nepoužívá.


Autor: CESNET

Ondřej Caletka

DNS-over-TLS (DoT) je velmi snadno nasaditelný, proto ho podporuje spousta nástrojů jako servery Unbound, Knot DNS, Google, Cloudflare a Quad9. Na klientské straně je podpora součástí resolveru v Android Pie, Unbound a Knot Resolver. Je dobré, že brání přinejmenším pasivnímu odposlechu a lze na něj oportunisticky přejít. Nevýhodou je, že port 853 lze snadno zablokovat a DNS jména unikají v SNI hlavičce TLS spojení. Objevuje se ale šifrované SNI, které se snad časem prosadí.

Konkurenční technologie se jmenuje DNS over HTTPS (DoH) a je kodifikovaná v RFC 8484 vydaném v říjnu 2018. Jde vlastně o posílání binárních DNS zpráv uvnitř HTTPS spojení. Dělá se to velmi jednoduše, binární zpráva se strčí přímo do HTTPS. Starší implementace od Google a Cloudflare ještě používala JSON.

DoH může běžet na samostatném serveru, který nabízí jen DNS služby nebo multiplexovaně s dalšími webovými službami. Výhodou je, že je dnes už součástí Firefoxu a Chrome a je prakticky nemožné komunikaci zablokovat nebo kontrolovat. Nevýhodou je, že vyžaduje URL pro konfiguraci a DNS servery dostávají mnohem více metadat z HTTP hlaviček. Provozovatel služby se také stává centrálním bodem a má informace, které dříve měl jen lokální resolver.

Standard DoT je poměrně jednoduchý upgrade, jako zavést HTTPS místo HTTP. Výhoda je, že vám to bude používat čím dál více lidí. Nebude to služba duchům, kterou spustíte a nikdo ji nebude používat. Jako provozovatel sítě máte stále kontrolu nad DNS provozem, protože lze snadno zablokovat externí resolvery.

DoH je proti tomu poměrně kontroverzní revoluce, která mění stávající pořádky, ale má silnou podporu v komunitě. Má velkou podporu vlivných lidí, zřejmě se z něj za čas stane standard. DNSSEC může krásně fungovat s oběma těmito protokoly, protože zabezpečuje autenticitu end-to-end.