Hlavní navigace

Internet je rozbitější a uživatelé hloupější, než odborníci na bezpečnost doufali

7. 2. 2018
Doba čtení: 16 minut

Sdílet

Jak vypadala (ne)bezpečnostní situace v roce 2017? Jaká je role certifikátů v bezpečné komunikaci? Jak zabezpečit web server a jaké jsou zkušenosti se zákonem o hazardních hrách? Je GDPR a ePrivacy správná cesta?

V úterý 6. února pořádalo sdružení CESNET svůj pravidelný Seminář o bezpečnosti sítí a služeb, na kterém se probírala především aktuální bezpečnostní, technická, ale i právní témata.

NeBezpečnost v roce 2017: Radoslav Bodó, Michal Kostěnec

První přednáška měla za cíl představit práci bezpečnostního týmu CESNET a upozornit na bezpečnostní problémy objevené v loňském roce. Na začátku byla popsána zranitelnost v nástroji Freeradius, který se často používá při přihlašování do Wi-Fi sítí. Používá se tu protokol TLS, který umožňuje přerušit a obnovit spojení. Freeradius ale obsahoval chybu, která dovolovala při správném přerušení a navázání spojení přeskočit fázi autentizace. Klient se tak mohl přihlásit bez ověření.

V Brně byla objevena chyba v knihovně používané v čipech firmy Infineon (CVE-2017–15361). Ty používají další výrobci TPM a hardwarových zařízení – na GitHubu bylo nalezeno 250 slabých klíčů, objeveno bylo asi 1000 slabých PGP klíčů, ale především tyto čipy používají občanské průkazy v Estonsku a na Slovensku. Chyba se týká optimalizace algoritmu generování RSA klíčů. V praxi je možné v rozumném čase faktorizovat privátní klíč generovaný kartou a zneužít ho.

Dále byla objevena zranitelnost Wi-Fi čipů Broadcom řady BCM43XX. Začali zkoumat jednotlivé čipy a v tu chvíli se na internetu objevily zdrojové kódy konkrétního routeru a s nimi unikly zdrojové kódy k Wi-Fi čipům. Čip používá vlastní operační paměť, která ale nemá implementovanou žádnou ochranu a je navíc libovolně zapisovatelná a kód je pak spustitelný. V kódu pak byla nalezena zranitelnost typu buffer overflow, kterou je možné zneužít pomocí škodlivého kódu v názvu upravené Wi-Fi sítě. Zranitelnost se týká čipů používaných v mnoha mobilních telefonech včetně značek jako iPhone nebo Samsung.

Známý je také útok KRACK vedený na protokol WPA2. Útočník dokáže během navazování spojení donutit oběť, aby začala v další fázi používat parametry již jednou používané v minulosti. Poruší se tím pravidla pro bezpečné šifrování a umožní to útočníkovi dále pronikat do šifrování a nakonec odhadnout klíč. Může pak sledovat komunikaci nebo do ni vstupovat. Ne všechny implementace WPA2 jsou správné, na Windows je například možné chybu zneužít jen částečně, naopak v Linuxu a Androidu je problém velmi vážný.

Svět Windows vloni ohrožoval červ WannaCry, který zneužíval již tři měsíce záplatovanou chybu EternalBlue k infekci náhodných cílů v celém internetu, ale i lokální síti. Útočníci chtěli zaplatit v bitcoinech, ale ukázalo se, že nemají žádnou chuť data uživatelům obnovit. Podařilo se jim vydělat přes sto tisíc dolarů a ty nakonec úspěšně vyprat.

Do počítačové bezpečnosti v posledních letech promlouvají kryptoměny, ať už známý Bitcoin, nebo i další nově vznikající. Pro útočníky je zajímavou a užitečnou alternativou měna Monero, která je navržená tak, aby nebylo možné výpočty jednoduše urychlit pomocí hardwarových ASIC čipů a má některé výhody z hlediska anonymity. Opět se objevují velké útoky botnetů, které po úspěšném útoku nainstalují miner a bez práce vydělávají peníze. Podobně se objevují javascriptové knihovny nebo se útočí pomocí SQL injection. Když vám někdo napadne WordPress, už ho nezajímají hesla, ale vloží vám do šablon těžařský kód.

