Dans la première étape,
l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à
l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur
de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue
et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur.
Le KDC fournit alors à l’utilisateur son TGT (étape 2).
L’utilisateur peut alors fournir le
TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le
TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et
lui fournir un TGS pour le service demandé (étape 4).
Enfin, l’utilisateur transmet ce
TGS comme preuve de son identité auprès du service (étape 5).
Dans le protocole Kerberos, ce sont
donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur,
au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une
authentification classique.
Introduction
aux délégations Kerberos
Microsoft a introduit les
délégations Kerberos dans l’objectif de permettre à une application de
réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée
sur un serveur différent. Un cas d’usage est par exemple l’accès à des
documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès
direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint
qui doit alors transmettre l’identité de l’utilisateur au serveur de
fichiers.
Cependant, les tickets de service
étant délivrés pour une application spécifique, le SharePoint ne peut
transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc
pour répondre à cette problématique que Microsoft a mis en place les
délégations Kerberos, qui existent sous deux formes :
- Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
- Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.
Les
délégations Kerberos non contraintes
Le schéma d’authentification d’un
utilisateur désirant accéder à une ressource dans le cas d’une délégation
Kerberos non contrainte est le suivant :

Lors de la première étape de ce
schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de
domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de
son mot de passe. Après avoir validé son identité, le contrôleur de domaine
fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une
authentification Kerberos classique.
Pour s’authentifier auprès de
l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de
domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le
cas d’une délégation Kerberos non contrainte, le contrôleur de domaine
construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide
du hash NTLM du mot de passe du compte de service utilisé par l’application
SharePoint (étape 4).
L’utilisateur s’authentifie alors
sur l’application SharePoint (étape 5) en transmettant le TGS que lui a
fourni le contrôleur de domaine lors de l’étape précédente.
Le compte de service de
l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré
avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut
fournir au contrôleur de domaine pour effectuer une demande de TGS pour le
serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS
renvoyé par le contrôleur de domaine (étape 7) représente son identité, et
non celle du compte de service.
Le compte de service de
l’application SharePoint peut alors transmettre ce TGS (étape 8), que le
serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même,
donnant accès au document demandé (étape 9). Ayant récupéré ce
document, l’application SharePoint peut le fournir à l’utilisateur, pour
lequel les phases d’authentification intermédiaires auront été transparentes.
Les
délégations Kerberos contraintes
Dans le cas d’une délégation
Kerberos contrainte, deux extensions de protocole sont utilisées pour
permettre à une application de réutiliser l’identité de l’un de ses
utilisateurs :
S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.
S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.
La cinématique d’authentification
et d’accès aux ressources dans le cas d’une telle délégation est alors la
suivante :

