Chiffrement Kerberos : sortir de RC4 et généraliser AES sans interrompre les services
Kerberos sait chiffrer ses tickets avec AES depuis Windows Server 2008, et pourtant RC4 reste présent dans la plupart des domaines que nous auditons. Rarement par choix : plutôt par inertie, à cause de comptes de service anciens et d'attributs jamais renseignés.
Pourquoi RC4 pose problème
Avec RC4-HMAC, la clé Kerberos d'un compte est directement dérivée de son condensat NT, sans sel ni itérations. Un ticket de service chiffré en RC4 est donc beaucoup plus rapide à attaquer hors ligne qu'un ticket AES : c'est le ressort principal du Kerberoasting. De plus, connaître le condensat NT d'un compte suffit à produire des tickets RC4 valides pour celui-ci. Enfin, RC4 est un algorithme considéré comme faible depuis longtemps. Microsoft a engagé la dépréciation de RC4 dans Kerberos et a annoncé des changements de comportement par défaut sur les contrôleurs de domaine ; le calendrier et les modalités précises doivent être vérifiés dans la documentation Microsoft actuelle, car ils ont évolué au fil des annonces.
Comment le type de chiffrement est choisi
Le contrôleur de domaine choisit le chiffrement d'un ticket de service en fonction de ce que le compte cible déclare supporter, via l'attribut msDS-SupportedEncryptionTypes, de ce que le client propose et de ce que la stratégie autorise. L'attribut est un masque de bits :
| Valeur | Type |
|---|---|
| 0x1 et 0x2 | DES (à proscrire, désactivé par défaut) |
| 0x4 | RC4-HMAC |
| 0x8 | AES128 |
| 0x10 | AES256 |
Les ordinateurs renseignent eux-mêmes cet attribut. Les comptes utilisateurs utilisés comme comptes de service, en revanche, le laissent souvent vide, et le comportement par défaut dépend alors du niveau de mise à jour des contrôleurs et du paramètre DefaultDomainSupportedEncTypes. Renseigner explicitement l'attribut à AES uniquement (0x18) sur ces comptes est plus lisible et plus sûr.
Le piège des mots de passe anciens
Les clés AES d'un compte ne sont générées qu'au moment d'un changement de mot de passe effectué alors que le domaine est au niveau fonctionnel Windows Server 2008 ou supérieur. Un compte de service dont le mot de passe n'a pas changé depuis l'époque d'un domaine plus ancien ne possède donc aucune clé AES : forcer AES sur ce compte provoquerait des échecs d'authentification. Identifiez ces comptes grâce à l'attribut pwdLastSet comparé à la date de relèvement du niveau fonctionnel, et planifiez un changement de mot de passe avant tout durcissement. Idéalement, remplacez-les par des comptes de service administrés de groupe (gMSA), dont le mot de passe est long, aléatoire et renouvelé automatiquement.
Une migration en quatre temps
- Mesurer : collecter les événements 4768 et 4769 des contrôleurs et filtrer le type de chiffrement des tickets (0x17 correspond à RC4, 0x11 et 0x12 à AES). Les mises à jour récentes enrichissent ces événements avec des champs utiles pour identifier les comptes concernés.
- Corriger les comptes : changer les mots de passe anciens, renseigner
msDS-SupportedEncryptionTypes, mettre à jour les fichiers keytab des systèmes non Windows. - Traiter les exceptions : identifier les applications et équipements qui ne savent faire que RC4 et documenter une date de fin pour chacun.
- Restreindre : configurer la stratégie « Sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos » pour exclure RC4, en commençant par un périmètre pilote.
Les appareils non Windows. Les équipements réseau, appliances et serveurs Linux intégrés au domaine utilisent souvent un keytab généré il y a des années, parfois en RC4 seulement. Ce sont eux qui cassent en premier : inventoriez-les avant de durcir.
Ce qu'un audit vérifie
- la proportion de tickets émis en RC4 et les comptes qui en sont à l'origine ;
- les comptes de service dont le mot de passe est antérieur à la génération des clés AES ;
- la valeur de
msDS-SupportedEncryptionTypessur les comptes disposant d'un SPN ; - la stratégie des types de chiffrement Kerberos appliquée aux contrôleurs et aux serveurs.