Kromě zlých zájmových skupin se formují také ty hodné. My jsme se zúčastnili akce LockedShields, což je taková bojovka mezi 20 státy, která se odehrává ve virtuálním prostředí. V ohromné cvičné síti je asi 120 druhů prvků a každý tým se musí starat o zabezpečení a zajištění celého systému. Škála protokolů a zařízení je ale obrovská, takže cílem je složit kvalitní tým, který dokáže postihnout celou šíři problematiky a pružně reagovat. Češi v letošním ročníku zvítězili, zajímavé také je, že v loňském roce vyhráli Slováci.

Role certifikátů v bezpečné komunikaci, Ondřej Caletka

Ondřej Caletka začal svou přednášku anketou, ve které posluchači odpovídali na otázku, co v prohlížeči znamená slovo „Zabezpečeno“ v adresním řádku. Většina uživatelů se totiž domnívá, že takto označená stránka je prověřená a bezpečná. Není to pravda, ve skutečnosti to jen znamená, že se serverem šifrujeme. Autorita nedokáže nijak ověřit úmysly provozovatele serveru. S nástupem automaticky ověřovaných DV certifikátů se role autority zmenšila skutečně jen na ověření držení domény.

Podobně druhá anketa vysvětlila, že certifikát neslouží ani k šifrování ani jej není potřeba chránit. Stále se často setkáváme s nepochopením smyslu certifikátu. Pomocí něj se nijak nešifruje, ten slouží pouze k ověření identity. Jeho role je podobná jako v případě občanského průkazu nebo pasu.


Certifikát je tedy průkazem totožnosti, který svazuje virtuální identitu (šifrovací klíč) s reálnou identitou (jménem). Certifikát je zabezpečen proti falšování, v případě občanského průkazu je to zajištěno specializovaným tiskem a dalšími ochranami. Certifikát je zabezpečen pomocí kryptografie a digitálním podpisem autority, která jej vystavila.

Existují tři stupně ověření certifikátu: DV, OV a EV. Skutečné ověření identity žadatele je velmi drahé a spousta lidí si to nemůže nebo nechce dovolit. Objevilo se tedy ověření doménového jména, které dovolilo vše automatizovat a zlevnit. Ověření se tím zjednodušilo jen na kontrolu automaticky vystavených údajů na serveru nebo potvrzení zprávy z doručeného e-mailu. Na základě toho vám pak vystaví certifikát, ve kterém není uvedené vaše skutečné jméno.

Na opačné straně pak stojí EV certifikáty, které se projevují tím, že prohlížeč v adresním řádku zobrazí také jméno organizace. To je mnohem důležitější, protože třeba v případě banky vás nezajímá, že komunikujete s držitelem domény, ale že jste ve spojení se správnou institucí. Tyto certifikáty by proto měly být (alespoň teoreticky) výrazně lépe ověřovány, mohou být platné maximálně dva roky a není možné vystavit wildcard EV certifikát.

Na konci února se změní pravidla pro DV a OV certifikáty, kterým se zkrátí maximální délka platnosti ze tří na dva roky. Tyto typy certifikátů také mohou používat wildcard domény, a jsou tedy platné pro všechny subdomény. To vypadá jako velmi dobrý nápad, ale mělo by to být používáno jen ve výjimečných případech. Jakmile totiž dojde ke kompromitaci, je kompromitována celá doména včetně všech subdomén.

Bohužel v současné době existuje několik různých standardů pro revokaci certifikátů, žádný z nich ale pořádně nefunguje. Tradičně se používaly CRL seznamy, které ale neškálují a jejich velikost a množství dělá problémy například mobilním zařízením. Alternativou je protokol OCSP, u kterého se klient při každém použití certifikátů ptá autority, zda je ještě certifikát platný. To je velmi náročné na dostupnost a vytváří to místo, které stačí vypnout, aby přestal fungovat internet. Nejpoužitelnější variantou jsou pak takzvané CRLSets, které má vestavěné prohlížeč Chrome. Bohužel jeho vytváření je netransparentní, je v rukou jediné firmy a ta do něj přidává jen ‚důležité revokace‘, ať je to cokoliv.

