tenhle článek už nejspíš moc neplatí
Dneska se podívejme na jeden antihekovací problém s HTTPS webovými servery. Není to problém jen alza.cz, na které se to pěkně předvede. Je to problém obecně, můj odhad od oka 99% všech web serverů :-) Alzu jsem si vybral jen proto, že mě přišla dneska rovnou do rány :-)
Jinak mě samozřejmě nejde o hekování webu. Mě se jedná o zabezpečení intranetových web serverů, jako je SharePoint a OWA a jiné business portály.
O co jde? To že web server má HTTPS není ještě žádná paráda. Aspoň něco. Ale může se z toho lehce stát nic.
Takže se podívejte na libovolný webový server, který implementuje HTTPS. Můžete zkusit taky gmail, facebook, nebo azure a MS download, msdn, Office365 apod. Nebo třeba váš vlastní SharePoint nebo OWA. Jak říkám, je to 99%. Všichni umožňují připojovat se přes nezašifrované HTTP a až později přejít na HTTPS. A nevyžadují klientské TLS certifikáty (TLS client certificate authentication).
Jak z toho dostat uživatelovo heslo? Nechceme, nebo nemůžeme dělat HTTPS MITM s podvrhnutým serverovým certifikátem (neboli HTTPS inspection). Nemůžeme, protože by mu klient nevěřil. Ne že by ta červená varování mnoha lidem vadila :-) ale jde to obvykle mnohem nenápadněji. Pomocí HTTPS strip (SSL strip, TLS strip) útoku, což je vlastně downgrade útok (ale v podstatě ne kryptografický, jen protokolový) za pomoci MITM.
HTTPS web servery obvykle umožňují přesměrování
Normální lidé zadávají do prohlížeče obvykle jen jméno serveru, bez předpony HTTPS://. Znamená to, že prohlížeč zkusí primárně jít na nezašifrované HTTP. Je jedno, jestli to jde, nebo to máte na svém web serveru zablokované, nebo tam máte redirect, nebo váš server vrací všechny linky a jiné odkazy jako HTTPS.
Pokud to klient zkusí sám dobrovolně od začátku jen přes HTTP, je proklet. Proč?
Normálně máte na svém TLS/SSL web serveru něco jako 302 redirect na HTTPS. Nebo také uvnitř webových stránek uvádíte odkazy explicitně na HTTPS. Prostě člověk jde na HTTP a ono ho to v odpovědi přesměruje na šifrované HTTPS. Viz. tyto dva obrázky z mého kurzu o PKI a TLS:
Jenže jak říkám, je už od začátku špatně, že jste do adresy zadali místo HTTPS jen nezašifrované HTTP.
HTTPS strip útok pomocí MITM (man in the middle)
Mrkněte se na obrázek:
Vy dobrovolně začnete s nechráněným HTTP. Útočník si stoupne mezi vás a HTTPS server. Všechno co vy pošlete na server přes HTTP, on přehodí na HTTPS. Všechny odpovědi od serveru, které explicitně obsahují zmínky o zabezpečeném HTTPS útočník změní zpět na čísté HTTP.
Pokud se vás web server snaží přesměrovat 302 na šifrované HTTPS, útočník vás prostě něchá na HTTP. Pokud vám server vloží do stránky absolutní odkazy, které vedou na šifrované HTTPS, útočník je prostě jen změní.
A je to.
Jak se proti tomu bránit
Existují alespoň tři metody
- musíte explicitně začít s HTTPS:// prefixem. A potom se musíte ujistit, že ten HTTPS prefix stále vidíte v panelu s adresou. A navíc musí být v Internet Exploreru vidět zámeček (lock icon) vpravo. Ta ikonka je zásadní. Viz. problém s alza.cz.
- webový server vyžaduje ověření uživatele pomocí klientského TLS/SSL certifikátu (tedy TLS client certificate authentication), o čemž jsem tu psal už několikrát - například tady a nedávno tady. Jde o to, že spojení je v takovém případě vzájemně autentizovaná (mutual authentication), útočník v prostředku (MITM) nemá klientský certifikát a může si tedy trhnout nohou.
- pro vnitřní web servery, které ověřují uživatele pomocí Kerberos (nebo i NTLM, když už by to muselo být) by se použila tzv. extended protection for authentication. O tom co nejdříve udělám další článeček, je to velice zajímavá věc. V podstatě se jedná o to, že navážete kerberosové tikety na TLS certifikát web serveru.
Jak jistě poznáte, první metoda vyžaduje uživatelovu dobrou vůli, porozumnění a zodpovědnost. Druhé dvě metody se hodí výborně do vnitřních prostředí, mě se velmi líbí ta druhá, s klientským TLS certifikátem, protože je kompatibilní i se SharePoint. On totiž SharePoint oficiálně extended protection nepodporuje, což je škoda. Zapnout to můžete, ale na vlastní riziko.
Zato klientský certifikát je parádička, která vám i z internetu přinese dokonce single-sign-on (SSO), to je potom krása!
Problém s alza.cz
Proč je tedy problém s alzou? Pokud se tam podíváte, jedete normálně na HTTP. To by tak nevadilo. To je normálka. Tudíž chcete přejít na TLS. Napíšete do adresy https://www.alza.cz a zjistíte, že v panelu ikonka certifikátu (a dokonce zeleného) jen problikne. Skončí to na tom, že v adrese vidíte sice HTTPS prefix, ale už nevidíte vpravo certifikátovou ikonečku.
Co to znamená? Adresa s HTTPS bez ikonky certifikátu? Odpověď vám dá například Developer Toolbar F12 v Internet Exploreru, přesněji jeho Network záložka. Když si nachytáte komunikaci mezi sebou a web serverem, zjistíte, že plno elementů stránky, jako jsou obrázky nebo skripty, se stahují buď úplně bez šifrování přes čisté HTTP, nebo z jiného HTTPS serveru.
Prohlížeč nemůže garantovat, že certifikátem je všechno zabezpečeno a prostě ho nezobrazí. Prefix HTTPS:// tam zůstane, protože základní HTML je opravdu na této adrese.
Takže nemáte žádnou informaci o tom, co vlastně je přes HTTPS a co není. Jste si jistí, že přihlašovací javascript, který vám zobrazí přihlašovací okénko dorazil přes šifrované spojení? Nemají to dokonce ani možno otevřít jako samostatnou stránku, takže víte v celku prd. To byste sice nevěděli, ani kdyby to samostatná stránka byla, ale přecejenom by to mohlo být zřetelnější.
Takže zde ani vlastní sebeochrana uživatele proti SSL strip útoku nefunguje.
Závěrem
Snažte se vždycky kontrolovat ikonku certifikátu a HTTPS:// prefix. Pokud to jde, použijte klientské certifikáty, nebo si přečtete zítra o Extended Protection v IIS za přispění Kerberos.