Prise en charge de la protection étendue de l’authentification (EPA, Extended Protection for Authentication) dans un service

Article
10/25/2023

Fonction	S’applique à
EPA	tous les systèmes d’exploitation Windows pris en charge
Mode d’audit EPA	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Quel est le problème ?

Il existe une classe d’attaques sur les services authentifiés appelés attaques de transfert. Ces attaques permettent aux adversaires de contourner l’authentification et d’agir en tant qu’un autre utilisateur. Étant donné qu’il s’agit d’attaques sur le service et non sur protocole d’authentification lui-même, il appartient au service authentifié de contrecarrer les attaques de transfert.

Comment fonctionnent les attaques de transfert ?

Lorsqu’un service ou une application appelle l’API AcceptSecurityContext pour authentifier un client, il transmet un blob de données reçues de l’appel du client à InitializeSecurityContext. Le protocole d’authentification est chargé de vérifier que le blob fourni provient de l’utilisateur indiqué. AcceptSecurityContext ne peut pas faire d’assertions sur l’authenticité du reste du message d’application qu’il n’a pas vu.

Une erreur de sécurité courante dans les applications traite le trafic de l’application comme authentifié après une authentification réussie du blob du protocole d’authentification interne. Cela se produit le plus souvent avec les applications qui utilisent TLS pour leur protocole filaire. TLS n’utilise généralement pas de certificats clients ; il fournit au serveur des garanties d’intégrité et de confidentialité, mais pas l’authentification. L’authentification interne fournit une authentification cliente, mais uniquement pour son blob. Il n’authentifie pas le canal TLS ou le reste du protocole d’application qu’il contient.

Un attaquant exécute une attaque de transfert en insérant un blob d’authentification à partir d’une source avec une requête créée par un attaquant. Par exemple, un attaquant peut observer le trafic d’authentification sur le réseau et l’insérer dans sa propre requête au serveur. Cela permet à l’attaquant d’accéder au serveur en tant que client à partir du trafic d’authentification capturé.

Le concept clé ici est que les messages d’authentification SSPI sont conçus pour être exposés sur le câble ; ils ne sont pas censés être gardés secrets. Cela diffère de nombreux schémas d’authentification web qui utilisent des jetons du porteur qui sont toujours conservés confidentiels dans les canaux TLS.

Quelle est la solution ?

La solution préférée consiste à utiliser la clé de session du protocole d’authentification pour signer ou chiffrer (MakeSignature, EncryptMessage) d’autres trafics. Étant donné que la clé de session est dérivée par chiffrement pendant l’échange de protocole d’authentification, ses données authentifiées et tout trafic protégé par cette clé est garanti à partir du client authentifié.

Il ne s’agit pas toujours d’une option. Dans certains cas, le format du message de protocole d’application est résolu par des normes conçues pour les jetons du porteur. Dans ce cas, la protection étendue de l’authentification (EPA), également appelée liaison de canal, peut protéger contre le transfert via un canal TLS/SSL.

Qu’est-ce que l’EPA ?

L’EPA lie par chiffrement la clé de session TLS à la clé de session du protocole d’authentification, ce qui permet à TLS de fournir la même authentification client que la clé du protocole d’authentification. Pour plus d’informations, consultez La vue d’ensemble de la protection étendue de l’authentification.

liaison de service

La deuxième partie de l’EPA est appelée Liaison de service. Contrairement à la liaison de canal, cela ne fournit pas au service des garanties de chiffrement et sert de défense du dernier recours où la liaison de canal n’est pas possible. Ce mécanisme permet au serveur d’appeler QueryContextAttributes pour récupérer l’attribut SECPKG_ATTR_CLIENT_SPECIFIED_TARGET qui contient le nom du client authentifié passé à InitializeSecurityContext.

Par exemple, imaginez un service résidant derrière un TLS en train de terminer un équilibreur de charge. Il n’a pas accès à la clé de session TLS et ne peut déterminer qu’à partir de la liaison de canal que l’authentification du client a été destinée à un service protégé TLS. Le nom fourni par le client doit être le même que celui utilisé pour valider le certificat de serveur TLS. En vérifiant que le client s’authentifie auprès d’un nom correspondant au certificat TLS du serveur à partir de l’équilibreur de charge, le service gagne en confiance que l’authentification provient du même client que le canal TLS.

