O několika klasických webových útocích, o heslech a uživatelích, kterým občas dáváme zaručené rady, které jejich bezpečnost mohou naopak ohrozit.

1. MEDVĚDÍ SLUŽBAMEDVĚDÍ SLUŽBA
Michal Špaček
www.michalspacek.cz @spazef0rze
O několika klasických webových útocích, o heslech a uživatelích, kterým občas
dáváme zaručené rady, které jejich bezpečnost mohou naopak ohrozit. Slajdy
obsahují poznámky, které v původní přednášce nejsou. Chudák medvěd.

2. Tohle je Mark. Mark šéfuje Facebooku. Mark používal stejné heslo pro LinkedIn,
Pinterest i Twitter. Nebuďte jako Mark a nepoužívejte jedno heslo na více místech.

3. LinkedInu v roce 2012 uniklo 167 milionů uživatelských účtů. Tenkrát si mysleli, že to
bylo jen 6,5 milionu, ale o čtyři roky později se ukázalo, že ten únik byl o dost větší.
Uniklá data totiž někdo začal prodávat a tak se na celý rozsah vlastně přišlo. Jestli
vaše e-mailová adresa není v nějakém veřejném úniku si můžete zkontrolovat na
službě haveibeenpwned.com. Ta také umožňuje posílat notifikace, nastavte si je.

4. Za únik dat z LinkedInu i dalších služeb je údajně odpovědný Jevgenij Nikulin. Toho
policie zadržela 5. října 2016 v Praze.

5. Zpátky k Zuckerbergovi, počátkem června 2016 se na jeho Twitter účtu objevila
zpráva, že jeho heslo na Twitter a další služby bylo v uniklých datech z LinkedInu.
Markovo jménem to tam napsal kdosi s přezdívkou OurMine poté, co balík všech
167 milionů účtů z LinkedInu začal volně kolovat po Internetu.

6. 0f158e648228a19cab5f23acfd6c36f716a702a9
SHA-1 hash
Markovo heslo naštěstí nebylo v LinkedInu uloženo v čitelné podobě, ale jako SHA-1
hash 0f158e…. Ale vlastně to vůbec nepomohlo, jak se dozvíme dále.

7. SQL INJECTIONSQL INJECTION
CENZURA
Data z webových aplikací se často dolují pomocí útoku SQL Injection. Ten poprvé
veřejně popsal Jeff Forristal v článku o webových zranitelnostech Windows NT pro
Phrack Magazine již v roce 1998, tenkrát ještě jako bezejmenný útok.

8. SQL Injection v běžném životě
● Dones z venku
● Dones z venku
← Útok SQL Injection
DŘEVO
DŘEVO
A KUP
V KRÁMU
PIVO
V běžném životě ten útok vypadá takto. Někdo vás pošle ven pro věc, kterou vám
napíše na papírek („dřevo“). Vy si na ten papírek dopíšete další příkaz („kup v krámu
pivo“) a domů tak donesete kromě dřeva i pivo. Přesně takhle SQL Injection funguje.

9. Útok SQL Injection
www.eshop.cz/hledej?max=400 UNION …
SELECT kniha, cena FROM knihy WHERE cena < 400
UNION SELECT email, heslo FROM uzivatele
Válka s mloky 300 Kč
mail@michalspacek.cz h,m+d198frt
josef@novak.cz 798656
Na webu to funguje podobně. Když webová aplikace pošle do databáze dotaz
SELECT s neošetřeným uživatelským vstupem (zde maximální cena 400 Kč pro
vyhledávací filtr), tak je možné přidat příkaz „připoj data z tabulky uživatelů“ a do
stránky se tak kromě nalezených knih levnějších než 400 Kč vypíší i uživatelská
jména a hesla. (Moje heslo zkoušet nemusíte, je to zbytečné, věřte mi.)

10. Pro hledání zranitelností SQL Injection se používá mj. program sqlmap. Umí
zranitelnost detekovat a samozřejmě i zneužít. Je to legální, legitimní (a výborný)
nástroj, ale samozřejmě lze použít i špatným způsobem, podobně jako např. sekera.
sqlmap byl použit například při útoku na službu Jabbim.cz v prosinci 2014.

11. Podařilo se nám tedy získat nějaká zahashovaná hesla a co teď s nimi? Jak z hashe
0f158e648228a19cab5f23acfd6c36f716a702a9 získat heslo? Nejjednodušší je
zkusit Google. Ten prohledává veřejně přístupné předpočítané tabulky hashů a
jednoduchá hesla najdete rovnou na stránce s výsledky. Marku, dadada, vážně?

12. data → zašifrovat → dešifrovat → data
data → zahashovat → otisk
Jaký je vlastně rozdíl mezi hashováním a šifrováním? Šifrování je obousměrná
operace, zašifrujeme-li nějaká data, můžeme je zase dešifrovat a získat tak původní
data. Hashování je pouze jednosměrná funkce, hashováním vyrobíme otisk, ze
kterého původní data nelze získat, podobně jako z otisku prstu neuděláte člověka.

