Hardening : la sécurisation d’une autorité AD CS
Sommaire
I. Présentation
Le durcissement (hardening), représente l'ensemble des techniques pour réduire la surface d'attaque d'un système. Dans le cas d'AD CS, on cherche à limiter les exploits de type « Privilege Escalation », qui permettent typiquement de devenir admin du domaine Active Directory. Ils sont déjà bien référencés, aussi si vous lancez une recherche avec les mots clés ADCS ESC vous en trouverez une liste avec les techniques d'attaques.
Pour une plateforme d'autorités de certification, plusieurs solutions s'offrent à nous avec des niveaux de complexité d'implémentation divers. Voici quelques-unes de ces possibilités.
II. La posture de sécurité
Pour déterminer le niveau de sécurisation (autrement appelé posture de sécurité) d’une autorité de certification, il est possible de recourir à des outils du marché, tel que celui de Microsoft : Defender for Identity, ou encore celui de Semperis qui couvre les briques autour de l’Active Directory :
Pour en savoir plus sur l'outil Purple Knight de Semperis, vous pouvez lire cet article :
Parmi les solutions gratuites, je vous recommande PSPKIAudit qui s’appuie sur le module PowerShell PSPKI que nous avons utilisé dans un module précédent.
Sur la machine où vous souhaitez l’exécuter, vérifiez tout d’abord que les prérequis sont installés, à savoir :
- Les outils d’administration (RSAT) AD CS,
- Le module PowerShell PSPKI.
Si ce n’est pas le cas, lancez les commandes suivantes :
Get-WindowsCapability -Online -Name "Rsat.*" | where Name -match "CertificateServices|ActiveDirectory" | Add-WindowsCapability -Online
Install-Module -Name PSPKIEnsuite, téléchargez les sources PSPKIAudit, puis lancez les commandes suivantes :
cd PSPKIAudit
Get-ChildItem -Recurse | Unblock-File
Import-Module .\PSPKIAudit.psd1Pour initier l’audit sur une autorité, il suffit de taper une commande de ce type :
Invoke-PKIAudit -CAComputerName S-SUBCA1.contoso.adLa posture de sécurité est évaluée selon les failles connues au travers des ESC dont je parlais en introduction. Le résultat est similaire à celui-ci :
Dans notre cas, l’indication "Misconfigurations : ESC8" signifie que l’autorité est vulnérable à l’attaque Petit Potam, détaillée un peu après.
III. 3 points clés pour renforcer la sécurité d'une CA
Ici, je souhaite détailler trois points précis permettant de renforcer la sécurité d'une autorité de certification AD CS.
A. Les groupes Active Directory
Lors de l'installation et de la configuration d'AD CS, le compte ordinateur du serveur est automatiquement ajouté au groupe « Builtin\Accès compatible pré-Windows 2000 » (Pre-Windows 2000 Compatible Access). Parfaitement nécessaire lors de la phase d'initialisation, cela représente un problème de sécurité potentiel par la suite. Le référentiel des points de contrôle Active Directory en fait mention : Points de contrôle Active Directory.
Il convient donc de retirer ce compte ordinateur du groupe. Depuis la console "Utilisateurs et ordinateurs Active Directory", affichez la liste des membres et supprimez le compte ordinateur.
L'autre groupe auquel une autorité de type Enterprise est ajoutée est « Editeur de certificats » (Cert Publishers) et c'est un risque potentiel de sécurité. Pour tous les détails, je vous renvoie vers cet excellent article : A “deep dive” in Cert Publishers Group – Decoder's Blog
Néanmoins, voici quelques explications : lorsque l'on génère un modèle de certificat, il existe cette case nommée "Publier le certificat dans Active Directory".
Elle autorise l'injection de la partie publique du certificat dans les propriétés de l'objet, en cas d'utilisation, par exemple, de chiffrement de mails où un échange de clés publiques est nécessaire. Dans les propriétés du compte utilisateur, on retrouve alors cette information :
Pour que cet ajout fonctionne, il faut que l'autorité dispose du droit d'écriture dans l'attribut "userCertificate" sur tous les objets AD et c'est précisément la fonction du groupe « Éditeur de certificats ».
Sauf que, comme vous le lirez dans l'article, les droits sont bien plus nombreux et un attaquant pourrait réussir à injecter un certificat d'autorité bidon dans l'Active Directory. Moralité : si vous n'exploitez pas de modèle qui nécessite la publication du certificat dans l'AD, je vous recommande fortement de supprimer l'appartenance de l'autorité à ce groupe.
B. L'attaque Petit Potam
Parmi les attaques possibles au travers du rôle AD CS, il en existe une qui s'appelle Petit Potam. Elle n'est pas propre aux autorités de certification, mais elle s'appuie sur une technique de relais NTLM. Si le composant IIS est installé sur l'autorité et que cette partie n'a pas été sécurisée, l'attaquant peut alors devenir admin du domaine. Les rôles de services concernés sont :
- Inscription web de l’autorité de certification
- Service web d’inscription de certificat
L'article Microsoft décrit bien les solutions possibles pour s'en prémunir. Néanmoins, celle que je préfère reste la désactivation du protocole NTLM au niveau de la machine. Notez bien que d'un point de vue architecture, il est préférable de ne pas installer de composants IIS sur le serveur qui joue le rôle d'autorité de certification. Pour des contextes où les besoins en matière de certificats sont restreints et lorsque la simplicité est demandée, il est fréquent de rencontrer IIS sur la même machine, d'où l'importance de combler cette faille.
C. Le Tiering Model
On parle aussi de l'implémentation d'un Tier Model. Pour résumer, il s'agit d'un modèle en couches qui contrôle plus finement les accès entre elles. L'idée étant d'éviter qu'un seul compte à privilèges ne puisse accéder à l'ensemble du système d'information (SI).
Objectivement, la charge d'exploitation est plus conséquente, mais la sécurité est considérablement accrue. Dans la mesure du possible, une solution de bastion est intégrée au déploiement, précisément pour faciliter l'administration du SI.
Il faut aussi prendre en compte une segmentation réseau pour ce type de projet.
Pour mieux comprendre son fonctionnement, je vous propose le schéma ci-après. Il s'agit d'un exemple simple d'application du Tier Model en 3 niveaux, d'autres implémentations permettent plus de granularités dans la délégation.
Quelques explications :
Tout d'abord, vous constaterez que les systèmes sont classés par niveau en fonction de leurs usages :
- Tier0 (T0) : tous les systèmes en rapport avec la gestion des identités et des accès. C'est dans ce niveau qu'on positionnera les autorités de certification,
- Tier1 (T1) : les serveurs membres et applicatifs sont membres de ce niveau,
- Tier2 (T2) : périphériques clients, imprimantes, utilisateurs appartiennent à ce niveau.
Entre ces niveaux, les accès sont contrôlés d'un point de vue filtrage réseau et aussi d'un point de vue système (restrictions par GPO). Un admin du domaine "adm-t0-bob", qui dispose par défaut d'un droit d'administration local sur tous les serveurs membres, se verra refuser l'ouverture de session sur un serveur T1. Il conservera néanmoins un droit de contrôle total sur tous les objets de l'annuaire Active Directory.
De même, si nous regardons plus particulièrement le niveau T1, le compte "adm-t1-alice" dispose des droits pour se connecter à n'importe quel système dans ce niveau et de droits de modification sur les objets Active Directory dans ce niveau (souvent lié à une OU), mais en aucun cas elle ne pourra se connecter sur des postes du niveau T2.
En outre, le compte "adm-t1-mia", pourra accéder aux ressources du niveau T1, mais pas administrer les objets dans l'AD.
IV. Conclusion
Nous l'avons vu, certaines actions de type Quick Wins permettent d'améliorer rapidement le niveau de sécurité. Pour d'autres, comme le tiering, un projet complet plus structurant doit être déclenché.
Bien entendu, les solutions exposées ici ne sont pas exhaustives et il convient de s'adapter à chaque contexte. Dans le chapitre suivant, nous traiterons d'une autre brique visant à améliorer la sécurité : le HSM.