Cet article ne explique pas comment prendre en charge la liaison de service. Pour plus d’informations, consultez : spécifier une liaison de service pendant la configuration.

Comment prenez-vous en charge l’EPA ?

Lors de l’application de l’EPA, les services peuvent remarquer que les clients ne parviennent pas à s’authentifier en raison de problèmes de compatibilité. Par conséquent, nous avons créé un mode d’audit EPA dans lequel les services peuvent activer l’audit, ce qui permet aux administrateurs d’observer la façon dont les clients répondent avant d’appliquer l’EPA.

Les services Microsoft prenant en charge le mode d’audit sont les suivants :

LDAP

Remarque

Vous trouverez ci-dessous des étapes facultatives pour activer la fonctionnalité d’audit EPA. Notez que l’activation de la fonctionnalité d’audit EPA sans appliquer l’EPA ne protège pas contre les attaques de relais. Nous vous recommandons que les services, qui choisissent d’activer l’EPA en mode audit uniquement, prennent des mesures ultérieures pour corriger les clients incompatibles et éventuellement appliquer strictement l’EPA pour éviter les attaques de relais potentielles.

Remarque

Les liaisons de canal transmises à AcceptSecurityContext n’ont pas besoin d’être des liaisons d’audit uniquement pour obtenir les résultats de l’audit. Les services peuvent exécuter le mode d’audit tout en appliquant l’EPA.

Client

Utiliser QueryContextAttributes(TLS) pour obtenir des liaisons de canal (remplir liaison unique ou de point de terminaison)
Appelez InitializeSecurityContextet passez des liaisons de canal dans SECBUFFER_CHANNEL_BINDINGS

Serveur

Utilisez QueryContextAttributes(TLS), comme sur le client
(Facultatif) Effectue un audit uniquement en appelant SspiSetChannelBindingFlags
(Facultatif) Ajoutez la mémoire tampon de résultat de liaison de canal aux mémoires tampons de sortie pour ASC.
Spécifiez le niveau EPA et d’autres configurations en appelant AcceptSecurityContext avec SECBUFFER_CHANNEL_BINDINGS
(Facultatif) Utilisez des indicateurs pour contrôler le comportement dans les cas particuliers :
- ASC_REQ_ALLOW_MISSING_BINDINGS : ne faites pas échouer les clients qui n’ont rien dit du tout, comme les anciens appareils tiers. Les clients éclairés qui n’ont pas obtenu SECBUFFER_CHANNEL_BINDINGS envoient une liaison vide plutôt que rien.
- ASC_REQ_PROXY_BINDINGS : cas rare d’un TLS qui termine des équilibreurs de charge. Nous n’avons pas de SECBUFFER_CHANNEL_BINDINGS à passer, mais nous voulons toujours appliquer les requêtes envoyées par les clients dans un canal TLS. Cela est le plus utile avec les liaisons de service pour vous assurer que le client est également entré dans un canal TLS pour lequel le certificat de serveur correspond à notre nom.

Comment appliquer l’EPA ?

Une fois qu’un service prend en charge l’EPA, les administrateurs peuvent contrôler l’état de l’EPA jusqu’à l’application complète de l’audit. Cela permet aux services d’évaluer la préparation de leur écosystème pour l’EPA, de corriger les appareils incompatibles et d’appliquer progressivement l’EPA pour protéger leur environnement.

Les attributs et valeurs suivants peuvent être utilisés pour appliquer différents niveaux d’EPA dans votre environnement :

Nom	Description
Aucun	Aucune validation de liaison de canal n’est exécutée. Il s'agit du comportement de tous les serveurs qui n'ont pas été mis à jour.
Autoriser	Tous les clients qui ont été mis à jour doivent fournir les informations de liaison de canal au serveur. Les clients qui n'ont pas été mis à jour n'ont pas à le faire. Il s'agit d'une option intermédiaire qui permet la compatibilité des applications.
Obligatoire	Tous les clients doivent fournir des informations de liaison de canal. Le serveur rejette les demandes d'authentification émanant des clients qui ne se soumettent pas à cette obligation.