Velkou změnu před několika lety přinesla autorita Let's Encrypt, která je otevřená, bezplatná a automatická. Zatímco ostatní autority mají automatizaci zavedenou jen na své straně, Let's Encrypt otevřela komunikační rozhraní i směrem ke klientům. V současné době autorita podporuje dvě metody ověření oprávněnosti žádosti: pomocí vystavení souborů na HTTP nebo vystavením DNS TXT záznamu.

Důležitou otázkou je, zda je Let's Encrypt se svou automatizací bezpečnostní hrozbou. Nejslabším místem je ověřování odpovědí od serveru žadatele, na což autorita reaguje tím, že posiluje svou infrastrukturu. V současné době probíhá ověření ze čtyř různých datacenter umístěných na různých místech na světě. Tím pádem není snadné z velké vzdálenosti ovlivnit komunikaci a přesměrovat si ji k útočníkovi. Pokud je ale dostatečně blízko, tak vám nic podobného nepomůže.

Na druhou stranu ale Let's Encrypt není objevitelem DV certifikátů. Ty tu byly už dřív, jen jejich použití nebylo zadarmo. Známý bezpečnostní expert Scott Helme ve svém článku tvrdí, že potřebujeme více phishingových stránek s HTTPS. Právě zneužití na phishingových webech je často používáno jako argument proti Let's Encrypt. S příchodem Certificate Transparency se ale situace mění, protože si každý může hlídat, zda někdo nevystavuje certifikát na doménové jméno, které by mohlo být zneužito k phishingu. Proto by tu měl být velký tlak na to, aby všechny phishingové weby měly HTTPS certifikát.

Bohužel v praxi neuspěl projekt DANE, který se snažil eliminovat roli certifikačních autorit ve vydávání DV certifikátů. Namísto aby autorita jednou ověřila naše držení domény a pak vystavila certifikát na tři roky, může si uživatel při každé návštěvě sám ověřit platnost. Jde o věc starší než Let's Encyrpt a než CAA záznamy, přesto je internetovou komunitou ignorováno. Naráží na to, že k použití DANE potřebujete DNSSEC. Protože je internet ještě rozbitější než jsme doufali, tak je problém dostat DNSSEC na koncový počítač.

Nejčastější přešlapy při zabezpečení www serveru, Martin Černáč

Chyby na web serverech se vyskytují v několika kategoriích: provozní, konfigurační, realizační a návrhové. Návrhové chyby jsou nejhorší. Když je nějaký systém špatně navržený od začátku, těžko nad ním stavět nějakou bezpečnou strukturu. Proto se těmto problémům Martin Černáč věnoval jako prvním.

Dnes už rozhodně neplatí, že webový server musí znamenat LAMP. Klienti dnes mají velmi rozdílné požadavky, potřebují PHP v různých verzích, Perl, Python, jedna aplikace potřebuje Redis, druhá MongoDB a tak dále. Za pár let zjistíte, že provozujete ‚božský server‘, na kterém běží všechno. Sami tomu vlastně nakonec ani dobře nerozumíte. Řešením je založit službu na microservices: vytvoříte reverzní proxy, přidáte kontejner pro každou aplikaci a získáte tak vlastně distribuovaný systém. Není to univerzální řešení, má také své nevýhody, například se v něm hůře hledají chyby a také může dojít k realizačním chybám.


Realizační chyby se týkají výběru vhodného nástroje k dosažení cíle. Měli bychom hledat nástroj, ne hledat způsob, jak daný nástroj použít pro naši situaci. Obvyklé je také nadměrné používání ‚black-box‘ komponent, u kterých není jasná interní funkce. Správce třeba ví, jak se daná komponenta používá, ale ve skutečnosti jí nerozumí. Podobně řada aplikací obsahuje zapouzdřený HTTP server, který je sice použitelný, ale jen v malém měřítku třeba pro testování.

