Podpora rozšířené ochrany pro ověřování (EPA) ve službě
| Vlastnost | Platí pro |
|---|---|
| EPA | všechny podporované operační systémy Windows |
| Režim auditu EPA | Windows Server 2019 Windows Server 2022 Windows Server 23H2 |
Jaký je problém?
Existuje třída útoků na ověřené služby označované jako útoky přesměrování. Tyto útoky umožňují nežádoucím uživatelům obejít ověřování a jednat jako jiný uživatel. Vzhledem k tomu, že se jedná o útoky na službu a ne na samotný ověřovací protokol, je na ověřené službě, aby zabránila útokům na předávání.
Jak fungují přesměrovací útoky?
Když služba nebo aplikace volá rozhraní API AcceptSecurityContext k ověření klienta, předává datový blok přijatý z volání klienta InitializeSecurityContext. Ověřovací protokol zodpovídá za ověření, že zadaný objekt blob pochází od uvedeného uživatele. AcceptSecurityContext nemůže činit žádná tvrzení o pravosti zbytku zprávy aplikace, kterou neviděl.
Běžnou chybou zabezpečení v aplikacích je považování datového toku aplikace za ověřený po úspěšném ověření blobu vnitřního autentizačního protokolu. Nejčastěji k tomu dochází u aplikací, které používají protokol TLS pro svůj wire protokol. Protokol TLS běžně nepoužívá klientské certifikáty; poskytuje serveru záruky integrity a důvěrnosti, ale ne ověřování. Vnitřní ověřování poskytuje ověření klienta, ale pouze pro jeho blok dat. Neověřuje kanál TLS ani zbytek aplikačního protokolu, který obsahuje.
Útočník provede útok přesměrování zpráv vložením autentizačního blobu z jednoho zdroje s žádostí vytvořené útočníkem. Útočník může například sledovat provoz ověřování v síti a vložit ho do vlastního požadavku na server. Útočník tak získá přístup k serveru jako klient z zachyceného ověřovacího provozu.
Klíčovým konceptem je, že ověřovací zprávy SSPI jsou navrženy tak, aby byly vystaveny na drátě; neočekává se, že budou tajní. To se liší od mnoha schémat ověřování na webu, která používají nosné tokeny, které jsou vždy důvěrné uvnitř kanálů TLS.
Co je řešení?
Upřednostňovaným řešením je použít klíč relace ověřovacího protokolu k podepisování nebo šifrování (MakeSignature, EncryptMessage) jiného přenosu. Vzhledem k tomu, že klíč relace je kryptograficky odvozen během výměny ověřovacího protokolu, je zaručeno, že jeho ověřená data a veškerý provoz chráněný tímto klíčem pochází z ověřeného klienta.
To není vždy možnost. V některých případech je formát zprávy aplikačního protokolu pevně stanoven standardy navrženými pro nosné tokeny. V tomto případě může rozšířená ochrana pro ověřování (EPA), označovaná také jako vazba kanálu, chránit před předáváním přes kanál TLS/SSL.
Co je EPA?
EPA kryptograficky sváže klíč relace TLS s klíčem relace ověřovacího protokolu, což umožňuje protokolu TLS poskytnout stejnou autentizaci klienta jako klíč ověřovacího protokolu. Další informace naleznete v tématu Přehled rozšířené ochrany pro ověřování.
Vazba služby
Druhá část EPA se nazývá Servisní vazba. Na rozdíl od vazby kanálu neposkytuje tato metoda službě kryptografické záruky a slouží jako obrana poslední instance, kde vazbu kanálu nelze použít. Tento mechanismus umožňuje serveru voláním QueryContextAttributes načíst atribut SECPKG_ATTR_CLIENT_SPECIFIED_TARGET, který obsahuje název, který ověřený klient předal do InitializeSecurityContext.
Představte si například službu, která se nachází za TLS ukončujícím vyrovnávačem zatížení. Nemá přístup k klíči relace TLS a může určit pouze z vazby kanálu, že ověřování klienta bylo určeno pro chráněnou službu TLS. Název zadaný klientem by měl být stejný jako název použitý k ověření certifikátu serveru TLS. Ověřením, že klient ověřoval jméno odpovídající certifikátu TLS serveru prostřednictvím nástroje pro vyrovnávání zatížení, získává služba vysokou jistotu, že ověřování pochází od stejného klienta jako kanál TLS.
Tento článek se nebude zabývat tím, jak podporovat vazbu služby. Další informace najdete v části Jak na to: Určení vazby služby v konfiguraci.
Jak podporujete EPA?
Při prosazování EPA mohou služby zaznamenat, že se klienti kvůli problémům s kompatibilitou neověří. Proto jsme vytvořili režim auditu EPA, ve kterém mohou služby povolit auditování, aby mohli správci kontrolovat, jak klienti reagují před vynucováním EPA.
Služby Microsoftu podporující režim auditu zahrnují:
Poznámka
Níže najdete volitelné kroky pro povolení funkce auditu EPA. Mějte na paměti, že povolení funkce auditu EPA bez vynucování EPA nechrání před reléovými útoky. Doporučujeme, aby služby, které se rozhodly nejprve povolit EPA pouze v režimu auditu, posléze podnikly kroky k nápravě nekompatibilních klientů a nakonec přísně vynucovaly EPA, aby se zabránilo potenciálním útokům na přenos.
Poznámka
Vazby kanálu předávané do AcceptSecurityContext nemusí být vazby pouze pro audit, aby se získaly výsledky auditování. Služby mohou spouštět auditní režim, zatímco stále vynucují EPA.
Klient
- Použijte QueryContextAttributes(TLS) k získání vazby kanálu (vyplnění unikátní versus koncový bod).
- Zavolejte InitializeSecurityContexta předejte vazby kanálu v SECBUFFER_CHANNEL_BINDINGS
Server
- Použijte QueryContextAttributes(TLS), stejně jako na klientovi
- (Volitelně) Převeďte na pouze audit pomocí volání SspiSetChannelBindingFlags
- (Volitelně) Přidejte vyrovnávací paměť výsledku vazby kanálu do výstupních vyrovnávacích pamětí pro ASC.
- Zadejte úroveň EPA a další konfigurace voláním AcceptSecurityContext s SECBUFFER_CHANNEL_BINDINGS
- (Volitelně) K řízení chování v mezních případech použijte flagy:
- ASC_REQ_ALLOW_MISSING_BINDINGS – Nezklamejte klienty, kteří vůbec nic neřekli, například staré zařízení třetích stran. Osvícení klienti, kteří nedostali SECBUFFER_CHANNEL_BINDINGS, budou místo ničeho posílat prázdné vazby.
- ASC_REQ_PROXY_BINDINGS – výjimečný případ pro ukončovací nástroje pro vyrovnávání zatížení protokolu TLS. Nemáme SECBUFFER_CHANNEL_BINDINGS, který bychom mohli předat, ale přesto chceme zajistit, aby klienti zadávali požadavky prostřednictvím kanálu TLS. To je nejužitečnější s vazbami služby, aby se zajistilo, že se klient také připojil do kanálu TLS, který odpovídal názvu serveru na našem certifikátu.
Jak prosazujete předpisy EPA?
Jakmile služba podporuje EPA, mohou správci kontrolovat stav EPA od auditu až po úplné vynucení. To poskytuje službám nástroje k vyhodnocení připravenosti jejich ekosystému na EPA, k nápravě nekompatibilních zařízení a k postupnému uplatňování zásad EPA na ochranu jejich prostředí.
Následující atributy a hodnoty lze použít k vynucení různých úrovní EPA ve vašem prostředí:
| Jméno | Popis |
|---|---|
| Žádný | Neprovádí se žádné ověření vazby kanálu. Toto je chování všech serverů, které nebyly aktualizovány. |
| Povolit | Všichni klienti, kteří byli aktualizováni, musí poskytovat informace o vazbě kanálu k serveru. Klienti, kteří nebyli aktualizováni, to nemusí dělat. Jedná se o zprostředkující možnost, která umožňuje kompatibilitu aplikací. |
| Vyžadovat | Všichni klienti musí poskytovat informace o vazbě kanálu. Server odmítne žádosti o ověření od klientů, kteří to neudělají. |
Tyto atributy lze spojit s funkcemi auditu, které shromažďují informace o kompatibilitě zařízení na různých úrovních vynucování EPA. Požadovanou konfiguraci předáte do SspiSetChannelBindingFlags.
- Audit – režim auditování může být použit ve spojení s některou z výše uvedených úrovní vynucování Agentury pro ochranu životního prostředí (EPA).
Jak interpretujete výsledky auditu EPA?
Výsledky auditu jsou soubor bitových příznaků.
| Vlajka | Popis |
|---|---|
| Výsledek_vázání_kanálů_klientská_podpora | Klient uvedl, že je schopen vazeb kanálů. |
| SEC_CHANNEL_BINDINGS_RESULT_ABSENT | Klient neposkytl vázání na vnější kanál. |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH | Vazby klienta označují jiný kanál než server. |
| SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING | Vazba kanálu selhala kvůli SEC_CHANNEL_BINDINGS_RESULT_ABSENT. |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED | Kanály byly úspěšně svázány. |
| SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY | Klient označil vazbu na vnější kanál, který byl předán z důvodu ASC_REQ_PROXY_BINDINGS. |
| Výsledek pro vazby kanálu je platný, ale chybí | Vazba kanálu byla předána z důvodu ASC_REQ_ALLOW_MISSING_BINDINGS. |
Existují také definice pro sady bitů:
| Vlajka | Popis |
|---|---|
| SEC_CHANNEL_BINDINGS_RESULT_VALID | Používá se k testování všech SEC_CHANNEL_BINDINGS_VALID_* případů. |
| Výsledek vázání kanálu (SEC_CHANNEL_BINDINGS_RESULT_NOTVALID) není platný | Používá se k testování všech SEC_CHANNEL_BINDINGS_NOTVALID_* případů. |
Průběh auditu
Jakýkoli operační systém, který podporuje výsledky, vždy nastaví alespoň jeden bit z SEC_CHANNEL_BINDINGS_RESULT_VALID nebo SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.
Selhala vazba kanálu : Zkontrolujte jakékoli bity z SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. U vazeb, které nejsou určeny pouze pro audit, to může vést k selhání ASC s STATUS_BAD_BINDINGS nebo SEC_E_BAD_BINDINGS.
- SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Jak klient, tak server vědí o vazbách kanálu, ale neshodují se ohledně kanálu. Jedná se o případ útoku nebo nesprávnou konfiguraci zabezpečení, která je nerozlišitelná od útoku, protože konfigurace narušila protokol HTTPS pro kontrolu provozu (např. Fiddler). Může se také stát, že klient a server nesouhlasí ohledně rozdílu mezi jedinečnými a koncovými vazbami.
-
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING se rozdělí do dvou případů:
- S SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTto znamená, že klient potvrzuje, že ví o vazbě kanálu a uvádí, že žádný kanál neexistoval. Může se jednat o útok na přeposílání ze služby jiného typu než TLS, ale pravděpodobně jde o neinformovanou aplikaci spuštěnou na klientovi, která používá protokol TLS, ale neinformuje o tom vnitřní ověřování.
- Bez SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTnení klient schopný vazby kanálů. Všechny podporované verze Windows jsou schopné vytvořit vazbu kanálu, takže je to buď třetí strana, nebo systém, který má nastavenou hodnotu registru SuppressExtendedProtection. To je případ, který se změní na SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING, když použijete ASC_REQ_ALLOW_MISSING_BINDINGS.
vázání kanálu bylo úspěšné: Toto je opak kontroly selhání nebo test SEC_CHANNEL_BINDINGS_RESULT_VALID.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED je případ úspěchu. Ochrana zabezpečení funguje (nebo by fungovala, pokud by byla EPA povolena pouze pro audit).
- SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING znamená, že ASC_REQ_ALLOW_MISSING_BINDINGS byl předán, takže jsme povolili klientovi, který neprokázal podporu pro vazbu kanálu. Klienti, kteří na tento případ narazili, nejsou chráněni a měli by být prozkoumány, aby se zjistilo, co je špatně. Je třeba je aktualizovat na podporu vazby kanálu, nebo by měla být hodnota registru SuppressExtendedProtection vymazána po aktualizaci poškozených aplikací.
- SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY je zvláštní případ přidružený k příznaku ASC_REQ_PROXY_BINDINGS, který se používá, když je protokol TLS ukončen na load balanceru místo připojení k serveru. Server nemůže ověřit, že klient používá stejné připojení TLS jako které ukončuje vyrovnávač zatížení. Pro účely auditování se s tím zachází stejně jako s SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.