Ondersteuning voor Extended Protection for Authentication (EPA) in een service

2025-03-22

Kenmerk	Van toepassing op
EPA	alle ondersteunde Windows-besturingssystemen
EPA-controlemodus	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Wat is het probleem?

Er is een klasse van aanvallen op geverifieerde services die doorstuuraanvallen worden genoemd. Met deze aanvallen kunnen kwaadwillende personen verificatie omzeilen en fungeren als een andere gebruiker. Omdat dit aanvallen zijn op de service en niet het verificatieprotocol zelf, is het aan de geverifieerde service om doorstuuraanvallen te verhinderen.

Hoe werken doorstuuraanvallen?

Wanneer een service of toepassing de API AcceptSecurityContext aanroept om een client te verifiëren, wordt een blob met gegevens doorgegeven die zijn ontvangen van de aanroep van de client naar InitializeSecurityContext. Het verificatieprotocol is verantwoordelijk voor het controleren of de opgegeven blob afkomstig is van de aangegeven gebruiker. AcceptSecurityContext kan geen beweringen doen over de echtheid van de rest van het toepassingsbericht dat niet is weergegeven.

Een veelvoorkomende beveiligingsfout in toepassingen is het behandelen van het toepassingsverkeer als geverifieerd na een geslaagde verificatie van de blob van het interne verificatieprotocol. Dit gebeurt meestal bij toepassingen die TLS gebruiken voor hun wire-protocol. TLS maakt doorgaans geen gebruik van clientcertificaten; het biedt de server integriteits- en vertrouwelijkheidsgaranties, maar geen verificatie. De interne authenticatie biedt clientauthenticatie, maar alleen voor de blob. Hiermee wordt het TLS-kanaal of de rest van het toepassingsprotocol daarin niet geverifieerd.

Een aanvaller voert een doorstuuraanval uit door een verificatie-blob vanuit één bron in te voegen met een door aanvaller samengestelde aanvraag. Een aanvaller kan bijvoorbeeld verificatieverkeer op het netwerk observeren en dit invoegen in een eigen aanvraag op de server. Hierdoor kan de aanvaller toegang krijgen tot de server als ware hij de client vanuit het vastgelegde verificatieverkeer.

Het belangrijkste concept hier is dat SSPI-verificatieberichten zijn ontworpen om te worden weergegeven op de kabel; ze worden naar verwachting niet geheim gehouden. Dit verschilt van veel webgebaseerde verificatieschema's die gebruikmaken van bearer-tokens die altijd vertrouwelijk blijven binnen TLS-kanalen.

Wat is de oplossing?

De voorkeursoplossing is om de sessiesleutel van het verificatieprotocol te gebruiken om ander verkeer te ondertekenen of te versleutelen (MakeSignature, EncryptMessage) te ondertekenen of te versleutelen. Omdat de sessiesleutel cryptografisch is afgeleid tijdens het uitwisselen van het verificatieprotocol, zijn geverifieerde gegevens en verkeer dat door die sleutel wordt beveiligd, is gegarandeerd afkomstig van de geverifieerde client.

Dit is niet altijd een optie. In sommige gevallen wordt de indeling van het toepassingsprotocolbericht vastgesteld volgens standaarden die zijn ontworpen voor bearer-tokens. In dit geval kan Extended Protection for Authentication (EPA), ook wel Channel Binding genoemd, bescherming bieden tegen doorsturen via een TLS/SSL-kanaal.

Wat is EPA?

EPA verbindt de TLS-sessiesleutel cryptografisch met de sessiesleutel van het verificatieprotocol, zodat TLS dezelfde clientverificatie kan bieden als de sleutel van het verificatieprotocol. Zie Uitgebreide beveiliging voor verificatieoverzicht voor meer informatie.

Service binding

Het tweede deel van EPA wordt Service Binding genoemd. In tegenstelling tot kanaalbinding biedt dit de service geen cryptografische garanties en fungeert als een verdediging van laatste redmiddel waarbij kanaalbinding niet mogelijk is. Met dit mechanisme kan de server QueryContextAttributes- aanroepen om het kenmerk op te halen SECPKG_ATTR_CLIENT_SPECIFIED_TARGET die de naam bevat die de geverifieerde client heeft doorgegeven aan InitializeSecurityContext.