Konfigurační chyby se poměrně snadno odhalují a velmi jednoduše se napravují. Je tak možné pomocí různých nástrojů automaticky zkontrolovat, že všechno funguje správně. Rychle tak odhalíte nový problém, který vznikne za provozu. Je potřeba si dát pozor také na zbytečné předávání citlivých údajů uživateli: chybové informace PHP, podrobnosti o verzích serveru a dalších komponent. Uživatele takové informace nezajímají, vy jako správci z toho nic nemáte, ale útočník z toho něco mít může.

Stále je možné se setkat také se zapomenutým directory listingem, který útočníkovi usnadní přístup k souborům na web serverům. Možná se tomu divíte, ale uživatelé skutečně často založí třeba adresář backup, do kterého nahrají zálohu serverů. Tu si pak stáhnou po FTP, ale už si neuvědomí, že obsah je dostupný přes web s directory listingem.

Rozšiřuje se počet serverů, které používají HTTPS. Dnes jde o základ pro bezpečí uživatelů web serveru. Pouze podporovat je ale málo. Nestačí jen nahrát certifikát a zapnout podporu. Správce musí dbát na podporované šifry, sledovat bezpečnost jednotlivých protokolů a používat nástroje pro kontrolu zabezpečení. Méně je někdy více, zejména to platí u podpory verzí SSL a TLS. Musíme ale udělat nějaký kompromis zohledňující to, kolik uživatelů se k vám přes nové šifry nedostane. Nestačí také HTTPS jen nabízet jako volitelnou variantu, je důležité si bezpečnou komunikaci vynutit například pomocí HSTS. Z penetračních testů víme, že uživatelé klidně zadají údaje do phishingové stránky, která HTTPS neumí. Musíte tedy myslet za ně a vědět lépe než oni, jak to má být správně.

Martin Černáč prováděl také vlastní průzkum, při kterém na vzorku 100 000 domén v .cz zkoušel zahájit komunikaci po HTTPS. Přibližně 8 % odpovědělo a 62 000 předložilo certifikát. Sesbíral pouze 7725 unikátních certifikátů, z nich bylo jen 1335 správně použitých. Nejčastější chybou bylo předložení certifikátu na jiné doménové jméno. Hodně se mluví o tom, že se všude už šifruje a problém HTTPS je vyřešený, ale podle mých zjištění to tak není. Snad jen pro Google a Facebook, ale obecně situace ještě příliš dobrá není. Detaily o výzkumu je možné najít v bakalářské práci [PDF].

Bezpečnostně provozní kaleidoskop, Tomáš Košňar

Tomáš Košňar vyvíjí systém FTAS, který slouží k monitoringu síťového provozu v síti CESNET. FTAS je služba určená pro e-infrastrukturu CESNET, ale také pro uživatele této sítě. Využívají jej instituce zabývající se výzkumem, vývojem, vzděláváním a další. Nově vzniklo něco, čemu se pracovně říká „Krajský FTAS“, kdy je možné z jednoho místa poskytovat služby více subjektům. Kraj dodá odborný personál, který se stará o správu celého systému. V jednotlivých institucích pak správci jen nastaví export dat z prvků do centrální databáze.

Na základě sesbíraných dat pak vzniká reputační databáze, která pak zpětně slouží k filtraci nebezpečného provozu. Nejtypičtější jsou agresivní TCP SYN floody nebo skeny do vnitřní sítě, na základě nichž pak vznikají blokační pravidla. Z databáze je možné získat také agregovaná data podle geolokačních údajů. Takový žebříček není příliš vypovídající, ale ukazuje obvyklé rozložení nejčastějších zemí, ve kterých jsou útočící adresy zaregistrovány.


V poslední době se na internetu objevily také seznamy IP adres ze sítě CESNET, na kterých je otevřený TCP port 3389 určený pro RDP. Pomocí údajů z databáze jsme vyfiltrovali některé počítače podle velkého provozu, který tekl z naší sítě. Vyřešili jsme to pak s místními správci.

