Compte rendu conférence SSTIC 2019 : Audit des GPO

Benjamin Parret Non classé

Les GPO (ou Stratégies de groupe) permettent la gestion centralisée et le déploiement de configurations sur un domaine Active Directory. Durant le SSTIC 2019, Aurélien Bordes a présenté, lors d’une conférence intitulée « Audit des GPO », différents points d’audit pour permettre de mieux analyser ce type d’environnement.
De plus, le conférencier a présenté deux outils utiles à l’analyse : gpocheck et gpo2sql.
– GPOCheck : Outil qui permet de vérifier les droits d’un répertoire SYSVOL. Cela a pour but de vérifier que les droits des répertoires soient bien synchronisés avec ceux des objets GPO.
– gpo2sql : Permet de visualiser un export de GPO XML en tables SQL. Cela permet une analyse via des requêtes SQL.
Ces outils sont disponibles ici.
La conférence se découpe en deux phases. Une première dans laquelle Aurélien Bordes a introduit et présenté les GPO, puis une deuxième axée sur l’audit et la présentation des outils.
L’article complet et la vidéo de la conférence sont disponibles sur le lien : https://www.sstic.org/2019/presentation/audit-gpo/

Nous commencerons ce compte rendu en précisant les termes qui seront utilisés :

– AD : Active Directory
– OU : Organisational Unit
– GPO : Group Policy Object
– GPT : Group Policy Template
– GPC : Group Policy Container
– GPMC : Group Policy Management Console
– DFS-R : Distributed File System Replication
– DFS-N : Distributed File System Namespaces
– CSE : Client Side Extension

Les propriétés d’une GPO sont définies dans une classe « groupPolicyContainer » qui est un conteneur Active Directory. On trouve de nombreuses propriétés dans cette classe, par exemple, l’identifiant unique (cn), le nom (displayName), ou encore le niveau fonctionnel de la GPO (gPCFunctionalityVersion).
Il est possible d’envoyer des requêtes à un domaine pour obtenir la liste des GPO en filtrant la recherche sur la requête LDAP ‘objectClass=groupPolicyContainer’.

En plus des GPO du domaine, il existe des GPO locales qui permettent d’appliquer des paramètres sur des comptes locaux ou des postes hors domaine.

Hormis les propriétés intégrées dans les objets groupPolicyContainer, il est nécessaire de disposer d’espaces de stockage pour stocker les paramètres définis par les GPO. Ce stockage peut être réalisé de deux manières :
– Directement dans l’AD, sous forme d’objets en utilisant des classes particulières.
– Via des fichiers. Pour chaque GPO, un répertoire dédié est créé. Ce répertoire est appelé GPT. Ce type de stockage est majoritairement utilisé.

Ces répertoires doivent être accessibles pour tous les postes du domaine. Ils sont donc partagés par les contrôleurs de domaine sous la forme : \\domain.tld\SYSVOL\Policies\
Ce partage est réalisé via les protocoles DFS-R et DFS-N. Anciennement, il se faisait via le protocole NTFRS mais ce dernier a été remplacé. Sur les systèmes en place, la migration n’est pas automatique et il faut donc s’assurer que celle-ci a bien été effectuée.

Premier point de contrôle : vérifier la migration de NTFRS vers DFS-R
Un utilitaire permet de vérifier le protocole utilisé et également d'effectuer la migration : dfsrmig Pour vérifier le protocole utilisé, depuis un contrôleur de domaine :
dfsrmig /GetMigrationState and dfsrmig /GetGlobalState Si la valeur de retour est "DFSR migration has not yet initialized", alors il faudra procéder à la migration. Si la valeur de retour est 3, alors la migration a déjà été effectuée.

L’ensemble des GPO ne s’applique pas à tous les postes et utilisateurs. Les paramètres gPLink et gPOptions activent l’applications de GPO en fonction des classes sur lesquelles ils sont placés :
– organizationalUnit : s’applique sur une ‘OU’
– samDomain : s’applique sur le domaine
– site : s’applique sur un site Active Directory
Ils référencent respectivement la ou les GPO, puis les propriétés du conteneur.

Du côté client, le service moteur GPSvc gère l’application des GPO avec le contexte LocalSystem. Il est probable que ce dernier utilise l’identité de l’utilisateur pour certaines actions, notamment savoir quelles GPO appliquer.
Les CSE, qui sont des bibliothèques dynamiques (DLL), sont chargées par le moteur GPO et servent à appliquer une tâche dédiée sur un type de paramètre spécifique. Une CSE est identifiée par un GUID et enregistrée dans le registre. Sous sa clé se trouve différentes valeurs pour la caractériser (DisplayName, ProcessGroupPolicy, ..). C’est le moteur GPSvc qui va charger et activer les CSE à condition d’être référencées dans l’attribut ‘gPCMachineExtensionNames’ (ou ‘gPCUserExtensionNAmes’) de l’objet GPO.
Cette fonctionnalité étant gérée par les administrateurs des GPO, il est possible d’y retrouver des références à des CSE obsolète ou inexistantes.

Deuxième point de contrôle : Vérifier les références aux CSE

