Coercition d'authentification et relais NTLM : comprendre PetitPotam et ses cousins pour s'en protéger
Certaines attaques n'exploitent pas une faille unique, mais l'enchaînement de comportements légitimes. La coercition d'authentification en est l'exemple type : on pousse un serveur à s'authentifier vers une machine contrôlée par l'attaquant, qui relaie cette authentification vers un autre service. Lorsque la victime est un contrôleur de domaine, l'enjeu est la forêt entière.
Le principe de la coercition
De nombreux protocoles RPC de Windows contiennent des fonctions qui demandent au serveur d'accéder à un chemin réseau fourni par l'appelant. Si ce chemin pointe vers une machine contrôlée par l'attaquant, le serveur s'y connecte et s'authentifie avec son compte d'ordinateur. Plusieurs techniques publiques exploitent ce comportement :
| Technique | Protocole utilisé |
|---|---|
| Bogue de l'imprimante | MS-RPRN, service Spouleur d'impression |
| PetitPotam | MS-EFSR, système de fichiers EFS |
| DFSCoerce | MS-DFSNM, gestion des espaces de noms DFS |
| Autres variantes | interfaces RPC diverses, dont les copies instantanées de serveurs de fichiers |
Certaines de ces techniques exigeaient un compte du domaine, d'autres ont pu fonctionner sans authentification avant les correctifs. Microsoft a corrigé plusieurs variantes, mais la famille reste ouverte : de nouvelles interfaces sont régulièrement identifiées. La défense durable ne consiste donc pas à boucher chaque fonction, mais à rendre l'authentification obtenue inutilisable.
Le relais : là où se joue l'attaque
Une authentification NTLM obtenue par coercition n'a de valeur que si l'attaquant peut la relayer vers un service qui l'accepte sans vérifier qu'elle lui était destinée. Les cibles typiques sont :
- l'inscription web d'AD CS : en relayant l'authentification d'un contrôleur de domaine vers les pages d'inscription HTTP de l'autorité de certification, l'attaquant peut obtenir un certificat au nom du DC, puis des droits de réplication sur l'annuaire ;
- LDAP sur les contrôleurs de domaine : un relais peut permettre de modifier des attributs d'objets ordinateurs, par exemple pour configurer une délégation ;
- SMB sur des serveurs où la signature n'est pas exigée.
Le relais Kerberos existe aussi, dans des conditions plus restreintes ; les mesures de signature et de liaison de canal le limitent également.
Casser la chaîne côté AD CS
C'est la priorité si vous disposez d'une autorité de certification avec les rôles d'inscription web. Microsoft a publié des recommandations dédiées :
- supprimer les rôles « Inscription de l'autorité de certification via le Web » et « Service web d'inscription de certificats » s'ils ne sont pas utilisés ;
- sinon, exiger HTTPS et activer la protection étendue de l'authentification (EPA) dans IIS pour ces applications ;
- désactiver NTLM sur ces sites IIS, en ne conservant que Kerberos via Negotiate lorsque c'est possible.
Signature, liaison de canal et filtrage
- Signature SMB exigée sur les contrôleurs de domaine (c'est le cas par défaut) et, idéalement, sur tous les serveurs et postes. Les versions récentes de Windows renforcent ces valeurs par défaut ; vérifiez celles qui s'appliquent à votre parc.
- Signature LDAP exigée et liaison de canal LDAP sur les contrôleurs de domaine, après une phase d'audit pour repérer les clients non conformes.
- Service Spouleur d'impression désactivé sur les contrôleurs de domaine et les serveurs de niveau 0 qui n'impriment pas.
- Filtres RPC : la fonctionnalité de filtrage RPC de Windows permet de bloquer ou de restreindre l'accès aux interfaces abusées, comme MS-EFSR, sur les serveurs qui n'en ont pas besoin. Testez-les soigneusement, car une interface bloquée peut être utilisée par une fonction légitime.
- Filtrage sortant des contrôleurs de domaine : un DC qui ne peut pas ouvrir de connexion SMB ou HTTP vers des postes arbitraires ne peut pas être forcé à s'y authentifier.
Réduire NTLM à long terme. Chacune de ces mesures ferme une cible de relais. La réduction progressive de NTLM, en commençant par l'audit de son usage sur les contrôleurs de domaine, supprime la cause commune. C'est un chantier de plusieurs mois, mais c'est celui qui rend toute la famille d'attaques inopérante.
Ce qu'un audit vérifie
- la présence des rôles d'inscription web AD CS, l'usage de HTTPS, d'EPA et l'acceptation de NTLM ;
- l'exigence de signature SMB et de signature LDAP, ainsi que la liaison de canal LDAP ;
- l'état du service Spouleur d'impression sur les contrôleurs de domaine ;
- les flux sortants autorisés depuis les contrôleurs de domaine ;
- l'existence d'un inventaire de l'usage de NTLM et d'un plan de réduction.