Bonnes pratiques de sécurisation d’Active Directory et Windows

L’Active Directory est le service d’annuaire incontournable pour une infrastructure Windows. Centre névralgique du système d’informations, il gère l’identification et l’authentification des ressources accédant au réseau. Il est fondamental de la configurer de manière sécurisée, car sa compromission entraîne celle du S.I. dans son ensemble. Si le besoin de sécurisation d’un AD est communément accepté, on se ne sait souvent pas par quelle recommandation commencer. Nous vous proposons ici un retour des mécanismes que vous pouvez mettre en place pour mitiger la majorité des chemins de compromission communément utilisés par les attaquants, basé sur notre expérience d’auditeurs.

Configuration des GPP et services

Afin de configurer des tâches récurrentes, les administrateurs se retrouvent souvent à devoir configurer des tâches sous l’identité d’un autre compte : « Exécuter en tant que…/Run as… ». Cette pratique très utile représente cependant un risque de sécurité majeur : le mot de passe du compte utilisé est nécessairement stocké. De la même façon, lors de l’usage de Group Policy Preferences (GPP), le mot de passe est stocké sur un partage réseau accessible à tous, chiffré avec une clef universelle, connue et donnée par Microsoft. Le risque encouru est le même lors de la configuration de l’exécution d’un service « en tant que… ». Il est donc recommandé de ne configurer ni GPP, ni d’exécutions en tant qu’autre utilisateur.

Microsoft a introduit dans Windows Server 2012 les comptes de service, également appelés gMSA group-Managed Service Accounts, comme solution pour les problèmes évoqués ci-dessus. Ces comptes ont leur mot de passe gérés automatiquement, un enregistrement SPN simplifié, et permettent d’exécuter des tâches à privilèges dans le domaine. Les gMSA peuvent être utilisés pour paramétrer des services Windows, des tâches planifiées, des rôles de l’AD, et certains softwares en fonction de leur compatibilité.

Gestion des protocoles obsolètes

Dans chaque audit interne, nos équipes observent l’utilisation de protocoles obsolètes par un ou plusieurs serveurs : SMBv1, paquets SMB non signés, NetNTLMv1, LLMNR/NetBIOS, WPAD, WDigest… De tels algorithmes mènent souvent à une prise de contrôle quasi-immédiate de comptes AD. Ces protocoles devraient donc être mis à jour au plus vite. Dans le cas de besoins métiers rendant impossible leur désactivation, comme des logiciels qui ne le permettent pas, il est recommandé de recenser puis d’isoler l’intégrité du matériel qui en a besoin. Vous pouvez ensuite demander à leur support de les mettre à jour, ou bien considérer de changer les matériels ou logiciels concernés au profit de solutions plus modernes n’ayant plus besoin de ces prérequis vulnérables pour fonctionner.

Accès à la mémoire du processus LSASS

Les réseaux Windows d’entreprise reposent sur des protocoles réseau tels que NetNTLM et Kerberos pour implémenter le single sign-on. Cela permet aux personnel d’accéder aux ressources sur le réseau sans avoir à saisir systématiquement ses identifiants. Leurs informations d’authentification sont donc enregistrées localement sur leur machine, et cette dernière prend la décision de les envoyer automatiquement aux ressources réseau qui le demandent. Le processus qui gère ces informations d’authentification s’appelle LSASS (Local Security Authority Subsystem Service).

Cette fonctionnalité est bien pratique, mais elle a ouvert la voie à de nombreuses attaques. En effet, certains protocoles ou anciennes versions de Windows stockent ces informations d’authentification de manière insuffisamment sécurisée : soit directement en clair, par exemple via les protocoles WDigest, TsPkg ou Kerberos, soit sous forme hachée. Dans les deux cas, les informations sont récupérables par un attaquant disposant des droits d’administration sur la machine, situation qui peut être due à des mauvaises pratiques (donner les droits d’administration sur les machines à trop de personnes), ou à des vulnérabilités qui affectent régulièrement Windows, et qui permettent à un utilisateur standard d’élever ses privilèges. Pour s’en prémunir, il convient donc de respecter le principe du moindre privilège, c’est à dire en ne donnant qu’avec parcimonie les droits d’administration sur les machines, conjugué au principe de l’administration par tiers dont nous parlerons un peu plus bas afin de limiter la présence de compte privilégiés sur le domaine.