13. aaaa → zahashovat → otisk?
aaab → zahashovat → otisk?
aaac → zahashovat → otisk?
aaad → zahashovat → otisk?
aaae → zahashovat → otisk?
Lámání zahashovaných hesel probíhá tak, že generujeme kandidáty, zahashujeme
je a porovnáme, jestli výsledný hash neodpovídá nějakému otisku získanému z
databáze. Hashe kandidátů můžeme také předpočítat a uložit do nějaké tabulky na
pozdější použití, ale to je jen na takového domácí crackování, není to moc efektivní.

14. First capital last symbol = 56 (0.21%)
First capital last number = 2213 (8.35%)
Single digit on the end = 1467 (5.54%)
Two digits on the end = 2776 (10.47%)
Three digits on the end = 1911 (7.21%)
Crackování se dá razantně urychlit. Díky analýzám uniklých hesel již víme, jak lidé
hesla nejčastěji vytváří a není třeba generovat takové kandidáty, které stejně skoro
nikdo nepoužívá. Toto je část analýzy 25 tisíc hesel uniklých z Xzone.cz, podobné
výsledky najdeme i v analýze 118 tisíc hesel ze služby SkTorrent.eu.

15. I můj pár let starý laptop bez dedikované grafické karty dokáže generovat zhruba 20
milionů SHA-1 nebo MD5 hashů za vteřinu. To znamená, že pokud budeme zkoušet
jen hesla dlouhá 8 znaků, která mají první písmeno velké, dále 6 malých písmen a
na konci číslici, tak vygenerovat všechny takové kombinace a spočítat z nich MD5
nebo SHA-1 hash bude mému laptopu trvat přibližně dvě hodiny.

16. Ale na laptopech se hesla nelámou. Na to jsou speciální stroje s mnoha výkonnými
grafickými kartami, které se pro crackování používají. Ty mají velmi rychlé operace s
celými čísly a stovky jader, takže výpočty lze provádět paralelně. Takové stroje umí
generovat desítky miliard MD5 a SHA-1 hashů za vteřinu. Staví je Jeremi Gosney
a jeho firma Sagitta HPC. Stroj s 8× GPU Nvidia stojí necelých $19000.

17. Pokud by vám takový brutální výkon nestačil, tak Sagitta HPC umí vzít více strojů
a postavit z nich tenhle cluster s celkem desítkami až stovkami GPU. To se to pak
láme. Jeremi a jeho tým samozřejmě staví i levnější crackovací servery.

18. Argon2
bcrypt
scrypt
PBKDF2
Na hashování hesel byste měli používat tyto algoritmy. Nejlepší je použít Argon2,
pokud pro váš programovací jazyk již existuje. V PHP je např. bcrypt implementován
v pro vývojáře jednoduchých funkcích password_hash() a password_verify().
Tyto algoritmy samy o sobě podporují salt a např. zmíněné funkce v PHP jej umí
i samy vygenerovat, takže programátor na salt nemusí myslet (a nemůže ho zkazit).

19. 8 znaků
Jedno velké
Jedno číslo
Existuje spousta rad, jak si uživatelé mají vytvořit bezpečná a silná hesla. Jedna
taková běžná říká, že heslo by mělo mít minimálně 8 znaků, minimálně jedno velké
písmeno a minimálně jedno číslo. Taková rada může být právě tou medvědí službou.

20. First capital last number
8.35%
Pamatujete na analýzu z předchozích slajdů? Přes 8 % uživatelů si zvolilo takové
heslo, které začíná velkým písmenem a končí číslem. Když je politika vytváření hesel
nastavená tak že heslo musí obsahovat velké písmeno a číslo, tak to velké písmeno
pravděpodobně bude na začátku a to číslo na konci. Značně to lámání takových
hesel urychlí. Podle požadavků na heslo se dá určit, jaká hesla uživatelé vytvoří.

21. Dobrá, tak uživatelům budeme říkat, že svá hesla mají pravidelně nebo alespoň
občas změnit. Radí to banky i správce domény CZ.NIC na webu služby MojeID.

22. Postupem času to pak většinou dopadne tak, že uživatelé svá hesla zjednoduší
natolik, že se stanou předvídatelnými. Uživatelé i jejich hesla. Tak to ukázal
například výzkum společnosti NetSPI.
● Fall2014 - 150
● Autumn14 - 15
● Winter2014 - 87
● Winter14 - 63
● Password1 - 1,446
● Spring2014 - 219
● Spring14 - 135
● Summer2014 - 474
● Summer14 - 221

23. Pokud uživatelé na hesla používají jen hlavu, tak se jim nebude chtít za 90 dní
vymýšlet a pamatovat si další složité heslo, tak si to usnadní a tím sníží i bezpečnost
hesel. Když na hesla používají nějaký program, tak pravidelná změna neuškodí, ale
nejspíš také moc nepomůže. Útočník může mít zadní vrátka v systému, ze kterého
hesla získal, a nebude pro něj problém hesla nebo jejich hashe získat znovu. Hesla
je nejlepší měnit až ve chvíli, když víte nebo máte podezření, že vám heslo nějak
uniklo, že jste ho zadali do falešného webu, že vám ho někdo přečetl přes rameno,
nebo když vám provozovatel služby napíše, že mu unikla celá jeho databáze hesel.