Stel bijvoorbeeld dat een service zich achter een TLS-beëindigende load balancer bevindt. Het heeft geen toegang tot de TLS-sessiesleutel en kan alleen bepalen vanuit de kanaalbinding dat de verificatie van de client is bedoeld voor een met TLS beveiligde service. De naam die door de client wordt opgegeven, moet dezelfde naam zijn als de naam die wordt gebruikt om het TLS-servercertificaat te valideren. Door te controleren of de client authenticeert naar een naam die overeenkomt met het server TLS-certificaat via de load balancer, krijgt de service hoge zekerheid dat de authenticatie afkomstig is van dezelfde client als het TLS-kanaal.

In dit artikel wordt niet besproken hoe u servicebinding kunt ondersteunen. Zie Procedure: Een servicebinding opgeven in configuratie- voor meer informatie.

Hoe ondersteunt u EPA?

Bij het afdwingen van EPA kunnen services merken dat klanten zich niet kunnen authenticeren vanwege compatibiliteitskwesties. Daarom hebben we een EPA-auditmodus gemaakt waarin services auditing kunnen inschakelen, waardoor beheerders de mogelijkheid hebben om te observeren hoe clients reageren voordat ze de EPA afdwingen.

Microsoft-services die de controlemodus ondersteunen, zijn onder andere:

LDAP

Notitie

Hieronder vindt u optionele stappen om DE AUDITfunctionaliteit van EPA in te schakelen. Houd er rekening mee dat het inschakelen van EPA-auditfunctionaliteit zonder het afdwingen van EPA-beleid geen bescherming biedt tegen relayaanvallen. We raden aan dat diensten die ervoor kiezen om EPA alleen in de auditmodus in te schakelen, later stappen ondernemen om incompatibele clients te herstellen en uiteindelijk EPA strikt handhaven om mogelijke relayaanvallen te voorkomen.

Notitie

De kanaalbindingen die zijn doorgegeven aan AcceptSecurityContext- hoeven geen alleen-auditbindingen te zijn om de auditresultaten te verkrijgen. Services kunnen de auditmodus uitvoeren terwijl EPA nog steeds wordt afgedwongen.

Klant

Gebruik QueryContextAttributes(TLS) om kanaalbindingen op te halen (vul een uniek versus eindpunt in)
Roep InitializeSecurityContext-aan en geef kanaalbindingen door in SECBUFFER_CHANNEL_BINDINGS

Server

Gebruik QueryContextAttributes(TLS), zoals op de client
Zet optioneel om naar alleen-audit door de functie SspiSetChannelBindingFlags aan te roepen.
(Optioneel) Voeg resultaatbuffer voor kanaalbinding toe aan uitvoerbuffers voor ASC.
Geef het EPA-niveau en andere configuraties op door AcceptSecurityContext- aan te roepen met SECBUFFER_CHANNEL_BINDINGS
(Optioneel) Gebruik parameters om het gedrag in randgevallen te beheren.
- ASC_REQ_ALLOW_MISSING_BINDINGS - Laat cliënten niet falen die helemaal niets zeiden, zoals oude apparaten van externe partijen. Geïnformeerde clients die niet SECBUFFER_CHANNEL_BINDINGS krijgen, verzenden een lege binding in plaats van niets.
- ASC_REQ_PROXY_BINDINGS - een zeldzaam geval voor TLS-afsluitende load balancers. We hebben geen SECBUFFER_CHANNEL_BINDINGS om door te geven, maar willen nog steeds afdwingen dat clients aanvragen in een TLS-kanaal plaatsen. Dit is het handigst bij servicebindingen om ervoor te zorgen dat de client ook een TLS-kanaal heeft ingevoerd waarvoor het servercertificaat overeenkomt met onze naam.

Hoe handhaaft u EPA?

Zodra een service EPA ondersteunt, kunnen beheerders de EPA-status helemaal beheren, van controle tot volledige afdwinging. Dit biedt services de hulpmiddelen om de gereedheid van hun ecosysteem voor EPA te evalueren, incompatibele apparaten te herstellen en EPA geleidelijk af te dwingen om hun omgeving te beschermen.

De volgende kenmerken en waarden kunnen worden gebruikt om verschillende niveaus van EPA in uw omgeving af te dwingen:

Naam	Beschrijving
Geen	Er wordt geen validatie van kanaalbindingen uitgevoerd. Dit is het gedrag van alle servers die niet zijn bijgewerkt.
Toestaan	Alle clients die zijn bijgewerkt, moeten kanaalbindingsinformatie verstrekken aan de server. Clients die niet zijn bijgewerkt, hoeven dit niet te doen. Dit is een tussenliggende optie waarmee toepassingscompatibiliteit mogelijk is.
Vereisen	Alle clients moeten informatie over kanaalbinding opgeven. De server weigert verificatieaanvragen van clients die dit niet doen.