Comme vu précédemment, le contexte LocalSystem est utilisé par le moteur GPSvc pour appliquer les CSE. Il est donc important de vérifier quelles CSE sont référencées dans les attributs 'gPCMachineExtensionNames' et 'gPCUserExtensionNames', mais également les CSE enregistrées sous la clé GPExtension

Du point de vue de la sécurité des échanges entre les clients GPO et les serveurs (contrôleurs de domaine), les protocoles LDAP et SMB doivent être protégés. Concernant LDAP, il est possible qu’un attaquant force l’utilisation du protocole déprécié NTLM dans le cadre d’un contexte utilisateur.

Troisième point de contrôle : Forcer l'utilisation de NTLMv2

Il faut vérifier que l'usage de NTLMv2 est forcé côté client. Pour cela, la clé de registre 'LmCompatibilityLevel' doit être définie entre 3 et 5. Les contrôleurs de domaine doivent aussi être régulièrement mis à jour.

Concernant SMB, la configuration du système est utilisée pour la sécurisation des échanges. Or celle-ci est par défaut, sur les version de Windows inférieures à Windows 10/Server 2016, vulnérable. Un attaquant en position de « Man in the middle » pourrait désactiver la signature et altérer les paramètres distribués.

Quatrième point de contrôle : Activer l'authentification mutuelle et la
signature des échanges

L'utilisation de Kerberos permet de bénéficier de l'authentification mutuelle, ce qu'est incapable d'assurer NTLM. Pour cela, il faut paramétrer 'RequireMutuelAuthentication' à 1. Il faut également activer la signature des échanges : 'RequireIntegrity=1'.

Les droits d’accès à une GPO sont donnés par le descripteur contenu dans l’attribut nTSecurityDescriptor. Les outils d’édition des GPO définissent des modes d’édition qui seront traduit en droit sur les objets GPO (Read, Edit et Apply).

Cinquième point de contrôle : Vérifier les droit dans l'AD

Il faut vérifier que les droits sur le conteneur CN=Policies, CN=System, dans l'Active Directory, ne soient pas trop permissifs. Par défaut, les droits sont : - Authenticated users : lecture (READ_CONTROL, DS_LIST, DS_READ_PROP, DS_LIST_OBJECT) - System : contrôle total - Domain admins : contrôle total sauf la suppression (d'objet et GPO) - Group Policy Creators Owners : Création d'objets fils

Les filtres WMI permettent de de choisir les GPO à appliquer en fonction de requêtes WQL, qui est un langage proche du SQL mais axé sur les WMI. Ce sont des objets de classe msWMI-Som et l’attribut msWMI-Parm2 contient la ou les requêtes WQL. Le filtre n’est validé que si un résultat au minimum est retourné.

Sixième point de contrôle : Revoir les filtres WMI

Il est important de vérifier régulièrement les requêtes WQL pour éviter les oublis de GPO pouvant compromettre la sécurité.

Septième point de contrôle : Revoir les propriétés des objets GPO

Le niveau fonctionnel d'une GPO, attribut 'gPCFunctionalityVersion', doit être paramétré à 2, sinon la GPO ne doit pas être intégrée. Les répertoires des GPO, attribut 'gPCFileSysPath', doivent être situés dans \\domain\SYSVOL\Policies\

Les paramètres des GPO sont souvent et majoritairement stockés dans le répertoire de la GPO. Il faut donc s’assurer que les droits d’accès à ces paramètres ne soient pas trop permissifs, ce qui pourrait permettre de modifier le comportement des GPO. La synchronisation des droits entre SYSVOL et les objets GPO de l’AD est faite par le moteur d’édition des GPO. Pour chaque répertoire, l’héritage NTFS est supprimé et des droits explicites sont déclarés. En cas de désynchronisation, l’éditeur va régénérer les droits, mais seulement à la racine du répertoire. Ainsi les droits des sous-répertoires ne seront pas restaurés. Aurélien Bordes propose ainsi un script permettant de vérifier et resynchroniser ces droits :

$domain = Get-ADDomain $gpm = New-object-ComObject " GpMgmt . gpm " $const = $gpm.GetConstants() $dom = $gpm.GetDomain($domain.DNSRoot, "", $const.UseAnyDC) $crit = $gpm.CreateSearchCriteria() $gpo = $dom.SearchGPOs($crit) $som = $dom.GetSOM("") $gpo | ForEach-Object { $name = $_.DisplayName $c = $_.IsACLConsistent() Write-Host-NoNewline $name" - " if ($c -eq $FALSE) { Write-Host -ForegroundColor Red "Error" $_.MakeACLConsistent() Write-Host -ForegroundColor Yellow "$name was corrected" } else { Write-Host -ForegroundColor "Ok" } }

Huitième point de contrôle : Vérifier les droits des répertoires de stockage des paramètres

Il faut vérifier les droits sur le répertoire 'SYSVOL\Policies' et également sur 'SYSVOL\scripts' qui contient des scripts qui peuvent s'exécuter à l'ouverture de session. La vérification de la synchronisation des droits doit être faite régulièrement.