24. Kromě amerického FTC (Federal Trade Commision) varuje před nebezpečím, které
může pravidelná změna hesel skrývat i britská vládní agentura GCHQ
prostřednictvím své skupiny CESG (Communications-Electronics Security Group).

25. A co na to chudák uživatel? Jedni mu říkají, že si hesla má pravidelně měnit, druzí
mu říkají, že raději ne. Komu má věřit, co si z toho má odnést a co má pro
bezpečnost svých dat a hesel dělat? To by se z toho jeden zvencnul.

26. Takže uživateli ještě doporučíme, aby začal používat ověřování pomocí SMS. Při
přihlašování zadá svoje heslo, přijde mu na mobil jednorázový kód v SMS, ten opíše
a je bezpečně přihlášen. Nebo snad ne?

27. Možná, dokud si nepřečte, že by SMS neměl na ověřování přihlášení používat. SMS
lze odposlechnout a nedají se ani považovat za „druhý faktor“ pro účely dvou-
faktorové autentizace, protože telefonní čísla se dají unést bez přístupu k telefonu
nebo SIM kartě, stačí vysoušlinženýrovat zákaznickou linku mobilního operátora.

28. Telefonní čísla se často používají i pro reset zapomenutých hesel, to když služba na
ono číslo zašle kód a po jeho opsání je možné nastavit heslo nové. Když se někomu
podaří unést ne samotný mobil, ne SIM kartu, ale to telefonní číslo, tak je pak
hračkou resetovat hesla a tím získat přístup i k dalším službám.

29. A že se obalamutit dají i čeští mobilní operátoři ukazuje Jirka Helmich. Nejmenovaný
modrý operátor mu dal novou SIM kartu, aniž by si ho jakkoliv ověřil. Naštěstí, nebo
možná spíš náhodou, ji dal opravdu tomu správnému člověku.

30. Podívejte se, jak vcelku jednoduché je získat data od mobilního operátora nebo
rovnou nechat nastavit heslo k cizímu účtu. Stačilo k tomu použít zvuk plačícího
dítěte a pár „neprůstřelných“ argumentů a oheň je na střeše.

31. Password managerPassword manager
http://www.flickr.com/photos/76029035@N02/6829471407/
Uživatelé by měli na hesla raději používat nějakého správce hesel. To je program,
který si hesla pamatuje za vás a pomáhá vám je také vytvářet. Poté si už musíte
pamatovat jen jedno hlavní heslo, to může být velmi silné, nebude nutné ho měnit
každých 30 dní a nebudete si takových hesel muset pamatovat desítky.

32. 1Password
KeePass
Používání password managerů má sice jistá rizika, ale ta jsou pořád menší, než když
budete všude používat stejné heslo, nebo když vaše hesla budou předvídatelná.
Výrobce správců hesel jsou si těchto rizik vědomí a snaží se proti nim bojovat. S
jedním z těchto třech chybu neuděláte. Více v mojí přednášce o hlavě a heslech.

33. Místo ověřování přihlášení pomocí SMS používejte raději mobilní aplikace jako např.
Google Authenticator. Ta umí tyhle kódy potřebné pro 2FA generovat sama bez
připojení kamkoliv. Takto se navíc vyřeší i zákeřné aplikace s právem čtení SMS,
které vás mizera nějak donutil nainstalovat.

34. Když vám telefon s Authenticatorem odejde, nebo ho ztratíte, tak máte smůlu
a ověřování přihlášení si budete muset resetovat, pokud to půjde. Raději používejte
aplikace, které kódy zálohují a synchronizují mezi různými zařízeními, jako třeba
Authy nebo Duo Security. Nebo rovnou nějaký hardwarový token, např. YubiKey.

35. https://example.com/faktura?id=123
124
125
126
127
128
Insecure Direct Object Reference
Útoků na webové aplikace je pochopitelně mnohem více. Dalším mým oblíbeným je
útok Insecure Direct Object Reference, který spočívá v chybějící kontrole oprávnění.
Aplikace tak dovolí zobrazit například faktury, které patří jiným zákazníkům nebo
umožní nastavit heslo ostatním uživatelům změnou parametru id ve formuláři.

36. Někteří uživatelé webu jsou prý jiní a tam kde vy vidíte formulářová políčka, oni vidí
Cross-Site Scripting. Nevím, které uživatele Luboš K. přesně myslel, když ve své
přednášce ukazoval tento slajd, nicméně pravdou je, že útok Cross-Site Scripting
mám také rád, ale o tom až někdy jindy a někde jinde, třeba v mojí přednášce o XSS.
Michal Špaček
www.michalspacek.cz @spazef0rze