Deze kenmerken kunnen worden gekoppeld aan de controlefunctionaliteit om informatie te verzamelen over apparaatcompatibiliteit op verschillende niveaus van EPA-afdwinging. U geeft de gewenste configuratie door aan SspiSetChannelBindingFlags.

Audit - Controlemodus kan worden gebruikt in combinatie met een van de bovenstaande EPA-afdwingingsniveaus.

Hoe interpreteer je DE auditresultaten van EPA?

Controleresultaten zijn een set bitvlagken:

Vlag	Beschrijving
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	De client heeft aangegeven dat het geschikt is voor kanaalbindingen.
SEC_CHANNEL_BINDINGS_RESULT_AFWEZIG	De client heeft geen binding met een extern kanaal opgegeven.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	De clientbindingen geven een ander kanaal aan dan de server.
There are no changes to be made as the translation is already faithful to the context of system error codes or technical identifiers.	De kanaalbinding is mislukt vanwege SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	De kanalen zijn succesvol gekoppeld.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	De client heeft een binding aangegeven met een extern kanaal, wat is doorgegeven door ASC_REQ_PROXY_BINDINGS.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Kanaalbinding is geslaagd vanwege ASC_REQ_ALLOW_MISSING_BINDINGS.

Er zijn ook definities voor verzamelingen bits:

Vlag	Beschrijving
SEC_CHANNEL_BINDINGS_RESULT_VALID	Wordt gebruikt om te testen voor alle gevallen van SEC_CHANNEL_BINDINGS_VALID_*.
SEC_KANAAL_BINDINGS_RESULT_NIET_GELDIG	Wordt gebruikt om te testen op alle SEC_CHANNEL_BINDINGS_NOTVALID_* gevallen.

Auditproces

Elk besturingssysteem dat de resultaten ondersteunt, stelt altijd ten minste één bit uit SEC_CHANNEL_BINDINGS_RESULT_VALID en SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

-kanaalbinding is mislukt: controleer op bits uit SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Voor bindingen die niet alleen voor controle zijn, betekent dit dat ASC mislukt met STATUS_BAD_BINDINGS of SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: De client en server weten beiden van kanaalbindingen, maar zijn het niet eens over het kanaal. Dit is de aanvalscase of een onjuiste beveiligingsconfiguratie die niet kan worden onderscheiden van een aanval, omdat de configuratie HTTPS heeft aangetast om verkeer te inspecteren (bijvoorbeeld Fiddler). Het kan ook de client en server zijn die het niet eens zijn over unieke versus eindpuntbindingen.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING is opgesplitst in twee gevallen:
- Met SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTbetekent dit dat de client aangeeft dat het op de hoogte is van kanaalbindingen en aangeeft dat er geen kanaal is. Dit kan een doorstuuraanval zijn van een niet-TLS-service, maar het is waarschijnlijk een onwetende toepassing die op de client draait, doet TLS maar deelt de interne authenticatie daar niet over mee.
- Zonder SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORTis het een client die geen kanaalbindingen kan gebruiken. Alle ondersteunde Windows-versies zijn geschikt voor kanaalbinding, dus dit is een derde partij of een systeem waarop de registerwaarde SuppressExtendedProtection is ingesteld. Dit is het geval dat is veranderd in SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING als u ASC_REQ_ALLOW_MISSING_BINDINGSdoorgeeft.

Kanaalbinding is geslaagd: Dit is de inverse van de controle op falen ofwel de test op SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED is het succesgeval. De beveiliging werkt (of zou werken als EPA is ingeschakeld in alleen-audit modus).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING betekent dat ASC_REQ_ALLOW_MISSING_BINDINGS werd doorgegeven, dus hebben we een client geaccepteerd die geen ondersteuning aangaf voor kanaalbinding. Klanten die met deze situatie te maken hebben, zijn niet beschermd en moeten onderzocht worden om na te gaan wat er mis is. Ze moeten worden bijgewerkt om kanaalbinding te ondersteunen of de registerwaarde SuppressExtendedProtection moet worden gewist zodra de verbroken toepassingen zijn bijgewerkt.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY is een speciaal geval dat is gekoppeld aan de vlag ASC_REQ_PROXY_BINDINGS die wordt gebruikt wanneer TLS wordt beëindigd bij een load balancer in plaats van de server te bereiken. Het is niet mogelijk dat de server controleert of de client dezelfde TLS-verbinding gebruikt als die is beëindigd bij de load balancer. Voor controledoeleinden wordt dit behandeld als SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.