Python a kybernetická bezpečnosť – 13. časť
Čím to je, že len čo niekto vymyslí niečo úžasné, takmer okamžite sa nájde niekto, kto to zneužije? Toto tvrdenie sa dá krásne aplikovať na systém ukladania prihlasovacích údajov, ktorý ponúkajú moderné internetové prehliadače. O čo ide? Určite ste sa už stretli s ponukou internetového prehliadača na uloženie prihlasovacieho mena a hesla počas prvého prihlasovania sa na niektorú z internetových stránok. Mnohí z nás túto ponuku využili, a tak nemusia pri každom novom otvorení danej stránky zadávať svoje ťažko zapamätateľné údaje znovu a znovu. Systém ukladania prihlasovacích údajov je určite nápomocný, ale predstavuje obrovské bezpečnostné riziko. V tejto časti seriálu prakticky predvedieme jednu z možností, ako sa dajú uvedené údaje veľmi jednoducho a ľahko získať. Zameriame sa pri tom na OS Windows a Google Chrome, na podobnom princípe však pracujú aj ostatné známe prehliadače.
Data Protection Application Programming Interface (DPAPI)
Pre každého používateľa OS Windows sa počas vytvárania jeho používateľského účtu generujú okrem iného aj rôzne bezpečnostné prvky, ktoré sa následne v prípade potreby používajú počas práce používateľa v rámci systému, resp. s jednotlivými aplikáciami. Táto oblasť je veľmi rozsiahla a určite nie je ambíciou tohto článku vysvetliť všetky jej detaily. Dôležité je však vedieť, že na rôznych miestach v rámci OS sú uložené tzv. DATA_BLOB a šifrovacie kľúče patriace konkrétnym používateľom. Pokiaľ dané prvky nemajú globálnu platnosť, je samozrejmé, že ich obsah dokáže čítať iba konkrétny používateľ. DPAPI ponúka rôzne funkcie, ktoré sú používané na systémovej úrovni, no dokáže ich použiť aj bežný používateľ OS.
Ukladanie prihlasovacích údajov v rámci Google Chrome
Internetové prehliadače, ako napr. Chrome, ponúkajú možnosť uložiť prihlasovacie údaje a neskôr ich využiť na automatické prihlásenie sa na konkrétnu stránku. Využívajú pri tom už spomínaný DPAPI a skutočnosť, že konkrétne bezpečnostné prvky v rámci OS sú sprístupnené iba konkrétnym používateľom. To znamená, že k prihlasovacím údajom uloženým v rámci Chrome sa dostane iba konkrétny používateľ, čo poskytuje akú-takú ochranu. Problém však je, že hoci Chrome prihlasovacie heslá šifruje, len čo je daný používateľ prihlásený do svojho účtu, zašifrované heslá možno ľahko dešifrovať. Predstavme si prípad, že máme v rámci Chrome uložených mnoho mien a hesiel na prístup k rôznym stránkam. Neraz môžeme to isté meno a heslo použiť aj na prístup na citlivejšie stránky, ako napr. internetové bankovníctvo, portály štátnej správy, zdravotnícke služby... Stačí, ak útočník získa prístup k nášmu systémovému účtu, a všetky uložené heslá použité v rámci Chrome, o ktorých sme si doposiaľ mysleli, že sú tajné, budú okamžite prezradené.
Obr. 1 Schéma ukladania bezpečnostných prvkov prehliadačom Google Chrome
Master_key
Celý problém s ukladaním prihlasovacích údajov spôsobuje tzv. master_key (pozri obr. 1). Ide o 32B náhodné číslo vygenerované prehliadačom Chrome, ktoré je zašifrované pomocou funkcie DPAPI CryptProtectData() s využitím prihlasovacích údajov konkrétneho používateľa. Následne je pred zašifrovaný master_key pridaný text „DPAPI“, celý objekt je zakódovaný kódovaním Base64 a vo formáte JSON uložený do súboru USER\AppData\Local\Google\Chrome\User Data\Local State, kde USER je domovská zložka používateľa. Jedinou podmienkou na dešifrovanie master_key je teda byť prihlásený do OS, nič viac.
Šifrovanie hesiel
Chrome využíva master_key pri šifrovaní hesiel, ktoré realizuje symetrickým algoritmom AES-256-GCM. Do tohto procesu vstupuje už iba 12B Initialization Vector, resp. Nonce a navyše 16B Authenticity Tag (AT). IV/Nonce sa ukladá spolu so zašifrovaným heslom a AT zabezpečuje autenticitu zašifrovaných údajov, teda v našom prípade je nepodstatný. Zašifrované heslá sa ukladajú do tabuľky logins databázy SQLite3, konkrétne do súboru USER\AppData\Local\Google\Chrome\User Data\default\Login Data.
Dešifrovanie hesiel
Master_key možno veľmi jednoducho dešifrovať pomocou funkcie DPAPI CryptUnprotectData(), a pretože sa IV/Nonce ukladá spolu so zašifrovaným heslom, nič nám nebráni toto heslo dešifrovať.
Skript GetChromeCredentials.py
Nami naprogramovaný skript realizuje uvedený proces dešifrovania master_key a následne dešifrovania hesiel uložených prehliadačom Chrome počas uloženia prihlasovacích údajov k prístupu na konkrétne stránky, a to v nasledujúcich krokoch:
|
Aktivita |
Výstup |
1 |
Načítanie obsahu súboru Local State, v ktorom sú údaje uložené vo formáte JSON |
Zašifrovaný zakódovaný master_key s „DPAPI“ |
2 |
Dekódovanie zašifrovaného master_key, ktorý je uložený v položke os_crypt.encrypted_key |
Zašifrovaný master_key s „DPAPI“ |
3 |
Odstránenie textu „DPAPI“ |
Zašifrovaný master_key |
4 |
Dešifrovanie master_key |
Dešifrovaný master_key |
5 |
Načítanie konkrétnych položiek tabuľky logins |
URL, meno, zašifrované heslo = 3B prefix + IV/Nonce + payload |
6 |
Výber IV/Nonce zo zašifrovaného hesla |
IV/Nonce |
7 |
Dešifrovanie hesla |
Dešifrované heslo + AT |
8 |
Odstránenie AT |
Dešifrované heslo |
Obr. 2 Textový výstup skriptu GetChromeCredentials.py
Na obr. 2 možno vidieť konkrétne URL, mená a dešifrované heslá uložené prehliadačom Chrome v procese ukladania prihlasovacích údajov. Údaje sú, samozrejme, mixované, ale pôvodne išlo o reálne čísla a reálne reťazce. Prezentujeme tak možnosť získania mien a hesiel, ktoré konkrétny používateľ používa na prístup ku konkrétnym internetovým stránkam, a to všetko iba za podmienky, že útočník má prístup k účtu používateľa v rámci OS.
Z uvedeného jasne vyplýva nevyhnutnosť bezpodmienečnej ochrany našich používateľských účtov v rámci OS. Prakticky sme predviedli, aké je dôležité používať veľmi silné heslá a tie si chrániť, ako len najlepšie vieme. Heslá nikdy nikomu neprezrádzame, neposielame a určite nenechávame na papieriku prilepenom na monitore. Ak sa totiž niekto prihlási do nášho systémového účtu, veľmi ľahko si dokáže prečítať všetky ostatné heslá.
Zobrazit Galériu