Podívejte se raději na online verzi přednášky, slajdy mohly být aktualizovány nebo doplněny.

Detail přednášky

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.

Bezpečnost webových aplikací pro vývojáře probíráme také na veřejném školení Bezpečnost webových aplikací (nejbližší termín: termín zatím nevypsán), přijďte. Firmám navíc nabízím také např. kurz zaměřený jenom na HTTPS.

Datum a akce

10. listopadu 2016, Kybernetická bezpečnost – řízení procesů a aplikace moderních technologií (délka přednášky 60 minut)

Slajdy

SlideShare

Přepis poznámek

  1. Watch For Ice

    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. Mark Zuckerberg

    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. LinkedIn Lost 167 Million Account Credentials in Data Breach

    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. Russian ‚Hacker‘ Detained In Prague

    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. You were in Linkedin Database with the password

    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. SHA-1 0f158e648228a19cab5f23acfd6c36f716a702a9

    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 Injection

    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. Dones z venku 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. SELECT ... WHERE cena < 400 **UNION SELECT email, heslo FROM uzivatele**

    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. sqlmap®

    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. 0f158e648228a19cab5f23acfd6c36f716a702a9dadada

    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. aaa[a-e] → 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%)

    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. Speed/sec: 22.70M words, Estimated: 00:01:56:33

    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. Sagitta Brutalis 8× GPU

    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. GPU cluster

    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. Změnit si čas od času heslo je prospěšné.

    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. Spring2014, Spring14, Summer2014, Summer14, Fall2014, Autumn14, Winter2014Winter14

    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.

  23. Frequent password changes are the enemy of security, FTC technologist says

    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. Stop resetting your passwords, says UK govt's spy network

    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. SMS: Your one time access password is 567390

    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. So Hey You Should Stop Using Texts for Two-Factor Authentication

    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. Adding a phone number to your Google account can make it LESS secure.

    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. K čemu je 2FA, když mi na pobočce @O2_CZ dají nano SIM od libovolného čísla, aniž by viděli starou SIM nebo občanku?!

    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. So she just basically blocked me out of my own account.

    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 manager

    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, LastPass, 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. Google Authenticator

    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. Authy, Duo Security, YubiKey

    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. Insecure Direct Object Reference, faktura?id=12[3–8]

    Ú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. Browsing the Internet with XSS mode On

    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

Michal Špaček

Vyvíjím webové aplikace, zajímá mě jejich bezpečnost. Nebojím se o tom mluvit veřejně, hledám hranice tak, že je posouvám. Chci naučit webové vývojáře stavět bezpečnější a výkonnější weby a aplikace.

Veřejná školení

Zvu vás na následující školení, která pořádám a vedu: