Právě včera jsem tu uveřnil článek o MITM útocích na HTTP web servery. Ty jsou obvykle chráněny pomocí TLS (ano, cca 15 let se už SSL používá jen jako úplně záložní metoda) a tedy HTTPS. K tomu je zapotřebí certifikát na web serveru, který poskytuje ale jen jednostranné ověření identity serveru. Neposkytuje vzájemné ověření i identity klienta.
Vzájemné ověření klienta a serveru se pro intranetové web servery dosahuje obvykle pomocí windows authentication za pomocí protokolu Kerberos. NTLM vzájemné ověření identity nepostkyje, NTLM ověřuje pouze identitu uživatele. Vzájemné ověření identity uživatele i serveru by se dalo dosáhnout také použitím TLS client certificate authentication, ale o tom tenhle článek není.
Z absence vzájemné autentizace TLS tunelu/kanálu pak vyplývá možnost různých útoků. Například:
- TLS strip attack, jak jsem popisoval zrovna včera
- HTTPS MITM (někdy to dělají i firewally jako HTTPS inspection). Tady se jedná o případ, kdy prostřední útočník (man in the middle) aktivně vstupuje do komunikace, vygeneruje si sám podvržený certifikát serveru a nabídne ho klientovi. Takový "útok" dělají například i testovací a troubleshootovací nástroje, jako je fiddler, nebo nejnovější Microsoft Message Analyser (který používá sám vnitřně fiddler).
U toho MITM útoku se zastavme. Proti podvodníkovi se brání už sám Internet Explorer na straně klienta tím, že obvykle zobrazí červené hlášení, že certifikát útočníka je neplatný. To samozřejmě za předpokladu, že ho nemáte na počítači z nějakého důvodu zdůvěryhodněny, že :-) Takže uživatel by se měl normálně dozvědět, že něco s tím TLS kanálem není v pořádku.
Jenže uživatelé tahle varování odkliknou. Proti tomu, aby vám uživatelé odklikávali taková hlášení, se server sám bránit nemůže. Vy prostě ze strany serveru uživatelův "odklik" neovlivníte. A to je škoda.
I kdyby to uživatel neodkliknul, stejně je pořád ohrožován HTTPS strip útokem, nebo třeba tím, že podvržený certifikát serveru je na jeho počítači důvěryhodný.
Od toho je právě tahle fíčura nazvaná extended protection for authentication. Je to relativně stará novinka, ale neznámá, proto o tom taky píšu. Je to k dispozici jako vylepšení protokolů Kerberos a NTLMv2 na straně klienta (od Windows XP SP3 a Windows 2003 SP2) podle KB968389. Na těchto systémech si to musíte ještě i povolit v registrech hodnotou SuppressExtendedProtection = DWORD = 0.
Ve Windows 7 a Windows 2008 R2 je to už od samého základu.
Jedná se o vylepšení Kerberos a NTLM o to, že se do ověřovacího paketu započítává thumbprint certifikátu, který vidí klient. Pojem "ověřovací paket" znamená v případě NTLM response (pouze NTLMv2) přihešování (HMAC-MD5) do NTLM challenge spolu s heší hesla (MD4). V případě Kerberosu se to hmakne pomocí session key klient-webServer z TGS.
Znamená to, že klient vypočítá ověřovací paket pomocí toho, co sám vidí za serverův certifikát ze svého pohledu. A server na druhé straně si naopak zpočítá co očekává od klienta na základě svého vlastního certifikátu, který si myslí, že by měl klient asi dostat. Pokud to sedí, server klienta přijme.
Výhody?
V případě Kerberos ověření, které je samo o sobě vzdájmené (mutual authentication) to zajistí vazbu vnitřního ověření uživatelského účtu na TLS kanál. Tím se zabrání libovolným MITM útokům.
V případě NTLMv2, které je jen jednostranným ověřením klienta to má navíc efekt vzájemného ověření klienta i serveru - naváže se klientovo ověření na ověření serveru - a máte v podstatě mutual authenticated NTLM :-)
Zapnutí?
Raději bych vynutil rovnou TLS klientské certifikáty, což je méně kompatibilně závislé, totálně standardní a navíc třeba pro SharePoint je to možné udělat pomocí NETSH HTTP tak, že to vůbec neovlivňuje parametry IIS, které SharePoint rád znásilňuje.
Ale pokud máte vnitřní prostředí na Windows 7 a novějších, hurá do toho!