En outre, il convient de mettre à jour ses systèmes, car Microsoft implémente régulièrement de nouvelles mesures de protection dans Windows visant à rendre plus difficile l’accès à la mémoire de ce processus. Des solutions antivirus performantes, que l’on a pu appeler « mécanisme d’analyse comportementale » ou encore « Endpoint detection and response », permettent également de détecter et bloquer la plupart des accès illégitimes à ce processus.

Mise en cache des identifiants du domaine

Sur un domaine, lorsqu’un utilisateur s’authentifie sur une machine Windows, celle-ci enregistre par défaut une empreinte du mot de passe utilisé. Cela permet ensuite de se connecter à la machine même si le domaine est injoignable. Ce mécanisme est pratique, typiquement dans le cas du télétravail. Il présente aussi un risque, car un attaquant ayant accès à la machine peut réaliser une élévation de privilèges et avoir accès à cette empreinte, stockée dans le registre, puis la « casser » pour retrouver le mot de passe en clair. Pour se prémunir face à ce risque, il est recommandé de désactiver ce mécanisme de mise en cache sur tous les ordinateurs qui n’en ont pas besoin, par exemple les serveurs et les postes locaux, et de l’activer avec parcimonie sur les machines qui le nécessitent.

Partages réseaux

Protéger le S.I. de l’entreprise permet d’assurer sa disponibilité, mais aussi la confidentialité des données qu’il renferme. Il est nécessaire de configurer correctement les droits d’accès aux partages réseaux, où l’on retrouve fréquemment des documents sensibles et/ou confidentiels, souvent accessibles par tous les utilisateurs du domaine, voire en mode anonyme. La sécurisation ne peut se faire qu’après une première étape de cartographie des partages réseaux et des permissions sur ceux-ci. Il est également nécessaire de sensibiliser les utilisateurs à la manière de partager et protéger des documents sur le réseau.

« Roasting »

Le « Kerberoasting » est une attaque citée pour la première fois au milieu des années 2010. Elle consiste à profiter du mécanisme de Kerberos pour obtenir l’empreinte d’un mot de passe d’un compte possédant un Service Principal Name. Si le mot de passe défini est trop faible, il est possible de casser l’empreinte et ainsi récupérer le mot de passe de ce compte, potentiellement réutilisé dans plusieurs procédures dans le domaine, et de ce fait très privilégié… Se prémunir de ce type d’attaque nécessite d’inventorier les comptes d’utilisateurs possédant un SPN, et leur définir un mot de passe complexe.

Une autre forme de « roasting » existe : l’AS-REP roasting. Avec cette technique, un attaquant va profiter d’un manque de sécurité de certains comptes du domaine, afin là encore de récupérer un ticket Kerberos qu’il pourra tenter de casser pour retrouver le mot de passe en clair du compte ciblé. Le nom provient du nom de l’un des messages utilisés dans une séquence d’authentification Kerberos : AS-REP.

Pour s’en prémunir, il faut s’assurer de bien activer la pré-authentification Kerberos sur tous les comptes du domaine. Si des comptes nécessitent que cette pré-authentification soit désactivée, il est primordial de les recenser, de documenter la raison de cette faille de sécurité, et œuvrer autant que possible dans le but de la combler.

Délégation d’administration

Le principe de délégation d’administration permet de respecter le principe de moindre privilège, en diluant les responsabilités administratives sur l’annuaire entre plusieurs comptes, et en évitant d’utiliser des comptes d’administration du domaine pour toutes les opérations. La méthode de mise en place consiste à créer des OUs et groupes bénéficiant des justes privilèges pour effectuer les tâches d’administration récurrentes, comme le déploiement de postes ou la réinitialisation de mots de passe de comptes, puis d’affecter les bons utilisateurs à ces OUs. En plus de la protection apportée en cas de compromission de l’un de ces comptes, cela permet également une meilleure organisation humaine, puisque les droits de chacun sont correctement identifiés. Il est alors possible de faire signer une charte d’utilisateur spécifique aux administrateurs, qui peuvent être spécialement formés aux tâches identifiées. Les processus sont au final mieux normés et maîtrisés.