Přednáška se dále zabývala architekturou připojení pro kritické služby. Při návrhu konkrétní sítě se obvykle hledí na koncovou aplikaci, zda unese plný počet uživatelů a podobně. Zapomíná se ale na síťovou infrastrukturu. Když něco takového navrhujete, dívejte se na síť jako na řetězec prvků, přistupujte k ní komplexně. Podle Košňara je především důležité mít konkrétní data. Kdo neměří, ten nic neví. Je proto potřeba najít nejslabší prvky, úzká místa a postarat se o zlepšení. Opravdu klíčová je znalost charakteru a objemu provozu, to nám umožní udělat analýzu každého podstatného článku řetězu.

Zároveň je potřeba mít vytvořenou strategii regulace provozu, abychom udrželi soustavu provozuschopnou a v extrému byly postupně regulovány části provozu podle našich vlastních priorit. Ne abychom vše řešili na poslední chvíli a pak raději zahodili všechen provoz. Především je potřeba začít s podobnými plány včas, ne až těsně před spuštěním služby do ostrého provozu nebo dokonce až za pochodu během útoku.

Poslední část přednášky se pak zabývala projektem FENIX, který vznikl na půdě sdružení NIX.CZ. Mimo jiné má umožnit dostupnost internetových služeb v rámci oddělené sítě, která je schopna fungovat samostatně i při velkém výpadku zbytku internetu. Co by se ale ve skutečnosti stalo, pokud by se FENIX skutečně odpojil a chtěl fungovat samostatně? V případě extrémních síťových útoků by měly být českým uživatelům dostupné alespoň české služby. Je ovšem jasné, že některé služby by dostupné nebyly. Přemýšleli jsme nad spoustou scénářů, je pravda, že některých služeb bychom se museli vzdát, ale jak to bude opravdu vypadat, ukáže až ostrý provoz.

12 měsíců se zákonem o hazardních hrách, Ondřej Caletka

Na loňském semináři se hojně hovořilo o zákoně o hazardních hrách (186/2016 Sb.), který se týká i poskytovatelů připojení k internetu. Ti musí zamezit v přístupu k internetovým stránkám uvedeným na seznamu internetových stránek s nepovolenými internetovými hrami. Některé pojmy nebyly vůbec jasné, ale ústavní soud řekl, že není možné bazírovat na slovíčkách. Horší je, že není určeno, jak to má být technicky provedeno. Zákon i přes protesty veřejnosti začal platit 1. ledna 2017, o dva týdny později vyšel metodický pokyn.

V únoru 2017 byl Ústavním soudem zamítnut návrh na zrušení části zákona. Nedělo se nic až do července, kdy byl zveřejněn první blacklist s jednou doménou. Dnes je na něm sedm domén. Seznam je zveřejněn v PDF s textovou vrstvou, při výmazu má být patřičná část začerněna. To se zatím nestalo a jsme na to velmi zvědavi. Podle ministerstva by se mělo blokovat na úrovni DNS, nemají se blokovat IP adresy. To jsme přesně chtěli slyšet.

CESNET blokuje pomocí DNS zóny rpz.cesnet.cz a pomocí nástroje rss2email sledují novinky v RSS ministerstva. Blokujeme pak přesnou shodu doménového jména, nikoliv subdomény. Nedává to smysl, ale stejně tak nedává smysl blokovat cokoliv navíc. Přesměrování pak probíhá na IP adresu serveru poker.cesnet.cz s návratovým kódem HTTP 451 Nedostupné z právních důvodů. Technické detaily popsal v samostatném článku.

Ve stejnou dobu začali s blokováním i Slováci, kteří ale do konce letošního roku zablokovali 133 adres. Jejich blokování alespoň formálně prochází přes soud, který na základě návrhu ministerstva vydá soudní příkaz. V něm je jasně napsáno, kdo a co má přesně udělat. Ta samá věc se tedy dá dělat logičtěji než se dělá u nás.

Jan Kolouch: IT a legislativa – quo vadis?

Jan Kolouch se ve své přednášce věnoval tomu, proč právo tak „bobtná“? Tak jako se internet vyvíjí, vyvíjíme se i my. Co všechno se ale po nás chce? Vyvíjíme se i my? Bohužel ne, lidé spíš hloupnou a nabírá to ne úplně dobrý směr. Místo mozku pak používáme Google, který ví všechno a na všechno má odpověď. Neřešíme ale vztahy a vzájemné souvislosti toho, co tam najdeme.