Ces attributs peuvent être couplés à des fonctionnalités d’audit pour collecter des informations sur la compatibilité des appareils à différents niveaux d’application de l’EPA. Vous transmettez votre configuration souhaitée à SspiSetChannelBindingFlags.

Audit : le mode audit peut être utilisé conjointement avec l’un des niveaux d’application de l’EPA ci-dessus.

Comment interpréter les résultats de l’audit EPA ?

Les résultats de l’audit sont un ensemble d’indicateurs de bits :

Indicateur	Description
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	Le client a indiqué qu’il est capable de liaisons de canal.
SEC_CHANNEL_BINDINGS_RESULT_ABSENT	Le client n’a pas fourni de liaison à un canal externe.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	Les liaisons clientes indiquent un canal différent du serveur.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	Échec de la liaison de canal en raison de SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	Les canaux ont été correctement liés.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	Le client a indiqué la liaison à un canal externe, qui est passé en raison de ASC_REQ_PROXY_BINDINGS.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Liaison de canal transmise en raison de ASC_REQ_ALLOW_MISSING_BINDINGS.

Il existe également des fichiers de définitions pour les ensembles de bits :

Indicateur	Description
SEC_CHANNEL_BINDINGS_RESULT_VALID	Utilisé pour tester tous les cas SEC_CHANNEL_BINDINGS_VALID_*.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Utilisé pour tester tous les cas SEC_CHANNEL_BINDINGS_NOTVALID_*.

Flux d’audit

Tout système d’exploitation qui prend en charge les résultats définit toujours au moins un bit de SEC_CHANNEL_BINDINGS_RESULT_VALID et SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

Échec de la liaison de canal : testez les bits de SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Pour les liaisons qui ne sont pas uniquement d’audit, cela correspond à l’échec d’ASC avec STATUS_BAD_BINDINGS ou SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH : le client et le serveur connaissent les liaisons de canal, mais ne sont pas d’accord sur le canal. Il s’agit du cas d’attaque ou d’une configuration de sécurité incorrecte qui est impossible à distinguer d’une attaque, car la configuration a compromis HTTPS pour inspecter le trafic (par exemple, Fiddler). Il peut également s’agir du client et du serveur en désaccord sur les liaisons uniques par rapport aux liaisons de point de terminaison.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING fractionne en deux cas :
- Avec SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, cela signifie que le client atteste qu’il connaît les liaisons de canal et qu’il a dit qu’il n’y avait aucun canal. Il peut s’agir d’une attaque de transfert à partir d’un service non-TLS, mais il est probable qu’il s’agit d’une application non éclairée s’exécutant sur le client qui effectue TLS, mais qui ne lui indique pas l’authentification interne.
- Sans SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, il s’agit d’un client qui n’est pas capable de liaisons de canal. Toutes les versions de Windows prises en charge sont capables de liaison de canal. Il s’agit donc d’un système tiers ou d’un système dont la valeur de Registre est définie sur SuppressExtendedProtection. C’est le cas qui est transformé en SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING si vous passez ASC_REQ_ALLOW_MISSING_BINDINGS.

Réussite de la liaison de canal : il s’agit de l’inverse de la vérification de l’échec ou du test de SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED est le cas de réussite. La protection de sécurité fonctionne (ou fonctionne si l’EPA est activé en tant qu’audit uniquement).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING signifie que ASC_REQ_ALLOW_MISSING_BINDINGS a été passé. Nous avons donc autorisé un client qui n’a pas revendiqué la prise en charge de la liaison de canal. Les clients dans ce cas ne sont pas protégés et doivent être examinés pour voir ce qui ne va pas. Ils doivent être mis à jour pour prendre en charge la liaison de canal, ou la valeur de Registre SuppressExtendedProtection doit être effacée une fois les applications endommagées mises à jour.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY est un cas spécial associé à l’indicateur ASC_REQ_PROXY_BINDINGS utilisé lorsque TLS est arrêté à un équilibreur de charge au lieu d’atteindre le serveur. Il n’est pas possible pour le serveur de vérifier que le client utilise la même connexion TLS que celle qui est terminée au niveau de l’équilibreur de charge. À des fins d’audit, cela est traité comme SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.