Modèle d’administration par tiers dans l’Active Directory

Ce modèle d’administration est décrit par Microsoft, mais il s’applique également dans toute architecture autre qu’un AD. L’objectif de ce modèle est de limiter la portée des privilèges des comptes d’administration en fonction des ressources qu’ils administrent. Cela permet de limiter les traces de ces comptes sur le SI et de protéger les zones plus critiques en cas de compromission d’un compte sur une zone moins critique.

Le principe est de séparer les ressources en trois tiers :

1. Tier 0 : les serveurs critiques ayant un impact sur l’infrastructure AD, comme les contrôleurs de domaine, les serveurs de PKI, de virtualisation, WSUS…
2. Tier 1 : les serveurs non critiques et applications membre de l’AD,
3. Tier 2 : les équipements utilisateurs, tels que les postes, les imprimantes…

Tout d’abord conçu pour les environnements On-Premise, Microsoft a fait évoluer ce modèle vers le nouveau Enterprise Access Model pour y inclure le cloud et les problématiques de contrôle d’accès qui l’accompagnent.

Implémentation des tiers

Ces modèles reposent sur la limitation des droits des administrateurs. Le compte d’administration d’un tiers doit seulement être en mesure de s’authentifier sur les hôtes de son tiers, et non sur les hôtes d’un autre tiers. Les administrateurs des tiers plus critiques n’ont ainsi aucun droit sur les tiers moins critiques, et les administrateurs des tiers inférieurs ont des droits sur les tiers supérieurs selon les besoins du rôle.

Concrètement, cela signifie que chaque personne étant amenée à effectuer des opérations d’administration doit disposer de plusieurs comptes : son compte d’utilisateur habituel, depuis lequel il peut effectuer ses tâches bureautiques quotidiennes, ainsi qu’un compte pour chaque tiers qu’il devra administrer. Cette lourdeur à l’usage est compensée par le fort gain en sécurité qu’il procure : au sein des S.I. n’incorporant pas ce modèle, nos consultants sont généralement en mesure d’accéder facilement à tous les hôtes du réseau dès lors qu’ils mettent la main sur les informations d’authentification d’un compte d’administration...

Il existe deux façons d’implémenter ce modèle : par restriction des droits de connexion par GPO ou bien par politiques et silos d’authentification. Microsoft recommandait auparavant l’emploi d’un Enhanced Security Admin Environment, à savoir une forêt dédiée pour l’administration. Cette méthode est aujourd’hui dépréciée de par sa complexité, en dehors de quelques cas d’usages très précis.

L’application par GPO s’appuie sur l’usage de cinq règles d’interdiction de connexion à adapter sur chaque tiers. Cette méthode est plus simple à mettre en place mais permet un contrôle moins fin des conditions de connexion.

Les politiques d’authentification ont été introduites dans Windows Server 2012 R2. Elles permettent de contrôler finement qui peut se connecter, à quelles ressources et depuis quelles ressources. Elles permettent donc de mettre en place des postes d’administration dédiés, un aspect qui augmente beaucoup le niveau de sécurité, mais qui peut être complexe à implémenter selon le contexte de l’entreprise. Les politiques d’authentification étant plus techniques à mettre en place, l’usage de la solution par GPO peut servir de solution intermédiaire le temps de la migration vers les politiques d’authentification.

Conclusion

La sécurisation d’un Active Directory est un sujet complexe. Les mécanismes de protection proposés dans cet article couvrent la majorité des faiblesses qu’exploitent nos pentesteurs lors de leurs interventions, mais cette liste n’est bien sûr pas exhaustive. Rappelons que la sécurité totale d’un S.I. n’existe pas : elle est affaire d’arbitrages à réaliser en prenant en compte la facilité d’utilisation, ou les prérequis de telle ou telle solution. Elle doit s’inscrire dans un processus global d’analyse des risques en cohérence avec les choix stratégiques de l’entreprise. Dans cette étude, la sécurité de l’Active Directory doit prendre une place majeure.