Remédiation aux exploitations de Kerberos
Introduction
Le protocole Kerberos
Kerberos est un protocole d'authentification basé sur des tickets, il permet l'accès au domaine et à ses services. Ce protocole est intégré dans les environnements Windows Active Directory, on présente sa version 5, son équivalent est Net-NTLMv2 que l'on abordera dans un autre document.
Ce document s'adresse à toute personne chargée de la gestion et de la configuration de l'Active Directory au sein d'une entreprise. Que vous soyez administrateur système, responsable de la sécurité ou responsable informatique, ce guide vous accompagnera dans toutes les étapes de configuration de manière simple et compréhensible. Les explications sont appuyées par des captures d'écran pour faciliter la mise en œuvre des recommandations. Dans ce guide, nous utiliserons les zones DNS cyberlab.local pour illustrer les étapes et méthodes de traitement. Vous devrez faire correspondre ces informations avec votre propre contexte d'exécution.
Mécanisme d'accès à un service
L'accès à un service requiert un échange de tickets entre le contrôleur de domaine, l'utilisateur et le service demandé. L'authentification s'effectue en trois phases, décrites ci-dessous.
1. Pré-authentification (ou demande du ticket TGT)
L'utilisateur demande un ticket TGT (Ticket Granting Ticket) en s'authentifiant sur un service du contrôleur de domaine.
2. Demande de ticket de service (ou demande d'un ticket ST)
Ayant le ticket TGT, l'utilisateur fait une demande d'un ticket de service ST au contrôleur de domaine.
3. Demande d'accès au service
Une fois le ticket de service récupéré, l'utilisateur demande l'accès au service en lui envoyant le ticket correspondant. Il peut alors utiliser ce service, étant authentifié sur celui-ci.
Pour en savoir plus, voir le mécanisme détaillé présent en annexe.
Recommandations générales
La première porte d'entrée pour un attaquant est l'authentification d'un utilisateur.
Afin d'éviter une usurpation d'identité pour récupérer un TGT, il faut activer la pré-authentification. L'activation de la pré-authentification doit être configurée sur tous les utilisateurs.
Lors de la récupération d'un ticket de service, une autre vulnérabilité de Kerberos peut être exploitée pour obtenir une signature. Cette faille peut être évitée en empêchant les utilisateurs d'avoir un SPN associé à leur compte.
Impacts sur le SI
Kerberos est à l'origine de l'authentification des utilisateurs dans le système d'information et l'accès à ses services. Un problème de configuration peut conduire à un accès non autorisé à des ressources sensibles et une escalade de privilèges. La compromission de ce système peut engendrer de graves impacts dans le système d'information donc de lourdes conséquences pour l'entreprise.
Dans ce document nous verrons les mesures à mettre en place pour contrer les attaques suivantes :
- Récupération de ticket (et obtention du mot de passe en clair) :
- AS-RepRoasting : utilisateurs sans pré-authentification;
- Kerberoasting : comptes utilisateur avec un SPN.
As-RepRoasting
Dans le cas où la pré-authentification est désactivée pour un utilisateur, il peut demander un ticket TGT sans s'authentifier.
L'attaque As-RepRoasting réceptionne des tickets TGT, une personne malveillante va avoir accès à plusieurs informations capitales :
- un nom de compte valide dans le domaine ;
- une signature pouvant donner sur un mot de passe en clair, utilisé lors de l'authentification sur d'autres services ou machines du domaine.
Pour plus d'informations concernant le déroulement de cette attaque, voir le mécanisme détaillé de l'attaque As-RepRoasting.
Kerberoasting
L'attaque Kerberoasting a le même objectif d'obtention d'une signature, sa récupération s'effectue alors par la demande d'accès à un service. Un utilisateur possède la capacité de demander n'importe quel service auprès du contrôleur de domaine, c'est au service de vérifier si l'utilisateur en a bien l'accès. Un attaquant va donc effectuer des demandes de tickets de services (ST) en indiquant des noms de services (SPN) arbitraires.
Lors de la réception d'un ST, l'attaquant va avoir accès à plusieurs informations capitales :
- un nom de compte valide dans le domaine ;
- une signature pouvant donner sur un mot de passe en clair, pouvant être utilisé lors de l'authentification sur d'autres services ou machines du domaine.
Pour plus d'informations concernant le déroulement de cette attaque, voir le mécanisme détaillé de l'attaque Kerberoasting.
Remédiations technique
Récupération de tickets
Le point faible exploité par ces attaques est la robustesse du mot de passe. Une fois qu'une personne malveillante a accès à un ticket Kerberos il va tenter de casser le condensat par une attaque de brute force dans l'objectif de trouver le mot de passe en clair. Cette attaque est d'autant plus efficace que le mot de passe est faible.
Les remédiations présentées ci-dessous sont exécutées sur un compte possédant les privilèges d'administrateur sur une machine ayant le rôle de contrôleur de domaine.
AS-RepRoasting (quick-win)
Afin de pallier ce défaut de configuration, il est nécessaire de changer le paramètre de la pré-authentification pour chaque utilisateur.
Lister les utilisateurs concernés
Avant d'appliquer une règle désactivant la pré-authentification sur l'ensemble des utilisateurs du domaine, il est recommandé d'établir une liste des comptes concernés.
Une commande PowerShell à lancer sur le contrôleur de domaine permet de lister les comptes dont la pré-authentification n'est pas requise :
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true'
Ci-dessous un résultat sur un domaine de test.
A partir de cette liste, vous pouvez juger si la désactivation de la pré-authentification est nécessaire on non pour chacun des comptes.
Modification du paramètre pour chaque utilisateur
Pour chaque utilisateur concerné on applique le paramètre d'activation de la pré-authentification.
Utilisateur et ordinateurs Active Directory > Propriété du compte puis l'onglet Compte
Il faut ensuite décocher la dernière case : La pré-authentification Kerberos n'est pas nécessaire
Kerberoasting
Liste des utilisateurs possédants un SPN
L'exécution du script PowerShell ci-dessous aura pour effet de lister l'ensemble des utilisateurs du domaine possédant un ou plusieurs SPN.
$search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$search.filter = "(&(objectCategory=person)(objectClass=user)(servicePrincipalName=*))"
$results = $search.Findall()
foreach($result in $results)
{
$userEntry = $result.GetDirectoryEntry()
Write-host "User : " $userEntry.name "(" $userEntry.distinguishedName ")"
Write-host "SPNs"
foreach($SPN in $userEntry.servicePrincipalName)
{
$SPN
}
Write-host ""
}
Ci-dessous un résultat sur un environnement de test.
Suppression des SPN liés à des utilisateurs
Pour afficher les SPN associés à des comptes utilisateurs il faut afficher les fonctionnalités avancées.
On peut ensuite venir dans l'onglet Editeur d'attributs pour chaque utilisateur concerné et ainsi supprimer les SPNs associés.
Ne pas supprimer le SPN associé au compte krbtgt, il est légitime.
Lexique
NTLM
Le protocole NTLM pour (New Technology Lan Manager) est un mécanisme d'authentification propriétaire Microsoft. Il connait deux versions à ce jour, NTLMv1 et NTLMv2, connu aussi sous les noms Net-NTLMv1 et Net-NTLMv2 pour éviter tout amalgame avec les condensats LM et NT nommé à tort hash NTLM.
KDC (Key Distribution Center)
Le KDC pour centre de distribution des clés est un service inclut dans le contrôleur de domaine. Il a notamment deux services, AS et TGS qui ont pour rôle de distribuer respectivement les tickets TGT et ST à l'utilisateur.
AS (Authentication Service)
Le service d'authentification est un sous-service du KDC qui est sollicité lors de la pré-authentification d'un utilisateur. Il distribue également les tickets TGT.
TGS (Ticket Granting Server)
Le TGS est un sous-service du KDC qui fournit les tickets de services (ST).
SPN (Service Principal Name)
Ce nom est utilisé pour identifier les services présents dans l'AD. Il est identifié notamment au sein des tickets et des requêtes Kerberos.
TGT (Ticket Granting Ticket)
Ticket généré par le service d'authentification du domaine. Il est utilisé lors de la demande d'un ticket de service.
ST (Service Ticket)
Le ticket de service est généré par le TGS, il est utilisé pour demander l'accès à un service du domaine.
Annexes
Kerberos
L'utilisateur est à l'origine des requêtes pour chacune des étapes. L'ensemble des clé échangées pour l'accès à un service est listé ci-dessous dans la légende.
1. Pré-authentification
L'utilisateur demande un ticket TGT en s'authentifiant sur le service KDC (Key Distribution Center) du contrôleur de domaine.
2. Demande de ticket de service
Ayant le ticket TGT, l'utilisateur fait une demande d'un ticket de service ST sur le service TGS (Ticket Granting Service) du contrôleur de domaine.
3. Demande d'accès au service
AS-RepRoasting
L'attaque AS-RepRoasting est une exploitation de la phase 1 de l'échange Kerberos.
Lorsque la pré-authentification n'est pas désactivée sur le contrôleur de domaine, l'utilisateur n'est pas obligé de transmettre l'horodatage chiffré avec sa clé privé. Cela peut engendrer une usurpation d'identité lorsqu'une personne malveillante utilise le nom d'un autre utilisateur.
Le but de l'attaquant est donc d'usurper un maximum d'utilisateur pour récupérer leur TGT.
Avec un TGT, une personne malveillante a la capacité de récupérer la signature de l'utilisateur en utilisant des méthodes de brute-force. Ayant acquis cette signature, l'attaquant peut s'authentifier sur l'ensemble des services / machines / accès de l'utilisateur compromis.
Kerberoasting
L'attaque Kerberoasting s'effectue lors de la phase 2 de l'échange Kerberos, dans les requêtes pour des tickets de services (ST).
Le but de l'attaquant est d'obtenir un maximum de tickets de services, ceux-ci contenant la signature du compte de service, une attaque par brute force permet d'obtenir le mot de passe en clair de ce compte.
La plupart des SPN sont liés à des comptes machines qui ont des mots de passe aléatoires très long, inexploitable pour une attaque par brute force. A l'inverse, les SPN liés à des comptes utilisateurs sont vulnérables et exploitables dans le domaine.