Zdravíčko, s ohledem na informace z poslední doby, kdy MSCHAPv2 ztratil poslední zbytky kreditu, bych se rád zeptal někoho, kdo se v jednosměrném šifrování vyzná, jaký je aktuální stav celé rodiny CHAP protokolu z hlediska odolnosti. Díky.
Zatím přeskakuji CHAP...
Poslední zbytky kreditu ztratil MSCHAP snad už hodně dávno? Také se to už snaží MS tak 15 let marně pohřbít. Spíše bych řekl, že širší informační veřejnost začala panikařit po té, co cca 3 měsíce zpět začal cloudcracker nabízet dešifrování nthashe za pár dolarů do jednoho dne. Zcela tim zkazil byznys slušným a zavedeným firmám, které se na tom doteď dobře živily (pravda, za o řády vyšší cenu, ale často s garancí dešifrování za podstatně kratší čas)...
Problém se týká všeho, kde je použit MSCHAP, pokud to není obaleno nějakou další bezpečnostní obálkou. Takže ať autorizační záležitosti typu holé PPP/PPPoE/802.1x/802.11i, tak i VPN technologie, kde zejména PPTP a taktéž L2TP (neníli použit IPsec transport) a SSTP (je-li vypnuta SSL/TLS obálka). MS se proto už tak 15 let snaží PPTP pohřbít, prvně náhraodu za L2TP/IPsec, potom, pro problémy s firewally a NAT, pomocí SSTP. A po zjištění, že SSTP trpí klasickým WinInWin problémem, tak už konečně čistým IPsec tunelem s IKEv2 (aby se vyhnul nemenšímu průseru jménem IKEv1 aggressive mód). Po úspěšném zjištní příslušného NThashe můžu dešifrovat kompletní VPN komunikaci i zpětně zachycenou (v MPPE není něco na styl PFS z IPsecu, bohužel) nebo se kamkoliv ověřit, kam pasuje daný login jméno a hash.
Zjednodušeně MSCHJAP funguje tak, že server pošle výzvu, klient ji zašifruje pomocí tří DES klíčů a ty tři zašifrované výzvy (každá jedním klíčem, ne jak 3DES, že se jedan data třikrát přešifrují přes sebe) se vrací serveru, který ověří, zda to sedí. Takže úkol zní najít ty 3 DES klíče. Jako klíč je použit nthash, což je 16 bajtů hash získaný jako MD4(heslo). MD4 je předchůdce MD5, je slabší, ale je zdarma k dispozici bez patentových poplatků. Nicméně zjišťovat zpětně čisté heslo z toho hashe je zbytečné, hash slouží jako plná náhrada toho hesla (protože Windows systémy drží uložen právě ten hash a vše odvozují od něj, aby tam nebyl čistě clear text). Pokud bych trval, že chci znát pro hezký pocit to heslo - cloudcracker, 20 USD a 20 minut (plus trochu štěstí). :-)
A Microsoft kdysi podělal to, jak se ten hash a DES použije. 3 DES klíče je 3x7=21 bajtů, ale hash má 16 bajtů, takže je to tak, že první dva klíče jsou po sedmi bajtech z toho hashe a poslední klíč je poslední dva bajty hashe plus 5 nul, takže jen 2^16 kombinací. Takže mám jen pasivním odposledchem chyceno pár prvních paketů jediné komunikace a vím výzvu, z odpovědi vím přihlašovací jméno v čistém tvaru a tři řetězce, každý předstaující tu výzvu šifrovanou po jendom z těch tří klíčů. Nalezneí třetího klíče (a získání tak posledních 2 bajtů hashe) je úkol pro PHP skript na 3 sekundy. Nalezení těch dvou 56 bitových prvních je už horší, to se řeší hardwarovými poli, dnes v low cost verzi s 100% úspěšností do 24 hodin při využití outscorovaných služeb (s větším rozpočtem reálně pod hodinu).
Tím pádem používat čistý PPTP nebo MSCHAP autorizaci má smysl tam, kde po zlomení nehrozí škoda víc jak 10 USD nebo údaje není třeba chránit déle, jak cca max 4 hodiny. V opačných přépadech je třeba použít něco jiného. Je třeba to brát tak, že data nejsou chráněna ani proti pasivnímu odposlechu (proto MS už 15 let cpe ten L2TP/IPsec, SSTP, IPsec/IKEv2 a lidi obvykle zatím moc nechtějí).
Co s tím? Pokud to chci pro autorizaci, tak je na zvážení použít místo toho EAP-MSCHAPv2 neboli PEAPv0. Což je MSCHAP vložený do TLS chráněné EAP sekvence, kde se prvně udělá TLS tunel, tak to zabrání možnosti pasivního odposlechu. Pokud je korektně řízeno ověřování certifikátů a správně vše nastavneo, tak je to odolné i aktivním zásahům do komunikace. Bohužel ne vše to umí a podporuje. ROS např pro PPP přenosy sám o sobě ne.
Takže pokud se použije PPTP a nahradí se v něm MSCHAP za tunelovanou PEAP variantu, tak je problém v podstatě vyřešen (neob přejít na L2TP/IPsec a dálší).
Vše výše napsané na téma MSCHAP se identicky týká i míst, kde se případně používá NTLM autorizace, takže občas firemní IMAP/SMTP/HTTP/proxy/Exchange/CIFS/... pokud opět není nacpáno do TLS tunelu. Proto i zde se snaží už přes 10 let NTLM Microsoft pohřbít ve prospěch Kerberosu (nícmeně i ten Kerberos, pokud máte povoleny tickety s DES a ne něčím lepším, tkaé dlouho neodolají)...
Poznámka k tomu, pokud od PPTP uteču k L2TP/IPSec, tka máte vyhráno, pokud nepoužijete IPsec s povleným aggresive mód vyjendávání IKEv1. Pokud je to povoleno a pro ověřování se používá sdílené heslo, tak je to ještě větší průšvih, než holé PPTP. Protože v případě PPTP musím být v cestě komunikac,e abych tu úvodní MSCHAP sekvenci chytil, v případě agresivního IKEv1, zkrátka požádám odkudkoliv výzvou a server mi hashe k luštění poskytne sám a nemusím hackovat se někde do routerů po cestě. Pokud se používá asymetrické ověřování (ť už s X.609 certifikáty nebo RSA klíči), talk je to OK, stejně tak je OK, pokud je povolen pouze main režim s PSK.
Takže já zůstávám klidný a dál si užívám výhod MSCHAP tím, jak je přes nthashe svázán s centrální autorizací ve woknech. Samozžejmě proto, že pro 802.1x a wifi varianty to mám výhradně v PEAP režimu (s nuceným ověřováním certifikátů radius serverů) a pro VPNka dávno už jen L2TP/IPsec variantou s použitím certifikátů pro IPsec vrtstvu a vnořené PPP už s MSCHAP je v klidu...
Zpět k holému CHAPu...
Tam je situace jiná a nebl bych se ho, pokud nemáš za zaměstnavatele NBÚ a podobné spolky. Funguje tak, že server pošle výzvu, ta je dvousložková, první číást je náhoný řetězec, který by se neměl ideálně vícekrát opakovat a druhá část je pevný identifikátor daného serveru (takže třeba jeho jméno, u Cisco beden např to, co nastavím přes "ppp chap hostname XXX"), klient odpovídá tám, že posílá čistý text přihlašovací jméno a za tím MD5 hsh spočítaný přes logině složky výzvy. Server si ověří zda to sedí a je to. Toto při pasivním odposlechu normálně nedáš přes brute force v přijatelném čase, pokud nejsi parchaňtě štěstěny. Problém je, že v MD5 je už známo dost postupůpro dohledávání některých bitů a diferenciální analýza, takže proto u CHAP se dá výrazně zvýšit šance na úspěch pomocí aktivního útoku, který využívá toho, co zavedl CHAP, že při použití CHAPu se může ověřování průběžně opakovat během komunikace v PPP vrstvě (jako ochrana proti prostému únosu spojení). Takže unesu spojení k sobě, nechám klienta s PPP data projít k serveru, uvodní autorizace mě nechává klidným a po chvilce začnu vkládat do PPP autorizační CAP vyzvy ke klientovi tak, že se pužije sada správně vybraných těch výzev, klient odpovídá hashem, to zase odeberu (PPP datové rámce propouštím oběma směry, stejně tak reautorizace od serveru, ať ani jenda strana nevyjde z konceptu) a na základě toho se dá s určitou pravděpodobností prvně dohledat délku hesla a následně dají odhadovat některé bity toho hesla a následný už cíleny bruteforce místo 2^128 je o řády níže, ale pořád je to o hodně řádí výše a bez garance úspěšného dohledání, než to MSCHAP zmíněné výše. Navíc to už vyžaduje viset ve spojení, a to dost dlouho.
Takže s klasickým CHAPem bych byl relativně klidný (pokud třeba řešíš, co povolit za protokoly v PPPoE)...
Tak tomu captive portálu, tím se snaží obejít tu možnost jendoduxhého odposlechu MSCHAP sekvence, jednoduché a pokud je prováděno a omezeno ověřování certifikátů, tak i účinné ve Wifi síti.
Vše výše zmíněno je lehce zjednodušeno, jde o princip a o to, že v sobotu večer je třeba chlastat a ne psát vědecké práce...