INTRODUCTION
L’annuaire Active Directory, centre névralgique de la sécurité des systèmes d’information Microsoft, est un élément critique permettant la gestion centralisée de comptes, de ressources et de permissions. L’obtention de privilèges élevés sur cet annuaire entraîne une prise de contrôle instantanée et complète de toutes les ressources ainsi administrées.
L’analyse des modes opératoires des attaques récentes met en évidence une recrudescence du ciblage des annuaires Active Directory, compte tenu de leur rôle de pierre angulaire de la plupart des systèmes d’information. En effet, l’attaquant ayant obtenu des droits élevés sur l’annuaire peut alors déployer une charge malveillante sur l’ensemble du système d’information, notamment par GPO ou en utilisant des connexions directes (psexec, wmiexec). Par conséquent, le faible niveau de sécurité des annuaires met en danger les systèmes d’information dans leur globalité et fait porter un risque systémique aux organisations.
Les observations de l’ANSSI font apparaître un manque de maturité critique et récurrent sur la sécurité des annuaires Active Directory. Le niveau de sécurité décroît ainsi de manière importante en fonction du temps et au rythme de la manipulation de ses objets ou des actions d’administration.
En réponse à ce risque croissant, l’ANSSI a développé et met à disposition un recueil de points de contrôle, afin d’accompagner les chaines DSI et SSI dans le suivi du niveau de sécurité des annuaires Active Directory. Ce recueil a vocation à être enrichi régulièrement en fonction des travaux de recherche, des pratiques constatées en audit, et de l’analyse des modes opératoires adverses.
Chaque point de contrôle vise à vérifier l’absence d’une pratique susceptible d’affaiblir le niveau de sécurité et qui pourrait le cas échéant être utilisée dans le cadre d’une attaque. En fonction des faiblesses trouvées, l’annuaire Active Directory se voit affecté un niveau :
· 1 L’annuaire Active Directory présente des problèmes critiques de configuration qui mettent en danger immédiat l’ensemble des ressources hébergées. Des actions correctrices sont à prendre dans les plus brefs délais ;
· 2 L’annuaire Active Directory présente des lacunes de configuration et de gestion suffisantes pour mettre en danger l’ensemble des ressources hébergées. Des actions correctrices sont à prendre à court terme ;
· 3 L’annuaire Active Directory possède un niveau de sécurité basique non affaibli depuis son installation ;
· 4 L’annuaire Active Directory dispose d’un bon niveau de sécurité ;
· 5 L’annuaire Active Directory dispose d’un niveau de sécurité à l’état de l’art.
Pour obtenir un niveau, un annuaire Active Directory doit passer avec succès tous les points de contrôles des niveaux inférieurs. Un annuaire de niveau 5 a passé avec succès tous les points de contrôle.
Chaque point de contrôle détaillé présente les caractéristiques suivantes:
· Titre du point de contrôle et niveau associé ;
· Identifiant du point de contrôle ;
· Description de la vulnérabilité ou de l’affaiblissement de sécurité induit que l’on cherche à caractériser par le point de contrôle ;
· Recommandation à appliquer pour valider le point de contrôle et durcir la configuration de l’annuaire.
Lorsqu’elles sont applicables, les documentations officielles sont proposées pour approfondissement.
Développé par l’ANSSI, le service ADS (Active Directory Security) met à disposition des opérateurs règlementés et de la sphère publique une capacité d’audit des annuaires Active Directory visant à leur donner de la visibilité sur le niveau de sécurité de leur annuaire et à les accompagner dans son durcissement par l’application progressive de mesures adéquates, avec un suivi dans le temps. Le service ADS implémente l’ensemble des points de contrôle présentés dans ce recueil.
CONTEXTE : CHEMINS DE CONTRÔLE
Un chemin de contrôle est composé d’un ensemble de relations de contrôle direct, où chaque relation traduit la maîtrise d’un objet sur un autre au travers d’une propriété particulière. Ainsi, les chemins de contrôle représentent des moyens pour un attaquant d’atteindre des cibles, et permettent d’identifier des déviances dans la gestion du domaine, de valider l’application d’un périmètre de sécurité autour des cibles considérées, mais également de révéler des moyens de persistance laissés par un attaquant après une compromission.
CONTEXTE : GROUPES PRIVILÉGIÉS
Les groupes privilégiés sont les groupes d’administration et les groupes opératifs ayant tous les droits et privilèges sur la forêt ou pouvant se les attribuer :
· « Administrateurs » ;
· « Administrateurs du schéma » ;
· « Administrateurs de l’entreprise » ;
· « Administrateurs du domaine » : ces administrateurs ont les privilèges de lire la base des secrets de tous les comptes et donc d’extraire les secrets de l’ensemble les comptes privilégiés ;
· « Opérateurs de compte » : ces opérateurs peuvent administrer tous les comptes d’utilisateurs, machines et groupes; à l’exception des comptes protégés par l’adminSDHolder ;
· « Opérateurs de serveur » : ces opérateurs peuvent administrer les contrôleurs de domaine, et donc récupérer les secrets de tous les comptes privilégiés ;
· « Opérateurs de sauvegarde » : ces opérateurs peuvent sauvegarder un contrôleur de domaine et donc extraire les secrets de tous les comptes privilégiés depuis cette sauvegarde ;
· « Opérateurs d’impression » : ces opérateurs peuvent charger des pilotes d’impression sur les contrôleurs de domaine et donc charger un pilote malveillant pour par exemple extraire les secrets de tous les comptes privilégiés.
Les groupes « opérateurs » sont vides par défaut et ne devraient contenir aucun membre.
LISTE DES POINTS DE CONTRÔLE
Un point de contrôle peut apparaître pour plusieurs niveaux de sécurité d’un Active directory. Plus le niveau visé est élevé, plus ses critères deviennent stricts. À ce jour, seuls les points permettant la validation des niveaux de sécurité 1 à 3 sont publiés. Les points de contrôle de niveaux supérieurs seront publiés lors de mises à jour futures de ce document.
La liste suivante permet de naviguer dans les points de contrôle décrits ci-après :
ID : vuln1_permissions_naming_context vuln2_permissions_naming_context
DESCRIPTION
Des chemins de contrôle dangereux existent vers les racines ldap de l’Active Directory, appelées naming contexts.
Selon le contrôle appliqué sur le naming context, un attaquant peut prendre le contrôle complet de l’Active Directory.
RECOMMANDATION
Un annuaire Active Directory contient plusieurs partitions appelées naming contexts :
· Domain, contient les informations des objets d’un domaine, comme les ordinateurs, les utilisateurs, les groupes, … ;
· Configuration, contient les éléments de configuration de la forêt ;
· Schema, contient la définition de tous les objets ;
· DomainDns, contient les zones DNS de niveau domaine ;
· ForestDns, contient les zones DNS de niveau forêt.
Il est fortement déconseillé de changer les permissions par défaut de la racine des naming contexts. Ainsi il est recommandé d’enlever ces permissions dangereuses. La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
Certaines de ces permissions, notamment relatives au service Microsoft Exchange, peuvent faire l’objet de correctifs de sécurité qu’il est nécessaire d’appliquer. C’est notamment le cas lorsque les objets suivants sont concernés :
· Exchange Windows Permissions ;
· Exchange Trusted Subsystem.
Documentation relative aux permissions Exchange positionnées sur la racine des domaines :
Documentation relative aux comptes Azure ADConnect (MSOL) :
· https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account
Utiliser la cmdlet Set-ADSyncRestrictedPermissions.
Utiliser la cmdlet Set-ADSyncRestrictedPermissions.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
ID : vuln1_permissions_adminsdholder vuln2_permissions_adminsdholder
DESCRIPTION
Des permissions dangereuses existent sur l’objet adminSDHolder. Ces permissions permettent aux comptes concernés de prendre le contrôle complet de l’Active Directory. Dans un modèle d’administration en niveaux (tiered administrative model), ces permissions cassent l’étanchéité du Tier 0.
RECOMMANDATION
CAS GÉNÉRAL
Les permissions de l’objet adminSDHolder sont régulièrement appliquées sur l’ensemble des objets protégés (membres des groupes administratifs et opératifs) de l’Active Directory. Par défaut, seuls les objets privilégiés possèdent des droits sur l’objet adminSDHolder. Ainsi, ce mécanisme permet de protéger les utilisateurs et les groupes les plus privilégiés de l’Active Directory.
Il est fortement déconseillé de changer les permissions par défaut de cet objet. Ainsi il est recommandé d’enlever les permissions dangereuses sur l’objet adminSDHolder afin de revenir à un état par défaut. La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
CAS PARTICULIERS
Dans le cadre de la mise en œuvre de forêts d’administration, il est toléré d’ajouter des droits à un groupe sur l’adminSDHolder aux conditions suivantes :
· les permissions sur ce groupe sont plus restrictives que celles appliquées initialement par l’objet adminSDHolder ;
· l’héritage des permissions sur ce groupe est désactivé.
Si une permission est liée à Exchange (par exemple WRITE_SPN), il est nécessaire d’appliquer les mises à jour Exchange ad hoc. La documentation relative aux permissions Exchange positionnées sur l’objet adminSDHolder est accessible à cette URL :
· https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server
Information : le contrôle depuis Exchange Trusted Subsystem avec WRITE_ALT_IDENTITY est un défaut de configuration qui sera corrigé ultérieurement par Microsoft.
Information : le contrôle depuis Exchange Trusted Subsystem avec WRITE_ALT_IDENTITY est un défaut de configuration qui sera corrigé ultérieurement par Microsoft.
Si les permissions concernent un compte Azure ADConnect (MSOL), il est nécessaire de reconfigurer les droits dans l’AD relatifs au compte MSOL spécifié. La documentation relative aux comptes Azure ADConnect (MSOL) est accessible à cette URL :
· https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account
Utiliser la cmdlet Set-ADSyncRestrictedPermissions et -SkipAdminSdHolders dans les commandes de configuration.
Utiliser la cmdlet Set-ADSyncRestrictedPermissions et -SkipAdminSdHolders dans les commandes de configuration.
ID : vuln1_permissions_dc vuln2_permissions_dc
DESCRIPTION
CAS GÉNÉRAL
Des chemins de contrôle dangereux existent vers les contrôleurs de domaine. Cela permet aux comptes concernés de prendre le contrôle complet de l’Active Directory. Un attaquant peut, par exemple, répliquer l’ensemble des secrets (dont ceux des Administrateurs du domaine), les réutiliser et ainsi prendre le contrôle complet du domaine.
CAS DES CONTRÔLEURS DE DOMAINE EN LECTURE SEULE
Dans le cas particulier des contrôleurs de domaine en lecture seule (RODC), un attaquant peut répliquer l’ensemble des secrets autorisés sur ce RODC et en devenir administrateur local. Le contrôle MANAGED_BY permet d’être administrateur local du RODC.
RECOMMANDATION
Il convient de considérer les comptes ayant des permissions sur les contrôleurs de domaine comme étant privilégiés. Il est alors nécessaire de les protéger avec le mécanisme de l’adminSDHolder. Pour cela, ces comptes doivent appartenir au groupe Administrateurs de l’entreprise ou Administrateurs du domaine.
Dans le cadre de la mise en place de forêts d’administration, il est toléré d’ajouter des droits sur les contrôleurs de domaine aux conditions suivantes :
· le groupe est de type DOMAIN LOCAL ;
· les permissions sur ce groupe sont plus restrictives que celles de l’adminSDHolder.
ID : vuln1_permissions_dpapi vuln2_permissions_dpapi
DESCRIPTION
Des chemins de contrôle dangereux existent vers les clés DPAPI. Si un attaquant obtient la clé DPAPI du domaine, il est en mesure de déchiffrer l’ensemble des secrets protégés par DPAPI, moyennant un accès préalable à cette donnée chiffrée.
RECOMMANDATION
Microsoft Windows fournit un mécanisme de protection des données (DPAPI) dont l’objectif est de protéger des données (souvent des fichiers ou des mots de passe) d’un utilisateur ou d’un processus système. DPAPI est, par exemple, utilisée par le gestionnaire de mots de passe de Windows, plusieurs navigateurs web, plusieurs messageries de discussion instantanées, le stockage des clés Wi-Fi et les certificats. Les données protégées sont chiffrées par une clé appelée master key, qui elle-même est protégée par le mot de passe de l’utilisateur ou une clé du domaine (backup key). Note : le mécanisme DPAPI est réputé robuste et n’est pas remis en question par ce point.
Il est fortement déconseillé de modifier les permissions par défaut des clés DPAPI. Ainsi il recommandé d’enlever les permissions dangereuses sur ces clés afin de revenir à un état par défaut. La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
ID : vuln1_permissions_gmsa_keys vuln2_permissions_gmsa_keys
DESCRIPTION
Des chemins de contrôle dangereux existent vers les clés des group managed service accounts (gMSA). Un attaquant ayant un contrôle sur ces clés est en mesure de récupérer le mot de passe des gMSA associés à ces clés.
RECOMMANDATION
Les comptes membres des gMSA héritent de certaines propriétés des classes utilisateurs et ordinateurs et permettent donc plus de souplesse au niveau de la gestion des comptes de services. Les gMSA utilisent le service de distribution de clés (KDS) pour créer et gérer les mots de passe des comptes. Les mots de passe de ces comptes sont dérivés d’une clé gérée par le KDS.
Il est fortement déconseillé de modifier les permissions par défaut de ces objets. Ainsi il recommandé d’enlever les permissions dangereuses sur ceux-ci afin de retourner à un état par défaut. La correction peut être effectuée à l’aide de la commande Dsacls <DN> /S /T. Cette commande restaure les permissions par défaut à partir du schéma.
ID : vuln1_permissions_dfsr_sysvol vuln2_permissions_dfsr_sysvol
DESCRIPTION
Des chemins de contrôle dangereux existent vers les paramètres du moteur de réplication de fichiers de Microsoft (DFSR) du volume système (SYSVOL). Un attaquant peut enregistrer un nouveau réplica DFS du SYSVOL, modifier son contenu et enfin forcer une synchronisation de celui-ci. Les modèles de stratégie de groupe et / ou les scripts ainsi modifiés seront appliqués (par exemple, sur les contrôleurs de domaine) par les GPO ad hoc, ce qui permet de prendre le contrôle total du domaine.
RECOMMANDATION
Il est fortement déconseillé de changer les permissions par défaut de cet objet. Ainsi il est recommandé d’enlever les permissions dangereuses sur les paramètres DFSR du SYSVOL afin de revenir à un état par défaut. La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
ID : vuln1_permissions_schema vuln2_permissions_schema
DESCRIPTION
Des chemins de contrôle dangereux existent vers les objets du schéma. Un attaquant ayant un contrôle sur le schéma peut prendre le contrôle complet de l’Active Directory.
RECOMMANDATION
Le schéma est l’une des trois partitions (appelées aussi naming context) de l’Active Directory. Il contient la définition de tous les objets de la forêt Active Directory.
Il est fortement déconseillé de changer les permissions par défaut de ces objets. Ainsi il est recommandé d’enlever les permissions dangereuses sur les objets du schéma afin de revenir à un état par défaut. La correction peut être effectuée à l’aide de la commande Dsacls <DN> /S /T. Cette commande restaure les permissions par défaut à partir du schéma.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
1 CHEMINS DE CONTRÔLE DANGEREUX VERS LES SERVEURS MICROSOFTDNS
ID : vuln1_permissions_msdns
DESCRIPTION
Des chemins de contrôle dangereux existent vers les serveurs DNS Microsoft.
Les comptes ayant le droit d’écrire les propriétés du conteneur CN=MicrosoftDNS,CN=System ont la possibilité de faire exécuter du code arbitraire par le service DNS, qui est généralement hébergé par un contrôleur de domaine. Par défaut, les membres du groupe DnsAdmins ont ce droit.
RECOMMANDATION
Il est recommandé de retirer la permission d’écriture sur les propriétés du conteneur CN=MicrosoftDNS,CN=System pour ces comptes.
Si la mise en place d’une telle permission a été faite pour la gestion du DNS, il est possible de créer une délégation manuellement. Cette délégation est généralement effectuée à l’aide de l’utilitaire ldp et elle peut être effectuée en deux étapes.
ÉTAPE 1: AUTORISER L’ACCÈS AUX RPC NÉCESSAIRES À L’UTILISATION DES COMPOSANTS ENFICHABLES DE GESTION DNS
Dans la partition du domaine, dans le conteneur CN=System, déléguer les droits suivants sur le conteneur CN=MicrosoftDNS :
FR EN
Propriété de lecture
Propriété d’écriture
Créer un enfant
Contrôler l’accès
Liste
DACL d’écriture
Supprimer un enfant
Écriture étendue
Afficher la liste pour l’objet
Accès en écriture au propriétaire
Supprimer
Autorisations de lecture
Écrire la liste SACL
Supprimer l’arborescence
ÉTAPE 2: AUTORISER LA MODIFICATION DE LA ZONE DNS
Dans la partition DC=DomainDnsZones, sur chaque zone ayant besoin d’être administrée, déléguer les droits suivants avec héritage sur le conteneur CN=MicrosoftDNS :
FR EN
Propriété de lecture
Propriété d’écriture
Créer un enfant
Contrôler l’accès
Liste
DACL d’écriture
Supprimer un enfant
Écriture étendue
Afficher la liste pour l’objet
Accès en écriture au propriétaire
Supprimer
Autorisations de lecture
Écrire la liste SACL
Supprimer l’arborescence
Attention à ne pas oublier également de déléguer les zones inverses (reverse DNS).
Note : pour changer de naming context (partition) dans ldp, il faut utiliser le menu affichage, arborescence et utiliser le menu déroulant pour sélectionner DomainDnsZones.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
1 CHEMINS DE CONTRÔLE DANGEREUX VERS LES GPO S’APPLIQUANT AUX MEMBRES DES GROUPES PRIVILÉGIÉS
ID : vuln1_permissions_gpo_priv
DESCRIPTION
Des chemins de contrôle dangereux existent vers des GPO s’appliquant aux membres des groupes privilégiés. Un attaquant ayant le contrôle sur ces GPO peut exécuter du code sur les machines utilisées par ces membres et élever ses privilèges.
RECOMMANDATION
Il est recommandé de revoir les permissions positionnées sur les objets GPO.
La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
ID : vuln1_privileged_members_perm vuln2_privileged_members_perm
DESCRIPTION
Des chemins de contrôle dangereux existent vers des membres de groupes privilégiés. Ces chemins de contrôle correspondent à des droits ou privilèges permettant à des utilisateurs non privilégiés de prendre le contrôle de comptes privilégiés.
RECOMMANDATION
La plupart des chemins de contrôle cités dans cette vulnérabilité sont également liés aux vulnérabilités « Permissions dangereuses sur l’objet adminSDHolder » et « Chemins de contrôle dangereux vers les contrôleurs de domaine ». L’application des recommandations associées à ces vulnérabilités corrigera une majorité de ces chemins.
Pour les chemins restants, il est recommandé d’enlever ces permissions dangereuses. La correction est généralement effectuée à l’aide du composant logiciel enfichable ADSI Edit ou de l’utilitaire ldp.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
1 NOMBRE IMPORTANT DE MEMBRES DES GROUPES PRIVILÉGIÉS
ID : vuln1_privileged_members
DESCRIPTION
La forêt contient plus de 50 comptes privilégiés.
La présence d’un nombre important de comptes privilégiés ne permet pas d’en assurer le contrôle : cela induit une mauvaise visibilité des comptes privilégiés réellement nécessaires, une augmentation du risque d’oubli de désactivation ou de suppression d’un compte non utilisé, etc.
RECOMMANDATION
Les groupes privilégiés de l’Active Directory permettent aux utilisateurs qui en sont membres de posséder tous les droits et privilèges sur la forêt. L’utilisation de ces groupes, à l’exception des groupes « Administrateurs » et « Administrateurs du domaine », procure donc un faux sentiment de sécurité.
Il est nécessaire de mettre en place un modèle d’administration permettant de réduire le nombre de comptes privilégiés. Pour cela, il convient de référencer les besoins d’administration de chaque compte et de faire les délégations ad hoc. Par exemple, pour un administrateur ayant besoin de créer et de supprimer des utilisateurs, les délégations nécessaires seront :
· créer un enfant ;
· supprimer un enfant ;
· propriété d’écriture ;
· reset password.
Cette délégation est généralement effectuée à l’aide de l’utilitaire ldp.
Note : l’« Assistant Délégation de contrôle » de l’Active Directory permet également de déléguer certaines actions d’administration. Bien que plus facile d’utilisation, cet assistant positionne trop de privilèges pour certaines délégations. Il est donc conseillé de privilégier l’utilitaire ldp.
Enfin, les règles d’appartenance suivantes doivent être mises en œuvre :
· groupes opératifs : tous vides ;
· groupes réplicateurs : tous vides ;
· groupes d’administration de niveau forêt (entreprise et schéma) : vides et peuplés temporairement uniquement lors d’opérations nécessitant ces droits ;
· groupes d’administration de niveau domaine : aucun compte de service.
1 CONTRÔLEURS DE DOMAINE INCOHÉRENTS
ID : vuln1_dc_inconsistent_uac
DESCRIPTION
Certains contrôleurs de domaine de la forêt possèdent des attributs dans un état incohérent. Ces incohérences peuvent être symptomatiques d’une erreur de configuration (manuelle ou par un logiciel) ou de traces de malveillance.
RECOMMANDATION
Chaque contrôleur de domaine doit posséder les caractéristiques suivantes :
· l’attribut userAccountControl de l’objet machine d’un contrôleur de domaine doit contenir SERVER_TRUST_ACCOUNT (0x00002000)|TRUSTED_FOR_DELEGATION (0x00080000)= 0x00082000 ;
· l’attribut userAccountControl de l’objet machine d’un RODC doit contenir PARTIAL_SECRETS_ACCOUNT (0x04000000)|TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION (0x01000000)|WORKSTATION_TRUST_ACCOUNT (0x00001000)= 0x05001000 ;
· un objet de type server doit exister dans la partition de configuration et avoir un attribut serverReference portant le DN du compte d’ordinateur:
· l’objet server doit avoir un objet fils NTDS Settings de type nTDSDSA (ou nTDSDSARO si c’est un contrôleur de domaine en lecture seule).
La correction est généralement effectuée à l’aide de l’utilitaire ldp.
Note : certains éditeurs créent pour leurs produits des configurations de ce type. C’est notamment le cas pour l’éditeur Riverbed.
1 DÉLÉGATION D’AUTHENTIFICATION CONTRAINTE VERS UN SERVICE D’UN CONTRÔLEUR DE DOMAINE
ID : vuln1_delegation_a2d2
DESCRIPTION
Des comptes possèdent des délégations d’authentification contraintes vers un service d’un contrôleur de domaine. Elles permettent au compte d’élever ses privilèges auprès du contrôleur de domaine.
RECOMMANDATION
La délégation d’authentification contrainte permet à un compte de s’authentifier auprès d’un service Kerberos avec l’identité d’un autre utilisateur (s’étant préalablement authentifié auprès de ce compte). Si cette délégation est autorisée vers une ressource privilégiée (notamment un service présent sur un contrôleur de domaine), elle permet au compte d’élever ses privilèges et de compromettre la forêt.
La délégation d’authentification contrainte vers un service d’un contrôleur de domaine ne doit pas être utilisée.
Pour les comptes concernés, il faut supprimer dans l’attribut msDS-AllowedToDelegateTo tous les Service Principal Name (SPN) référençant les contrôleurs de domaine. Cette opération peut être effectuée directement à partir de l’onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs.
1 DÉLÉGATION D’AUTHENTIFICATION CONTRAINTE AVEC TRANSITION DE PROTOCOLE VERS UN SERVICE D’UN CONTRÔLEUR DE DOMAINE
ID : vuln1_delegation_t2a4d
DESCRIPTION
Des comptes possèdent des délégations d’authentification contraintes avec transition de protocole vers un service d’un contrôleur de domaine. Elles permettent au compte d’élever ses privilèges auprès du contrôleur de domaine.
RECOMMANDATION
La délégation d’authentification contrainte avec transition de protocole permet à un compte de s’authentifier auprès d’un service Kerberos avec l’identité d’un autre utilisateur. Si cette délégation est autorisée vers une ressource privilégiée (notamment un service présent sur un contrôleur de domaine), elle permet au compte d’élever ses privilèges et de compromettre la forêt.
La délégation d’authentification contrainte vers un service d’un contrôleur de domaine ne doit pas être utilisée.
Pour les comptes concernés, il faut supprimer dans l’attribut msDS-AllowedToDelegateTo tous les Service Principal Name (SPN) référençant les contrôleurs de domaine. Cette opération peut être effectuée directement à partir de l’onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs.
1 DÉLÉGATION CONTRAINTE BASÉE SUR LES RESSOURCES, SUR DES CONTRÔLEURS DE DOMAINE
ID : vuln1_delegation_sourcedeleg
DESCRIPTION
Sur les contrôleurs de domaine, la délégation contrainte basée sur les ressources (resource-based constrained delegation) est configurée. Cette configuration accorde à des comptes une délégation complète vers les contrôleurs de domaine.
RECOMMANDATION
La délégation vers des ressources privilégiées (par exemple un service d’un contrôleur de domaine) ne doit pas être utilisée.
Contrairement aux autres types de délégations reposant sur un Service Principal Name (SPN), la délégation contrainte basée sur les ressources est implémentée avec un descripteur de sécurité sur la ressource cible. Ce descripteur de sécurité est stocké dans l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur l’ordinateur cible. Pour retirer cette délégation, il est nécessaire de supprimer l’attribut.
Cette modification peut être réalisée en PowerShell. Par exemple, la commande Set-ADComputer MACHINE -PrincipalsAllowedToDelegateToAccount $Null permet de retirer cette délégation autorisée sur une machine appelée MACHINE.
1 COMPTES PRIVILÉGIÉS SANS PRÉ-AUTHENTIFICATION KERBEROS
ID : vuln1_kerberos_properties_preauth_priv
DESCRIPTION
Des comptes privilégiés n’imposent pas la pré-authentification Kerberos.
RECOMMANDATION
La pré-authentification permet de s’assurer que l’utilisateur connaît un de ses secrets d’authentification lors d’une demande de TGT (ticket Kerberos obtenu auprès d’un contrôleur de domaine). Sans pré-authentification il est possible d’obtenir un ticket chiffré avec un des secrets associés au compte correspondant. Il est ensuite possible de lancer une attaque afin de retrouver le mot de passe de l’utilisateur, ce qui peut être facilité s’il n’est pas assez robuste.
La propriété DONT_REQUIRE_PREAUTH doit être supprimée pour ces comptes et le mot de passe doit être changé.
Par défaut, tous les comptes utilisateur imposent la pré-authentification car la propriété DONT_REQUIRE_PREAUTH n’est pas positionnée. Cette propriété ne doit jamais être positionnée pour les comptes privilégiés du domaine. En cas d’incompatibilité avec une application, celle-ci doit faire l’objet d’une évolution applicative.
1 COMPTES PRIVILÉGIÉS AVEC SPN
ID : vuln1_spn_priv
DESCRIPTION
L’attribut servicePrincipalName (SPN) est positionné pour plusieurs comptes privilégiés.
Il est possible de lancer une attaque afin de retrouver le mot de passe de l’utilisateur, ce qui peut être facilité si celui-ci n’est pas assez robuste.
RECOMMANDATION
Le SPN permet d’associer des noms de service Kerberos à des comptes. Lorsqu’un compte possède un nom de service Kerberos, n’importe quel utilisateur authentifié peut demander un ticket pour ce service. Dans ce cas, le ticket émis est chiffré avec une des clés Kerberos associées au compte correspondant, ce qui permet de faire une attaque par brute force. Par défaut seuls les comptes machine possèdent des SPN, cet attribut doit toujours être vide pour les comptes privilégiés du domaine.
CAS GÉNÉRAL: SUPPRIMER LE SPN
Si les comptes ayant un SPN ont réellement besoin d’être privilégiés, il convient de supprimer leur attribut servicePrincipalName et de changer leur mot de passe.
Note : il est toléré qu’un compte privilégié possède un SPN aux conditions suivantes :
· le compte est un Managed Service Account (sMSA / gMSA) ;
· OU
o une politique de mot de passe affinée (Password Settings Object ou PSO) s’applique sur le compte avec une longueur de mot de passe supérieure à 32 ;
o une politique de mot de passe affinée (Password Settings Object ou PSO) s’applique sur le compte avec une durée d’expiration maximale de 3 ans ;
o le mot de passe du compte a changé depuis la dernière modification du PSO ;
· le compte ne peut utiliser que les algorithmes AES.
CAS PARTICULIER: RETIRER LE COMPTE DES GROUPES PRIVILÉGIÉS
Si les comptes ayant un SPN n’ont pas réellement besoin d’être membres d’un groupe privilégié de l’Active Directory, il est préférable de les retirer de ces groupes et de faire les délégations nécessaires.
1 COMPTES PRIVILÉGIÉS DONT LE MOT DE PASSE N’EXPIRE JAMAIS
ID : vuln1_dont_expire_priv
DESCRIPTION
Certains comptes privilégiés possèdent des mots de passe n’expirant pas.
Si aucun mécanisme de sécurité ne force le changement de ces mots de passe, la récupération d’un compte privilégié permet à un individu malveillant de conserver ces droits d’accès au domaine sur le long terme.
RECOMMANDATION
CAS GÉNÉRAL
Il est recommandé de changer régulièrement les mots de passe des membres des groupes privilégiés (au maximum tous les 3 ans). Afin que la politique de mot de passe du domaine soit imposée sur ces comptes, la propriété DONT_EXPIRE ne doit pas être positionnée. Il convient donc de supprimer cette propriété pour ces comptes et de renouveler régulièrement leur mot de passe dès la suppression de la propriété. Cette action peut être effectuée en décochant la case « Le mot de passe n’expire jamais » dans les propriétés du compte de l’utilisateur (onglet compte).
Note importante : il est déconseillé de forcer ce renouvellement trop fréquemment (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive. La fréquence de changement doit être adaptée en fonction du contexte d’emploi du compte. La politique de mot de passe imposée par le domaine peut être soit globale, soit affinée via le mécanisme des Password Settings Object (PSO).
CAS PARTICULIERS
Si la propriété DONT_EXPIRE a été positionnée car le changement de mot de passe de ces comptes n’est pas possible facilement, cela peut signifier que ces comptes ne sont pas utilisés pour des opérations d’administration (par exemple, des comptes de service). Ces comptes ne doivent en aucun cas être membres d’un groupe privilégié. Il convient de :
· les retirer de ces groupes ;
· leur conférer les délégations nécessaires à leur fonctionnement ;
· documenter une procédure de changement de mot de passe spécifique ;
· d’enlever la propriété DONT_EXPIRE.
CAS DES COMPTES NON UTILISÉS
Il est nécessaire de neutraliser les comptes qui ne sont plus utilisés. La méthode suivante de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
· désactiver le compte ;
· le retirer de tous ses groupes d’appartenance ;
· changer son mot de passe de façon aléatoire. Pour garantir un mot de passe aléatoire, il est recommandé de sélectionner l’option « Une carte à puce est nécessaire pour ouvrir une session interactive » dans les propriétés du compte. Cela revient à positionner l’attribut ADS_UF_SMARTCARD_REQUIRED dans la propriété userAccountControl ;
· éventuellement, déplacer le compte dans une OU dédiée ;
· éventuellement, mettre à jour le champ description du compte afin d’indiquer le contexte de désactivation (date, raison, etc.).
1 COMPTES PRIVILÉGIÉS DONT LE MOT DE PASSE EST INCHANGÉ DEPUIS PLUS DE 3 ANS
ID : vuln1_password_change_priv
DESCRIPTION
La date de dernier changement du mot de passe de comptes privilégiés est supérieure à 3 ans.
RECOMMANDATION
CAS GÉNÉRAL
Afin de limiter l’impact en cas de vol d’un mot de passe, il est nécessaire de mettre en œuvre une politique de renouvellement des mots de passe pour les comptes privilégiés. La durée de ce renouvellement doit être inférieure à 3 ans.
Le compte « Administrateur intégré » (RID 500, utilisé en tant que compte bris de glace ne devant jamais être utilisé sauf en de rares exceptions) doit également faire l’objet d’un changement de mot de passe tous les 3 ans. En effet il est important de s’assurer régulièrement que celui-ci est toujours accessible et que les procédures associées à son utilisation sont toujours correctes.
Note importante : il est déconseillé de forcer ce renouvellement trop fréquemment (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive.
CAS DES COMPTES DE SERVICE
S’il s’agit d’un compte de service où le changement de mot de passe n’est pas possible, il convient de :
· le retirer de ces groupes ;
· lui conférer les délégations nécessaires à son fonctionnement
· étudier la possibilité de recourir aux Managed Service Accounts (sMSA, gMSA).
CAS DES COMPTES NON UTILISÉS
Il est nécessaire de neutraliser les comptes qui ne sont plus utilisés. Cette méthode de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
· désactiver le compte ;
· le retirer de tous ses groupes ;
· changer son mot de passe de façon aléatoire. Pour garantir un mot de passe aléatoire, il est recommandé de sélectionner l’option « Une carte à puce est nécessaire pour ouvrir une session interactive » dans les propriétés du compte. Cela revient à positionner l’attribut ADS_UF_SMARTCARD_REQUIRED dans la propriété userAccountControl ;
· éventuellement, déplacer le compte dans une OU dédiée ;
· éventuellement, mettre à jour le champ description du compte afin d’indiquer le contexte de désactivation (date, raison, etc.).
1 CONTRÔLEURS DE DOMAINE DONT LE MOT DE PASSE DE COMPTE D’ORDINATEUR EST INCHANGÉ DEPUIS PLUS DE 45 JOURS
ID : vuln1_password_change_dc_no_change
DESCRIPTION
Des contrôleurs de domaine n’ont pas changé le mot de passe de leur compte d’ordinateur depuis plus de 45 jours, ce qui indique que leurs secrets ne sont pas renouvelés.
RECOMMANDATION
Dans leur fonctionnement par défaut, les contrôleurs de domaine changent automatiquement le mot de passe de leur compte d’ordinateur périodiquement (30 jours par défaut). Il convient d’investiguer la raison qui empêche le contrôleur de domaine de changer son mot de passe.
Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
· HKLMSystemCurrentControlSetServicesNetlogonParametersDisablePasswordChange : doit valoir 0 ou ne pas exister ;
· HKLMSystemCurrentControlSetServicesNetlogonParametersMaximumPasswordAge : doit valoir 30.
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s’assurer qu’elles ne sont pas positionnées par une GPO.
1 CONTRÔLEURS DE DOMAINES INACTIFS
ID : vuln1_password_change_inactive_dc
DESCRIPTION
Des contrôleurs de domaine ne se sont pas authentifiés depuis plus de 45 jours.
RECOMMANDATION
Dans leur fonctionnement par défaut, les contrôleurs de domaine doivent s’authentifier et changer automatiquement leur mot de passe sur le domaine tous les 30 jours.
L’absence d’authentification au domaine est symptomatique d’une machine désynchronisée. Les contrôleurs de domaine désynchronisés du domaine doivent être réinstallés ou supprimés. Dans le cas d’une réinstallation, afin d’éviter le chemin de contrôle de type OWNER du compte d’ordinateur, il est recommandé d’effectuer une jonction de domaine hors connexion à l’aide de l’utilitaire Djoin.
1 CHEMINS DE CONTRÔLE DANGEREUX VERS LES CONTENEURS DE CERTIFICATS
ID : vuln1_adcs_control
DESCRIPTION
Des chemins de contrôle dangereux existent vers les conteneurs de certificats. Ces chemins de contrôle permettent d’ajouter une autorité de certification malveillante et donc notamment d’usurper des utilisateurs ou des services.
RECOMMANDATION
Lors de l’installation d’un serveur de PKI Microsoft, l’utilisateur réalisant l’installation se voit automatiquement déléguer des droits sur ces conteneurs.
Il est recommandé d’enlever les permissions dangereuses sur ces conteneurs de certificats afin de revenir à un état par défaut. La correction est généralement effectuée à l’aide des consoles adsiedit.msc ou de l’utilitaire ldp.
ID : vuln1_adcs_template_control vuln2_adcs_template_control
DESCRIPTION
Des chemins de contrôle dangereux existent vers les modèles de certificats (certificate templates).
Le contrôle d’un modèle de certificat permet de faire générer par l’autorité de certification un certificat arbitraire. Il est par exemple possible d’obtenir un certificat d’authentification par carte à puce pour n’importe quel utilisateur, et ainsi d’usurper son identité.
Au niveau 1 seuls les modèles publiés par au moins un serveur Active Directory Certificate Services (AD CS) apparaissent. Au niveau 3 l’ensemble des modèles sont concernés.
RECOMMANDATION
Il est recommandé d’enlever les permissions dangereuses sur ces modèles de certificats afin de restaurer l’état par défaut. La correction est généralement effectuée à l’aide de la console adsiedit.msc, pkiview.msc ou de l’utilitaire ldp.
1 COMPTES AVEC UN PRIMARYGROUPID INFÉRIEUR À 1000
ID : vuln1_primary_group_id_1000
DESCRIPTION
Certains utilisateurs ou ordinateurs ont un attribut primaryGroupId en dehors des valeurs par défaut recommandées. Les primaryGroupId inférieurs à 1000 sont souvent privilégiés.
RECOMMANDATION
Dans le fonctionnement d’un Active Directory, l’attribut primaryGroupId d’un compte utilisateur ou machine permet d’affecter implicitement ce compte à un groupe, même si ce groupe n’est pas répertorié par l’attribut memberOf de l’utilisateur. L’appartenance à un groupe via cet attribut n’apparaît pas dans la liste des membres du groupe dans certaines interfaces. Cet attribut peut permettre de dissimuler l’appartenance d’un compte à un groupe.
Il est recommandé de repositionner les attributs primaryGroupId des utilisateurs ou ordinateurs concernés à leur valeur par défaut :
· utilisateurs: 513 (Utilisateurs du domaine) ou 514 (Invités du domaine); ;
· ordinateurs: 515 (Ordinateurs du domaine) ;
· contrôleurs de domaine: 516 (Contrôleurs de domaine) ;
· contrôleurs de domaine en lecture seule (RODC) : 521 (Contrôleurs de domaine en lecture seule).
ID : vuln1_certificates_vuln vuln2_certificates_vuln vuln3_certificates_vuln
DESCRIPTION
Certains certificats possèdent des problèmes et ne doivent plus être utilisés. Cette vulnérabilité peut apparaître aux niveaux 1, 2 et 3 selon le problème rencontré :
· 1 Utilisation de DSA: le Digital Signature Algorithm (DSA), est un algorithme de signature numérique standardisé par le NIST, et fait partie de la spécification Digital Signature Standard adoptée en 1993 (FIPS 186). Le projet FIPS 186-5 (en cours de rédaction) propose la suppression de cet algorithme. Cette suppression interdira l’utilisation de DSA pour générer des signatures numériques. ;
· 1 Taille de clé RSA très faible (< 1024): l’utilisation de modules inférieurs à 1024 bits est considérée comme insuffisante pour garantir une sécurité pratique ;
· 1 Clé vulnérable à la vulnérabilité ROCA: cette vulnérabilité permet de récupérer une clé privée à partir d’une clé publique ;
· 2 Certificat impossible à décoder: cela peut signifier que le certificat est dans un format invalide, et n’est peut-être pas utilisé ;
· 3 Taille de clé RSA faible (< 2048): le Référentiel Général de Sécurité (RGS) recommande une taille minimale de 2048 bits pour une utilisation ne devant pas dépasser l’année 2030 et une taille minimale de 3072 bits pour une utilisation au-delà de 2030 ;
· 3 Signature utilisant un algorithme faible (différent de SHA2 ou de SHA3) : les algorithmes comme MD5 ou SHA1 sont vulnérables aux collisions ;
· 3 Exposant public RSA faible (< 65537) : les calculs de chiffrement et de déchiffrement RSA font intervenir deux autres données que le module, appelées exposant public et exposant secret. Le Référentiel Général de Sécurité (RGS) recommande d’employer des exposants publics supérieurs à 65536.
Un individu malveillant pourrait tenter d’exploiter l’une de ces vulnérabilités pour générer un certificat malveillant avec une signature valide, lui permettant d’usurper l’identité de n’importe quel utilisateur.
RECOMMANDATION
CAS DES AUTORITÉS DE CERTIFICATIONS VALIDES
Il est recommandé de révoquer les certificats problématiques et de les regénérer. Les certificats enfants doivent aussi être regénérés. Enfin, les certificats expirés doivent être purgés des conteneurs de confiance.
Lors de la génération d’un nouveau certificat, il convient de s’assurer que :
· l’algorithme DSA n’est pas utilisé pour la signature du certificat (privilégier RSA ou ECDSA) ;
· la taille de la clé RSA est d’au moins 2048 bits et les exposants publics supérieurs à 65536 ;
· la clé RSA est générée à l’aide d’une bibliothèque à jour (pour éviter les vulnérabilités type ROCA).
CAS DES AUTORITÉS DE CERTIFICATIONS EXPIRÉES
Si le certificat est expiré, il est recommandé de le supprimer de la liste des autorités reconnues de l’Active Directory. Dans le cas d’une utilisation de signature de code, l’autorité de certification peut être redéployée par GPO.
1 COMPTES MEMBRES DU GROUPE DNSADMINS
ID : vuln1_dnsadmins
DESCRIPTION
Plusieurs comptes sont membres du groupe DnsAdmins.
Les membres du groupe DnsAdmins disposent de droits pour gérer le service DNS Microsoft. Parmi ces droits il est possible de faire exécuter du code arbitraire par le service DNS, qui est généralement hébergé par un contrôleur de domaine.
RECOMMANDATION
Il est recommandé de ne pas utiliser le groupe DNSAdmin. Une délégation doit être créée pour la gestion du DNS (création/suppression de zones, gestion des enregistrements, etc.), généralement effectuée à l’aide de l’utilitaire ldp. Cette délégation peut être effectuée en deux étapes.
ÉTAPE 1: AUTORISER L’ACCÈS AUX RPC NÉCESSAIRES À L’UTILISATION DES COMPOSANTS ENFICHABLES DE GESTION DNS
Dans la partition du domaine, dans le conteneur CN=System, déléguer les droits suivants sur le conteneur CN=MicrosoftDNS :
FR EN
Propriété de lecture
Propriété d’écriture
Créer un enfant
Contrôler l’accès
Liste
DACL d’écriture
Supprimer un enfant
Écriture étendue
Afficher la liste pour l’objet
Accès en écriture au propriétaire
Supprimer
Autorisations de lecture
Écrire la liste SACL
Supprimer l’arborescence
ÉTAPE 2: AUTORISER LA MODIFICATION DE LA ZONE DNS
Dans la partition DC=DomainDnsZones, sur chaque zone ayant besoin d’être administrée, déléguer les droits suivants avec héritage sur le conteneur CN=MicrosoftDNS :
FR EN
Propriété de lecture
Propriété d’écriture
Créer un enfant
Contrôler l’accès
Liste
DACL d’écriture
Supprimer un enfant
Écriture étendue
Afficher la liste pour l’objet
Accès en écriture au propriétaire
Supprimer
Autorisations de lecture
Écrire la liste SACL
Supprimer l’arborescence
Attention à ne pas oublier également de déléguer les zones inverses (reverse DNS).
Note : pour changer de naming context (partition) dans ldp, il faut utiliser le menu affichage, arborescence et utiliser le menu déroulant pour sélectionner DomainDnsZones.
De plus, les opérations suivantes sont à réaliser sur le groupe DnsAdmins :
· vider le groupe ;
· s’assurer que le propriétaire du groupe est Administrateurs du domaine ;
· optionnellement, positionner une ACE interdisant à tout le monde de changer le propriétaire, de changer les droits d’accès et d’écrire les membres du groupe.
Si des permissions spécifiques sont nécessaires, il convient de considérer que les comptes ou les groupes délégués sont eux-mêmes privilégiés. Ainsi, ils doivent être correctement protégés et leurs permissions appliquées doivent être au moins aussi restrictives que celles appliquées à l’adminSDHolder. Il est donc nécessaire de leur appliquer des permissions « sécurisées ». Pour cela, il est recommandé d’utiliser la commande Set-ADSyncRestrictedPermissions du module AdSyncConfig.psm1 fourni avec Azure AD Connect. Cette commande supprime l’héritage et applique des permissions (ACE) restreintes.
Exemple d’utilisation de Set-ADSyncRestrictedPermissions pour appliquer des permissions « sécurisées » sur un compte privilégié :
Import-Module .AdSyncConfig.psm1
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
$credential = Get-Credential
Set-ADSyncRestrictedPermissions -ADConnectorAccountDN « CN=COMPTE,CN=Users,DC=exemple,DC=ads » -Credential $credential
Note : le module AdSyncConfig.psm1 peut être directement extrait du fichier d’installation d’Azure AD Connect à l’aide de l’utilitaire intégré msiexec : msiexec /a « AzureADConnect.msi » /qb TARGETDIR=c:temp
Le paquet d’installation peut être téléchargé à l’adresse suivante : https://go.microsoft.com/fwlink/?LinkId=615771.
ID : vuln1_dnszone_bad_prop vuln3_dnszone_bad_prop
DESCRIPTION
Des zones DNS présentent des problèmes de configuration.
Par exemple, la valeur ZONE_UPDATE_UNSECURE (propriété DSPROPERTY_ZONE_ALLOW_UPDATE) permet la mise à jour d’un enregistrement DNS sans authentification. Un individu malveillant peut utiliser cette vulnérabilité pour :
· ajouter arbitrairement un nom DNS ;
· remplacer un nom afin d’usurper une interface d’administration et attendre une authentification pour subtiliser des identifiants.
Note : au niveau 1 seules les zones des domaines et les zones _msdcs associées sont remontées ; au niveau 3 toutes les zones sont remontées.
RECOMMANDATION
Si la propriété DSPROPERTY_ZONE_ALLOW_UPDATE vaut ZONE_UPDATE_UNSECURE, il est recommandé de reconfigurer les zones DNS pour n’autoriser que les mises à jour sécurisées avec la commande suivante: dnscmd <servername> /Config <zone> /AllowUpdate 2
ID : vuln1_dsheuristics_bad vuln2_dsheuristics_bad
DESCRIPTION
Des paramètres dangereux sont configurés dans l’attribut dSHeuristics. Cette vulnérabilité peut apparaître aux niveaux 1 et 2 selon le problème rencontré :
· 1 si fAllowAnonNSPI est différent de 0 ;
· 1 si dwAdminSDExMask est différent de 0 ;
· 2 si fLDAPBlockAnonOps est égal à 2 .
RECOMMANDATION
L’attribut dSHeuristics permet de définir des heuristiques qui sont utilisées pour déterminer le fonctionnement de certains mécanismes de l’Active Directory. Par exemple :
· fLDAPBlockAnonOps permet d’autoriser des opérations LDAP sans authentification ;
· fAllowAnonNSPI permet d’autoriser l’accès anonyme au Name Service Provider Interface (NSPI) ;
· dwAdminSDExMask permet de définir les groupes protégés par le mécanisme SDProp.
Les paramètres dangereux configurés dans la propriété dSHeuristics doivent être modifiés et réinitialisés à leur valeur par défaut :
· fLDAPBlockAnonOps ne doit pas être configuré ou avoir une valeur différente de 2 ;
· fAllowAnonNSPI doit valoir 0 ;
· dwAdminSDExMask doit valoir 0.
La correction est généralement effectuée à l’aide des consoles adsiedit.msc ou de l’utilitaire ldp.
1 RELATIONS D’APPROBATION SORTANTE DE TYPE DOMAINE NON FILTRÉ
ID : vuln1_trusts_domain_notfiltered
DESCRIPTION
Un ou plusieurs domaines de la forêt approuvent un domaine externe sans filtrage.
Un attaquant ayant compromis le domaine externe peut usurper l’identité de n’importe quel utilisateur ou machine du domaine (sauf comptes ayant un RID inférieur à 1000, ce qui exclut les utilisateurs ou les groupes présents par défaut). Il est alors possible pour cet individu malveillant d’accéder à l’ensemble des données du domaine. Si un chemin de contrôle existe pour le compte usurpé, il peut également élever ses privilèges vers « Administrateurs du domaine » et ainsi compromettre l’ensemble de la forêt.
RECOMMANDATION
Depuis Windows 2003, il est possible de filtrer un domaine externe approuvé. Ce mécanisme est appelé « quarantaine ». Ce filtrage empêche tout utilisateur du domaine approuvé d’usurper l’identité d’un utilisateur d’un autre domaine. Les relations d’approbation concernées doivent avoir ce mécanisme de quarantaine activé. Cette action peut être effectuée via la commande netdom trust <domaine> /domain:<domaine_externe_approuvé> /Quarantine:yes.
De plus, il est recommandé de ne pas établir de relation d’approbation sortante depuis une forêt de confiance vers un domaine de moindre confiance / sensibilité.
Note : le type de relation d’approbation est vérifié par la présence ou l’absence de certains attributs ldap. La relation externe relevée dans cette vulnérabilité est déduite de l’absence de l’attribut WITHIN_FOREST. Dans certains cas, lorsque les forêts sont anciennes, les relations d’approbation internes ne sont pas correctement marquéesWITHIN_FOREST. Dans ce cas, il est nécessaire d’effectuer une opération manuelle pour positionner les attributs corrects sur les relations.
1 RELATIONS D’APPROBATION SORTANTES DE TYPE FORÊT AVEC SID HISTORY ACTIVÉ
ID : vuln1_trusts_forest_sidhistory
DESCRIPTION
La forêt approuve une forêt externe, avec un filtrage affaibli. Un attaquant ayant compromis la forêt externe peut usurper l’identité de n’importe quel utilisateur ou machine de la forêt (sauf comptes ayant un RID inférieur à 1000, ce qui exclut les utilisateurs ou les groupes présents par défaut). Il est alors possible pour cet individu malveillant d’accéder à l’ensemble des données de la forêt. Si un chemin de contrôle existe pour le compte usurpé, il peut également élever ses privilèges vers « Administrateurs du domaine » et ainsi compromettre l’ensemble de la forêt.
RECOMMANDATION
Par construction, les relations d’approbation de type forêt sont filtrées. Toutefois, ce filtrage a été affaibli pour permettre le fonctionnement d’un mécanisme appelé sIDHistory, utilisé notamment lors d’une migration de forêt.
Il convient préalablement de justifier l’affaiblissement du filtrage entre ces forêts. Ceci peut être dû à une migration en cours nécessitant le mécanisme du sIDHistory. Si c’est le cas, il est alors nécessaire de terminer cette migration avant de réactiver le filtrage par défaut. Le retour à un état de filtrage par défaut peut être effectué avec la commande netdom trust <forêt> /domain:<forêt_tierce_approuvée> /EnableSIDHistory:no.
1 NOMBRE IMPORTANT DE COMPTES ACTIFS INUTILISÉS
ID : vuln1_user_accounts_dormant
DESCRIPTION
La forêt contient plus de 25% de comptes dormants. Les comptes dormants correspondent à des comptes utilisateur ou machine, non désactivés qui ne se sont pas authentifiés auprès de l’Active Directory depuis plus d’un an. Ces comptes dormants sont soit des comptes légitimes devant être rarement utilisés, soit des comptes obsolètes.
Les comptes obsolètes peuvent donner accès à des personnes n’en ayant plus besoin (suite à un départ par exemple) ou utilisés de manière furtive par un attaquant, ce qui est d’autant plus préjudiciable si ces comptes sont privilégiés. La présence de ces comptes augmente par ailleurs le travail de gestion des comptes (revue de droits, etc.).
RECOMMANDATION
L’absence de politique de gestion des comptes (ou sa mauvaise application) peut entraîner la persistance de comptes obsolètes sur le domaine. Cela peut s’expliquer, par exemple, par le départ ou le changement d’affectation d’un utilisateur, la suppression d’une application ou la mise au rebut d’une machine.
Sont considérés comme dormants des comptes n’ayant plus d’activité auprès du domaine depuis plus d’un an. Sont considérés comme obsolètes des comptes dormants dont l’existence dans le domaine n’est plus justifiée.
Deux critères peuvent être utilisés pour énumérer les comptes dormants dans un domaine :
· les comptes dont le mot de passe doit expirer et pour lesquels la date de dernier changement est supérieure à un an (propriété pwdLastSet) ;
· les comptes n’ayant pas réalisé une authentification auprès du domaine depuis plus d’un an (propriété LastLogonTimestamp). Attention, cette propriété n’est mise à jour que si le niveau de fonctionnalité du domaine est au moins positionné à Windows 2003.
Il convient de déterminer, parmi ces comptes dormants, les comptes obsolètes. En effet, une partie des comptes présentés en annexe peut concerner des comptes dormants légitimes (par exemple un compte de secours) ou encore des comptes utilisés pour créer des boîtes de messagerie Exchange consultées uniquement par délégation. Ces comptes fonctionnels Exchange doivent être désactivés et positionnés dans une OU adéquate.
Il est nécessaire de neutraliser les comptes obsolètes. Cette méthode de neutralisation apporte les mêmes avantages que la suppression tout en conservant la traçabilité offerte par la simple désactivation. Pour neutraliser un compte, il faut :
· désactiver le compte ;
· le retirer de tous ses groupes d’appartenance ;
· changer son mot de passe de façon aléatoire. Pour garantir un mot de passe aléatoire, il est recommandé de sélectionner l’option « Une carte à puce est nécessaire pour ouvrir une session interactive » dans les propriétés du compte. Cela revient à positionner l’attribut ADS_UF_SMARTCARD_REQUIRED dans la propriété userAccountControl ;
· éventuellement, déplacer le compte dans une OU dédiée ;
· éventuellement, mettre à jour le champ description du compte afin d’indiquer le contexte de désactivation (date, raison, etc.).
2 COMPTES MEMBRES DE GROUPES PRIVILÉGIÉS AVEC UNE MAUVAISE POLITIQUE DE MOT DE PASSE
ID : vuln2_privileged_members_password
DESCRIPTION
Une politique de mot de passe faible est imposée à des comptes privilégiés.
RECOMMANDATION
Il est recommandé d’appliquer une politique de mot de passe pour les comptes privilégiés avec :
· un renouvellement au maximum tous les 3 ans ;
· une longueur d’au moins 8 caractères.
Note importante : il est déconseillé de forcer un renouvellement trop fréquent (quelques mois). Une demande de renouvellement trop fréquente induit statistiquement un nouveau choix de mot de passe plus faible, ce qui en fait une mesure de sécurité contre-productive.
2 DÉLÉGATION D’AUTHENTIFICATION NON CONTRAINTE
ID : vuln2_delegation_t4d
DESCRIPTION
Des comptes de la forêt possèdent des délégations d’authentification non contraintes. Cette délégation permet d’usurper l’identité de tout utilisateur s’authentifiant auprès de ces comptes.
RECOMMANDATION
La délégation d’authentification non contrainte permet à un compte de s’authentifier auprès de n’importe quel service Kerberos avec l’identité d’un utilisateur (s’étant préalablement authentifié auprès de ce compte). Elle n’est donnée par défaut qu’aux contrôleurs de domaine et ne doit pas être accordée à d’autres comptes.
Pour les comptes concernés, il convient de supprimer la propriété TRUSTED_FOR_DELEGATION présente dans l’attribut userAccountControl. Cette opération peut être effectuée directement à partir de l’onglet « Délégation » de la console de gestion des utilisateurs et ordinateurs. Si une délégation Kerberos doit être mise en œuvre, il faut utiliser la délégation contrainte.
2 COMPTES SANS PRÉ-AUTHENTIFICATION KERBEROS
ID : vuln2_kerberos_properties_preauth
DESCRIPTION
Des comptes n’imposent pas la pré-authentification Kerberos. Sans pré-authentification il est possible d’obtenir un ticket chiffré avec un des secrets associés au compte correspondant. Il est ensuite possible de lancer une attaque afin de retrouver le mot de passe de l’utilisateur, ce qui peut être facilité s’il n’est pas assez robuste.
RECOMMANDATION
La pré-authentification permet de s’assurer que l’utilisateur connaît un de ses secrets d’authentification lors d’une demande de TGT (ticket Kerberos obtenu auprès d’un contrôleur de domaine). Par défaut, les comptes utilisateur imposent la pré-authentification. Cette propriété ne doit jamais être positionnée pour les comptes du domaine.
CAS GÉNÉRAL
La propriété DONT_REQUIRE_PREAUTH doit être supprimée pour ces comptes et le mot de passe doit être changé.
CAS PARTICULIERS
En cas d’incompatibilité avec une application, celle-ci doit faire l’objet d’une évolution applicative. Ce problème peut être réduit via les contournements suivants:
· une politique de mot de passe affinée (Password Settings Object ou PSO) s’applique sur le compte avec une longueur de mot de passe supérieure à 32 ;
· une politique de mot de passe affinée (Password Settings Object ou PSO) s’applique sur le compte avec une durée d’expiration maximale de 3 ans ;
· le mot de passe du compte a changé depuis la dernière modification du PSO ;
· le compte ne peut utiliser que les algorithmes AES.
2 COMPTES UTILISATEURS AVEC UN CHIFFREMENT KERBEROS FAIBLE
ID : vuln2_kerberos_properties_deskey
DESCRIPTION
La propriété USE_DES_KEY_ONLY est positionnée pour plusieurs utilisateurs. Cette propriété autorise les contrôleurs de domaine à émettre des tickets chiffrés avec l’algorithme DES, afin d’assurer une compatibilité avec d’anciennes implémentations Kerberos. Cet algorithme est considéré comme obsolète et ne doit plus être utilisé. Il diminue grandement la robustesse des tickets Kerberos émis et simplifie les attaques parbrute force.
RECOMMANDATION
Le support des familles de chiffrement par les systèmes Windows est, dans une configuration par défaut, le suivant :
· Windows XP et Windows Server 2003 : DES et RC4 ;
· Windows Vista et Windows Server 2008 : DES, RC4 et AES ;
· Windows 7 et Windows Server 2008 R2 (et suivants) : RC4 et AES. DES est supporté mais désactivé par défaut.
La propriété USE_DES_KEY_ONLY doit être retirée de l’attribut userAccountControl des comptes. Cette opération peut être effectuée directement à partir de l’onglet « Compte » de la console de gestion des utilisateurs et ordinateurs, en décochant la case « Utiliser uniquement les types de chiffrement DES via Kerberos pour ce compte ».
En cas d’incompatibilité avec une application, celle-ci doit faire l’objet d’une évolution applicative.
2 COMPTES DONT LE MOT DE PASSE N’EXPIRE JAMAIS
ID : vuln2_dont_expire
DESCRIPTION
Certains comptes possèdent des mots de passe n’expirant pas. La récupération d’un compte permet à un individu malveillant de conserver ses droits d’accès au domaine sur le long terme.
RECOMMANDATION
CAS GÉNÉRAL
Afin qu’un renouvellement soit imposé techniquement par l’Active Directory, il est nécessaire que les comptes ne possèdent pas la propriété DONT_EXPIRE. Cette propriété doit être supprimée et le mot de passe être changé.
CAS DES COMPTES DE SERVICE
Pour être en mesure de changer le mot de passe des comptes de service et de pouvoir tracer leur utilisation, il est nécessaire de documenter leur emploi. Un document doit ainsi recenser tous les comptes de service et leur utilisation. Il doit contenir pour chaque compte de service identifié :
· les informations concernant le compte (samAccountName, description, groupes AD, caractéristiques, etc.) ;
· les applications ou les systèmes qui utilisent ce compte ;
· la date de dernier changement du mot de passe associé au compte ;
· la procédure de changement du mot de passe du compte ;
· une personne ou une équipe responsable de son cycle de vie.
2 SERVEURS DONT LE MOT DE PASSE DE COMPTE D’ORDINATEUR EST INCHANGÉ DEPUIS PLUS DE 90 JOURS
ID : vuln2_password_change_server_no_change_90
DESCRIPTION
Des serveurs n’ont pas changé le mot de passe de leur compte d’ordinateur depuis plus de 90 jours, ce qui indique que leurs secrets ne sont pas renouvelés.
RECOMMANDATION
Dans leur fonctionnement par défaut, les serveurs changent automatiquement le mot de passe de leur compte d’ordinateur périodiquement (30 jours par défaut). Il convient d’investiguer la raison qui empêche les serveurs de changer leur mot de passe.
Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
· HKLMSystemCurrentControlSetServicesNetlogonParametersDisablePasswordChange : doit valoir 0 ou ne pas exister ;
· HKLMSystemCurrentControlSetServicesNetlogonParametersMaximumPasswordAge : doit valoir 30.
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s’assurer qu’elles ne sont pas positionnées par une GPO.
2 UTILISATION DE NTFRS POUR LA RÉPLICATION DU SYSVOL
ID : vuln2_sysvol_ntfrs
DESCRIPTION
Des contrôleurs de domaines sont configurés pour utiliser le protocole de réplication NTFRS (en particulier pour la réplication du SYSVOL). Ce protocole est obsolète et rajoute inutilement des interfaces d’administration aux contrôleurs de domaine. De plus, ce protocole n’est plus supporté par les dernières versions de Windows Server, ce qui empêche la migration vers les dernières versions.
RECOMMANDATION
Il est recommandé d’utiliser uniquement le mécanisme Distributed File System Replication (DFSR) pour synchroniser des répertoires sur différents serveurs, en particulier pour la réplication du SYSVOL.
Note : NTFRS n’est plus supporté dans les dernières versions de Windows Server. Le processus de migration vers DFSR est documenté par Microsoft : https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr.
2 MAUVAISES VERSIONS DE L’ACTIVE DIRECTORY
ID : vuln2_adupdate_bad
DESCRIPTION
La mise à jour du schéma est en révision 15. Cette mise à jour crée un chemin de contrôle permettant le contrôle total de l’Active Directory par certains groupes.
RECOMMANDATION
La mise à jour du schéma ayant pour révision 15 positionne des ACE trop permissives aux groupes « Key Admins » et « Enterprise Key Admins ». La mise à jour du schéma présente dans Windows server, version 1709 (et suivants) corrige ce problème. Il est donc recommandé de mettre à jour le schéma.
Cette opération est généralement effectuée à l’aide de l’utilitaire adprep, présent sur le média d’installation d’un Windows Server à jour. Les commandes permettant de réaliser cette action sont adprep /ForestPrep puis adprep /DomainPrep.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd464018(v=ws.10)
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd464018(v=ws.10)
2 LE GROUPE « PRE-WINDOWS 2000 COMPATIBLE ACCESS » CONTIENT « ANONYMOUS »
ID : vuln2_compatible_2000_anonymous
DESCRIPTION
Le mécanisme de compatibilité pré-Windows 2000 est activé. Cela se caractérise par la présence de l’identifiant de sécurité « Anonymous » (S-1-5-7) dans les membres du groupe « Accès compatible pré-Windows 2000 ». Ce mécanisme permet une énumération anonyme de certains éléments auprès des contrôleurs de domaine.
RECOMMANDATION
Le mécanisme de compatibilité pré-Windows 2000 permet d’assurer le support des systèmes antérieur à Windows 2000 (Windows NT 4.0). Historiquement utilisé pour des raisons de rétrocompatibilité, le groupe « Accès compatible pré-Windows 2000 » ne doit contenir que « Utilisateurs authentifiés » (S-1-5-11).
2 MOT DE PASSE DU COMPTE KRBTGT INCHANGÉ DEPUIS PLUS D’UN AN
ID : vuln2_krbtgt
DESCRIPTION
Le mot de passe du compte krbtgt n’a pas été changé depuis plus d’un an.
Le compte krbtgt est un compte d’infrastructure servant de support de stockage aux clés des centres de distribution des clés Kerberos. La compromission du compte krbtgt permet à un attaquant de forger des tickets Kerberos (souvent appelés golden tickets) et ainsi de pouvoir s’authentifier auprès de n’importe quelle ressource (serveur, poste de travail, etc.) du domaine Active Directory avec des droits d’administration, et ce, de manière relativement furtive. Le compte krbtgt ne changeant pas automatiquement de mot de passe, si la base des comptes de l’Active Directory a été extraite (par exemple par un ancien administrateur, lors d’un audit ou pour un test de robustesse des mots de passe), il est possible, tant que ce mot de passe n’a pas été changé, d’utiliser les informations contenues dans la base afin d’en extraire les secrets. Une personne malveillante peut ainsi s’authentifier sur l’ensemble des services du domaine Active Directory plusieurs années après.
RECOMMANDATION
Le compte krbtgt est un compte d’infrastructure servant de support de stockage aux clés des centres de distribution des clés Kerberos. Afin de renouveler les clés Kerberos utilisées pour chiffrer les TGT, il est nécessaire de procéder annuellement à un changement manuel du mot de passe du compte krbtgt. Il est conseillé d’effectuer ce changement en utilisant le script mis à disposition par Microsoft. Pour que le script fonctionne sur une machine installée en français, il faut effectuer les modifications suivantes :
· ligne 62 : replacer « *completed* » par « *effectués* » ;
· ligne 84 : replacer « *Successfully replicated object* » par « *a été correctement répliqué* ».
Le changement de mot de passe doit être effectué deux fois pour être efficace.
Attention: toute opération de changement du mot de passe du compte krbtgt doit être effectuée uniquement dans un environnement Active Directory où la réplication entre contrôleurs de domaine est nominale. Ainsi il est indispensable d’attendre un délai avant le deuxième changement de mot de passe.
Il est également possible de réinitialiser manuellement le mot de passe du compte krbtgt, de la même façon qu’un compte classique. Si le script mis à disposition n’est pas utilisé, il est recommandé un délai d’au minimum 24 heures entre les deux changements et de s’assurer de la réplication effective entre contrôleurs de domaine. Une stratégie peut être d’effectuer un unique changement de mot de passe tous les 6 mois, afin de garantir un changement effectif annuel.
2 COMPTES OU GROUPES PRIVILÉGIÉS PRÉSENTS DANS LES ATTRIBUTS DE RÉVÉLATION DES RODC
ID : vuln2_rodc_priv_revealed
DESCRIPTION
Des comptes privilégiés ont été révélés sur des RODC, ce qui signifie que leurs secrets d’authentification y sont mis en cache. Une compromission de ces machines (généralement plus exposées que des contrôleurs de domaine classiques) permet de compromettre l’intégralité du domaine.
RECOMMANDATION
Les RODC conservent, entre autres, une copie d’une partie des secrets du domaine. Par défaut, les comptes membres de groupes privilégiés ne sont pas révélés (c’est-à-dire copiés) sur les RODC. Cette mesure permet de limiter l’impact d’un accès malveillant aux seuls comptes révélés sur les RODC. Les utilisateurs privilégiés ne doivent donc pas être révélés sur les RODC.
Pour cela, les contrôleurs de domaine en lecture seule (RODC) doivent comporter dans l’attribut msDS-NeverRevealGroup au minimum les valeurs suivantes :
· « Administrateurs » ;
· « Administrateurs du domaine » ;
· « Opérateurs de compte » ;
· « Opérateurs de serveur » ;
· « Opérateurs de sauvegarde » ;
· « Groupe de réplication de mot de passe RODC refusée ».
Cette opération peut être effectuée directement à partir de l’onglet « Stratégie de réplication de mot de passe » de la console de gestion des utilisateurs et ordinateurs.
2 COMPTES OU GROUPES AYANT UN HISTORIQUE DE SID D’APPARENCE NON CONFORME
ID : vuln2_sidhistory_dangerous
DESCRIPTION
Plusieurs comptes ou groupes de la forêt possèdent un attribut sIDHistory ayant la valeur d’un well-known SID (SID des utilisateurs et groupes génériques) ou d’un SID privilégié de domaine. Ce mécanisme peut être utilisé par des attaquants pour s’accorder illégitimement des droits d’accès.
RECOMMANDATION
La propriété sIDHistory permet de rajouter un identifiant de sécurité (SID) arbitraire dans la liste des groupes d’un compte utilisateur ou machine. Ce mécanisme est principalement utilisé lors de la migration de comptes d’un domaine à un autre pour perpétuer l’accès à d’anciennes ressources.
Une investigation doit être menée pour expliquer la présence de ces SID non conformes. L’attribut sIDHistory doit être effacé pour tous les comptes et groupes concernés dès lors que les opérations de migration ont été effectuées.
2 COMPTES DE TRUST DONT LE MOT DE PASSE EST INCHANGÉ DEPUIS PLUS D’UN AN
ID : vuln2_trusts_accounts
DESCRIPTION
Les comptes de trust n’ont pas eu leur mot de passe changé depuis plus d’un an. Cela peut signifier que les relations d’approbation ont été supprimées, mais que les comptes associés sont toujours présents.
RECOMMANDATION
CAS D’UNE RELATION D’APPROBATION SUPPRIMÉE
Certains comptes de trust restent présents alors que les relations associées ont été supprimées. Il faut donc supprimer ces comptes.
CAS D’UNE RELATION D’APPROBATION NON SUPPRIMÉE
Il est recommandé de changer au moins annuellement les mots de passe des comptes de trust. Ce changement doit être automatique entre les environnements Microsoft. Il convient également d’investiguer la cause du non-renouvellement automatique de ce mot de passe.
3 SERVEURS DONT LE MOT DE PASSE DE COMPTE D’ORDINATEUR EST INCHANGÉ DEPUIS PLUS DE 45 JOURS
ID : vuln3_password_change_server_no_change_45
DESCRIPTION
Des serveurs n’ont pas changé le mot de passe de leur compte d’ordinateur depuis plus de 45 jours, ce qui indique que leurs secrets ne sont pas renouvelés.
RECOMMANDATION
Dans leur fonctionnement par défaut, les serveurs changent automatiquement le mot de passe de leur compte d’ordinateur périodiquement (30 jours par défaut). Il convient d’investiguer la raison qui empêche les serveurs de changer leur mot de passe.
Une première vérification consiste à vérifier la valeur des entrées de Registre suivantes :
· HKLMSystemCurrentControlSetServicesNetlogonParametersDisablePasswordChange : doit valoir 0 ou ne pas exister ;
· HKLMSystemCurrentControlSetServicesNetlogonParametersMaximumPasswordAge : doit valoir 30.
Si ces valeurs sont incorrectes, il convient de les remettre aux valeurs par défaut et de s’assurer qu’elles ne sont pas positionnées par une GPO.
3 SERVEURS INACTIFS
ID : vuln3_password_change_inactive_servers
DESCRIPTION
Des serveurs ne se sont pas authentifiés depuis plus de 90 jours.
RECOMMANDATION
Dans leur fonctionnement par défaut, les serveurs doivent s’authentifier et changer automatiquement leur mot de passe sur le domaine tous les 30 jours. Les serveurs non utilisés doivent être désactivés.
L’absence d’authentification au domaine est symptomatique d’une machine désynchronisée. Les serveurs désynchronisés du domaine doivent réinstallés ou supprimés. Dans le cas d’une réinstallation, afin d’éviter le chemin de contrôle de type OWNER du compte machine, il est recommandé d’effectuer une jonction de domaine hors connexion à l’aide de l’utilitaire Djoin.
3 COMPTES AVEC UN PRIMARYGROUPID MODIFIÉ
ID : vuln3_primary_group_id_nochange
DESCRIPTION
Certains utilisateurs ou ordinateurs ont un attribut primaryGroupId modifié.
RECOMMANDATION
Dans le fonctionnement d’un Active Directory, l’attribut primaryGroupId d’un compte utilisateur ou machine permet d’affecter implicitement ce compte à un groupe, même si ce groupe n’est pas répertorié par l’attribut memberOf de l’utilisateur. L’appartenance à un groupe via cet attribut n’apparaît pas dans la liste des membres du groupe dans certaines interfaces. Cet attribut dissimule l’appartenance d’un compte à un groupe privilégié.
Il est recommandé de repositionner les attributs primaryGroupId des utilisateurs ou ordinateurs concernés à leur valeur par défaut :
· utilisateurs: 513 (Utilisateurs du domaine) ou 514 (Invités du domaine); ;
· ordinateurs: 515 (Ordinateurs du domaine) ;
· contrôleurs de domaine: 516 (Contrôleurs de domaine) ;
· contrôleurs de domaine en lecture seule (RODC) : 521 (Contrôleurs de domaine en lecture seule).
3 COMPTES OU GROUPES MEMBRES DE « PRE-WINDOWS 2000 COMPATIBLE ACCESS »
ID : vuln3_compatible_2000_not_default
DESCRIPTION
Le mécanisme de compatibilité pré-Windows 2000 est activé pour certains comptes. Ce mécanisme permet l’accès à certaines RPC aux membres du groupe Pre-Windows 2000 Compatible Access. Selon le paramétrage système, le groupe intégré Tout le monde peut contenir les utilisateurs anonymes, ce qui peut augmenter le risque s’il est membre du groupe de rétro-compatibilité.
RECOMMANDATION
Le mécanisme de compatibilité pré-Windows 2000 permet d’assurer le support des domaines de type Windows NT. Historiquement utilisé pour des raisons de rétrocompatibilité, le groupe « Accès compatible pré-Windows 2000 » ne doit contenir que « Utilisateurs authentifiés » (S-1-5-11).
Note : les serveurs ADCS sont inscrits dans ce groupe lors de leur installation. Dans la plupart des cas, l’appartenance à ce groupe n’est pas nécessaire et peut être supprimée. Cette opération est facilement réversible.
3 OBJETS AYANT UN PROPRIÉTAIRE INADAPTÉ
ID : vuln3_owner
DESCRIPTION
Des objets ont des propriétaires non standard.
Note : seuls les 20 premiers objets sont affichés.
Note : seuls les 20 premiers objets sont affichés.
RECOMMANDATION
Tous les objets (utilisateurs, groupes, sMSA, gMSA, ordinateurs, OU et GPO) doivent avoir pour propriétaire l’un des objets suivants :
· « Administrateurs du domaine » ;
· « Administrateurs de l’entreprise » ;
· « Administrateurs » ;
· « Système local ».
3 COMPTES PRIVILÉGIÉS NON MEMBRES DU GROUPE PROTECTED USERS
ID : vuln3_protected_users
DESCRIPTION
Des comptes privilégiés ne sont pas protégés par le groupe Protected Users.
RECOMMANDATION
L’ensemble des comptes privilégiés doivent être ajoutés au groupe Protected Users afin de :
· forcer l’authentification en Kerberos ;
· réduire la durée de vie des tickets Kerberos ;
· forcer l’utilisation d’algorithmes de chiffrement forts (AES) ;
· interdire la mise en cache du mot de passe sur les postes de travail ;
· interdire toute forme de délégation.
Attention : l’utilisation du groupe Protected Users a des impacts fonctionnels importants.
Référence : https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group.
Référence : https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group.
3 COMPTES AYANT LEUR MOT DE PASSE STOCKÉ DE MANIÈRE RÉVERSIBLE
ID : vuln3_reversible_password
DESCRIPTION
Des comptes ont leur mot de passe stocké de manière réversible dans l’annuaire.
Il est possible, en possédant des droits d’administrateur de récupérer en clair les mots de passe concernés.
RECOMMANDATION
Afin d’éviter les faiblesses dans la gestion des mots de passe, il est nécessaire de retirer les propriétés dangereuses relatives aux mots de passe des comptes utilisateur. Cette action peut être effectuée à l’aide de la console « Utilisateurs et ordinateurs AD ». Il faut pour cela décocher la case « Enregistrer le mot de passe en utilisant un chiffrement réversible » dans l’onglet « Compte » des propriétés du compte en question. Cela a pour effet de retirer la propriété ENCRYPTED_TEXT_PASSWORD_ALLOWED de l’attribut userAccountControl.
Si ces paramètres correspondent à un besoin métier légitime, il convient de le documenter, par exemple en l’indiquant dans le commentaire du compte.
3 CONFIGURATION DANGEREUSE DES CONTRÔLEURS DE DOMAINE EN LECTURE SEULE (RODC) (NEVERREVEAL)
ID : vuln3_rodc_never_reveal
DESCRIPTION
La forêt possède des contrôleurs de domaine en lecture seule (RODC) avec des attributs de révélation dangereux. Des groupes par défaut sont manquants dans l’attribut msDS-NeverRevealGroup sur des RODC.
RECOMMANDATION
L’attribut msDS-NeverRevealGroup permet d’interdire la révélation des secrets des objets qui y sont listés (et ce, de manière récursive).
Les contrôleurs de domaine en lecture seule (RODC) doivent comporter dans l’attribut msDS-NeverRevealGroup au minimum les valeurs suivantes :
· Administrateurs ;
· Opérateurs de serveur ;
· Opérateurs de compte ;
· Opérateurs de sauvegarde ;
· Groupe de réplication de mot de passe RODC refusée.
3 COMPTES OU GROUPES PRIVILÉGIÉS PRÉSENTS DANS LES ATTRIBUTS DE RÉVÉLATION DES RODC
ID : vuln3_rodc_reveal
DESCRIPTION
La forêt possède des contrôleurs de domaine en lecture seule (RODC) avec des attributs de révélation dangereux. En effet, certains utilisateurs ou groupes privilégiés (RID < 1000) sont présents dans l’attribut msDS-RevealOnDemandGroup.
RECOMMANDATION
L’attribut msDS-RevealOnDemandGroup permet de définir les utilisateurs et groupes autorisés à être révélés sur un RODC.
Les contrôleurs de domaine en lecture seule (RODC) ne doivent pas comporter dans cet attribut des groupes dont le RID est inférieur à 1000.
3 CONFIGURATION DANGEREUSE DES GROUPES DE RÉPLICATION POUR LES CONTRÔLEURS DE DOMAINE EN LECTURE SEULE (RODC) (ALLOW)
ID : vuln3_rodc_allowed_group
DESCRIPTION
Le groupe Groupe de réplication dont le mot de passe RODC est autorisé n’est pas vide.
RECOMMANDATION
Les secrets des membres du groupe Groupe de réplication de mot de passe RODC autorisée peuvent être révélés sur l’ensemble des RODC.
Il est recommandé de vider ce groupe et d’utiliser des groupes spécifiques dans la PRP (Password Replication Policy) de chaque RODC.
3 CONFIGURATION DANGEREUSE DES GROUPES DE RÉPLICATION POUR LES CONTRÔLEURS DE DOMAINE EN LECTURE SEULE (RODC) (DENIED)
ID : vuln3_rodc_denied_group
DESCRIPTION
Le groupe Groupe de réplication de mot de passe RODC refusée ne possède pas l’ensemble de ses membres par défaut.
RECOMMANDATION
Le groupe Groupe de réplication de mot de passe RODC refusée doit avoir au minimum les membres suivants (intégrés par défaut) :
· Contrôleurs de domaine ;
· Contrôleurs de domaine en lecture seule ;
· Propriétaires créateurs de la stratégie de groupe ;
· Administrateurs du domaine ;
· Éditeurs de certificats ;
· Administrateurs de l’entreprise ;
· Administrateurs du schéma ;
· KRBTGT.
3 COMPTES OU GROUPES AYANT UN HISTORIQUE DE SID
ID : vuln3_sidhistory_present
DESCRIPTION
Des comptes ou groupes de la forêt possèdent un attribut sIDHistory non vide.
La présence de sIDHistory entraine inutilement la génération d’événements Windows 4665 et 4666, ce qui peut rendre plus difficile la supervision. De plus, leur utilisation légitime impose un affaiblissement de la sécurité des relations d’approbation.
RECOMMANDATION
La propriété sIDHistory permet de rajouter un identifiant de sécurité (SID) arbitraire dans la liste des groupes d’un compte utilisateur ou machine. Ce mécanisme est principalement utilisé lors de la migration de comptes d’un domaine à un autre pour perpétuer l’accès à d’anciennes ressources. Il peut également être utilisé par des attaquants pour s’accorder illégitimement des droits d’accès.
L’attribut sIDHistory doit être effacé pour tous les comptes et groupes concernés dès lors que les opérations de migration ont été effectuées.
3 RELATIONS D’APPROBATION ENTRANTE AVEC DÉLÉGATION
ID : vuln3_trusts_tgt_deleg
DESCRIPTION
Des relations d’approbation autorisent la délégation Kerberos. Par construction, ces relations permettent aux ressources externes approuvées de pouvoir s’authentifier avec l’identité des comptes qui s’y connectent (comptes membres de la forêt analysée). Cela permet à un attaquant ayant compromis le domaine externe approuvé d’élever ses privilèges vers le domaine local approuvant.
RECOMMANDATION
Une relation d’approbation entrante permet d’être approuvé par un domaine externe ou une forêt tierce. Cela permet aux comptes de se connecter à des ressources externes à la forêt.
Une relation d’approbation entrante doit interdire la délégation Kerberos vers la ressource approuvante. À partir de Windows 2012 il est possible de désactiver la délégation de TGT à l’aide de la commande netdom trust <domaine> /domain:<domaine_externe_approuvé> /EnableTGTDelegation:no
Source: https://www.cert.ssi.gouv.fr/dur/CERTFR-2020-DUR-001/