Co vlastně chceme jako uživatelé? Chceme soukromí, což je něco, co by mělo být hájené a nedotknutelné. Soukromí nám přiznávají současné právní normy. Pro spoustu lidí je konečným řešením GDPR. Je přeci lepší a komplexnější. Uživatelé předpokládají, že za ně budou muset všichni zlí a oškliví sběrači osobních dat jejich údaje chránit. Musí je chránit oni, když už já je do toho internetu sám cpu!


GDPR zavádí nové zásady a povinnosti pro správce dat: musí prokázat existenci alespoň jednoho právního důvodu, musí dokumentovat, definovat účel a minimalizovat údaje. Na jednu stranu cpu všechny informace do Facebooku, ale zároveň ho nutím, aby minimalizoval ukládání údajů. Schizofrenie. Zpracovávat data je možné buď jen s konkrétním souhlasem nebo z jiných zákonných důvodů. Jak ale srozumitelně vysvětlit složitou věc? Tady je jedno z mnoha úskalí.

Jestli byla GDPR pro spoustu lidí bomba, ePrivacy je atomová bomba. Kompletně vám rozkope váš domeček z písku. Naštěstí jsme ještě ve stavu návrhu, ale otázkou je, zda se nám ho podaří ještě změnit. Měl by chránit soukromí fyzických i právnických osob v oblasti elektronické komunikace. Ale to už tady máme v listinách základních práv a svobod! Nová směrnice by ale měla být natolik široká, že postihne všechny současné i budoucí komunikační prostředky.

Tvůrci ePrivacy vlastně říkají, že už nezáleží na technickém způsobu komunikace (poskytovateli připojení), protože uživatelé si zvykli používat konkrétní služby, do kterých už poskytovatel často ani nevidí. ePrivacy tedy rozšiřuje svůj zásah na poskytovatele připojení, poskytovatele služeb a poskytovatele veřejně dostupných seznamů. Ve skutečnosti půjde o všechny služby, které umožňují ‚intrapersonální komunikaci‘, byť jen jako vedlejší produkt své hlavní činnosti. Prakticky tak může jít o cokoliv od Skype přes e-mail až po World of Tanks. To ale nestačí, už spolu komunikují i mašiny. Z tohoto pohledu by se vlastní nařízení mělo vztahovat i na komunikaci zařazenou do internetu věcí. Tím se zásah ještě více rozšiřuje.

Počítá se s tím, že se souhlas přenese na konkrétní aplikace. Uživatel musí potvrdit, že souhlasí se sběrem informací za konkrétním účelem přenosu dat při intrapersonální komunikaci. Tuto informaci navíc musí aplikace zobrazit každých šest měsíců. Všechny aplikace by nás tedy měly pravidelně otravovat oznámením o tom, že o nás sbírají určité informace.

ePrivacy také určuje, že by uživatelům měl být nabídnout soubor možnosti nastavení ochrany soukromí: nižší úroveň, střední úroveň a vyšší. Jak to uděláme s IoT? Podobných problémů je celá řada.

root_podpora

Otázkou je, jestli taková změna bude mít opravdu kýžený dopad. Skutečně přestaneme být komoditou? Přestane být řada služeb na internetu „zdarma“? Bude to vůbec fungovat? Právně to jistě bude fungovat dobře, napsané je to hezky. Bude to ale fungovat opravdu? Podle Koloucha zřejmě směrnici ePrivacy psali lidé, kteří neví, jak internet funguje. Vytváří se tu směrnice, která ve skutečnosti nebude fungovat.

Podle Koloucha bychom se měli zbavit závislosti a vzdělávat se. Místo abychom učili lidi, aby nedávali sami dobrovolně do internetu citlivé údaje, tak děláme, že nikdo takový neexistuje. Pokud v tom budeme pokračovat, budeme za každou cenu chránit lidi, kteří ochranu nechtějí a nepotřebují.

Byl pro vás článek přínosný?

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.