Dans la première étape de cette
cinématique, l’utilisateur s’authentifie après du premier service en lui
transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur
n’a pas besoin de s’authentifier auprès du contrôleur de domaine.
Le compte de service demande alors
un TGS représentant l’identité de l’utilisateur et permettant de
s’authentifier auprès de son propre service (étape 2). Le compte de service
possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket
(étape 3).
Ce même compte de service demande
ensuite un TGS représentant l’identité de l’utilisateur et permettant de
s’authentifier auprès du second service (étape 4). Après validation de
l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)
Grâce à ce second ticket de
service, le compte de service du SharePoint peut accéder aux ressources du
serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de
fichiers valide les privilèges de l’utilisateur, et transmet le document
demandé au compte de service SharePoint (étape 7), qui le transmet à
l’utilisateur (étape 8).
Contrairement au cas des délégations
non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet
de spécifier les services accessibles au compte de service SharePoint. Ainsi,
même si l’utilisateur dispose des privilèges nécessaires pour accéder à un
autre serveur, le compte de service ne pourra récupérer de TGS valide
représentant l’identité de l’utilisateur. Dans le cas d’une délégation
contrainte, cette restriction se fait à l’aide d’un paramètre du compte de
service, appelé SPN pour Service Principal Name.
Il est à noter que depuis la
version Serveur 2012 du système d’exploitation Windows, un troisième type de
délégation Kerberos est proposée, les délégations Kerberos contraintes basées
sur les ressources. Le fonctionnement de ces délégations est similaire à celui
des délégations contraintes, mais la restriction est effectuée en spécifiant
explicitement le compte ayant accès aux ressources.
Exploiter
les délégations non contraintes
Les faiblesses induites par les
délégations Kerberos non-contraintes sont connues depuis plusieurs années.
Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la
Black Hat USA 2015. Dans la cinématique d’authentification présentée
précédemment, il est en effet évident que le compte de service de
l’application SharePoint peut, une fois que l’utilisateur lui a transmis un
TGS contenant son TGT, accéder à l’ensemble des services pour lesquels
l’utilisateur dispose de privilèges nécessaires.
L’objectif d’un attaquant est alors
d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se
connecter au contrôleur de domaine avec les privilèges maximum pour changer
le mot de passe du compte krbtgt afin de pouvoir forger ses propres
tickets à la demande.
Pour parvenir à cela, il est
d’abord nécessaire d’identifier les services qui disposent de délégations non
contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory
à la recherche de paramètres TrustedForDelegation valant True.
Ce paramètre indique en effet la présence d’une délégation non contrainte, et
est de plus accessible sans privilège particulier, par exemple à l’aide de la
commande Get-ADComputer du module ActiveDirectory :
PS
C:\> Import-Module ActiveDirectory
PS C:\> Get-ADComputer –Filter {(TrustedForDelegation –eq $True) –and
(PrimaryGroupID –eq 515)}
|
Une fois les services disposant
d’une délégation Kerberos non contrainte identifiés, il est nécessaire
d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils
sont utilisés. Les méthodes de compromission classiques peuvent alors être
utilisées, mais ne seront pas abordées dans cet article.
En cas d’accès au service par un
administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS
fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :
mimikatz # kerberos::list /export
|
Comme indiqué dans le scénario
d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant
pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se
connecter au contrôleur de domaine.
Les recommandations pour protéger
un domaine d’une telle attaque sont alors les suivantes :
- Utiliser des délégations Kerberos contraintes qui sont plus restrictives
- Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation
Dans le cas d’un domaine au niveau
fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité
« Utilisateurs protégés » peut être utilisé pour les comptes à
privilèges étant donné que les délégations ne sont pas autorisées pour les comptes
de ce groupe.
Qu’en
est-il des délégations contraintes ?
L’utilisation de délégations
contraintes semble être une alternative plus sécurisée. Cependant, différents
éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté
Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de
protocole utilisées ont été pensées avec les principes suivants :
- Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
- L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.
De ce fait, un service qui
possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel
autre service en se faisant passer pour un utilisateur, et ce sans nécessiter
son mot de passe.
Matan Hart a publié son outil
« Mystique[1] » qui permet d’identifier des configurations à risque
pour les délégations. Pour cela, il liste les comptes qui disposent du
paramètre TrustedToAuthForDelegation valant True,
indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation
d’un SPN, ce qui est obligatoire pour les comptes de délégation.
Il est également à noter que les
TGS sont validés selon deux critères, le hash du mot de passe de
l’utilisateur, et le SPN possédé par le compte de service qui possède la
délégation contrainte. En cas de multiples SPNs associés à un même compte de
service, et de mot de passe partagé entre différents comptes, les tickets
pour deux services distincts seront complétement interchangeables, ce qui
pourrait permettre à un service de réutiliser l’identité d’un utilisateur de
manière illégitime.
Ces faiblesses ne sont pas
considérées comme des vulnérabilités par Microsoft, et ne sont donc pas
amenées à changer. Lors de la création d’une délégation Kerberos contrainte,
il est alors nécessaire de faire attention aux points suivants pour se
protéger des attaques :
- Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
- Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
- Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.
Conclusion
L’utilisation de délégations
contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de
bien maitriser leur configuration et les ressources auxquelles elles
permettent d’accéder afin d’éviter les travers détaillés dans cet article.
Nicolas DAUBRESSE
Sources :
|
|
|
|
|
|
|
|
|
Excellent article ! Les comptes GMSA ont-ils depuis changé en partie la donne sur le système de délégation ? Je trouve qu'ils correspondent bien aux reco de l'article, mais en même temps je ne sais pas dire à quel point ils sont attaquables.
RépondreSupprimerLes comptes GMSA présentent l'avantage de pouvoir disposer de mots de passe robustes et régulièrement modifiés, et ce sans complexité de gestion pour les administrateurs, puisqu'ils sont gérés de manière automatique. A ce titre, l'utilisation de tels comptes est une bonne recommandation pour la protection de ces comptes de service, considérés comme sensibles (notamment vis-à-vis d'attaques tel que le kerberoasting).
RépondreSupprimerPar contre, il est à noter qu'un compte GMSA peut être utilisé pour différents services (appartenant à un même groupe). Si ces services disposent de plus de SPN ayant la même valeur, les tickets créés seront toujours interchangeables.