Active Directory en milieu universitaire : une approche par la sécurité Emmanuel Mesnard / Xavier Girardin.

Présentation au sujet: "Active Directory en milieu universitaire : une approche par la sécurité Emmanuel Mesnard / Xavier Girardin."— Transcription de la présentation:

1 Active Directory en milieu universitaire : une approche par la sécurité
Emmanuel Mesnard / Xavier Girardin

2 Sommaire Introduction Volet technique
Volet organisationnel et fonctionnel Volet audit Perspectives Conclusion

3 Introduction Points communs entre ces événements ?
Juin 2017 Janvier 2019 Mars 2019 Mai 2019 Merck (malware NotPetya) Avril 2015 TV5 monde Altran (ransomware) Norsk Hydro (ransomware LockerGoga) Ville de Baltimore (ransomware RobinHood) Active Directory : la nouvelle cible des attaquants !!! Deux possibilités de compromission d’un AD : Systèmes Windows non mis à jour avec des vulnérabilités non patchées, Des mauvaises configurations d’Active Directory Une approche de la sécurité par « couches » (Liaison / Application / Orga / Audit)

4 Volet technique - Structure physique
Une architecture répartie sur KVM pour le PCA Utilisation des fonctionnalités de VMWare pour le PRA Sécurisation des serveurs à travers les VLAN, les VRF (sécure) et les pare- feu Réseau interne Sécurité : maintien de la disponibilité du service 4

5 Volet technique – Flux réseau
Identification des groupes de machines devant communiquer avec l’AD Avoir le contrôle des flux réseaux entre les différents groupes de machines

6 Volet technique – rôle FSMO
Un Active Directory utilise un mode de réplication Multi-Maître, 5 modifications ne peuvent être exécutées qu’en mode Mono-Maître Les 5 rôles FSMO sont les suivants : Serveur 1 Serveur 2 Serveur 3 Zone sécurisée Limite les risques d’usurpation des rôles et les modifications par exemple le schéma LDAP Emulateur PDC : - Modification des stratégies de groupe du domaine (éviter les conflits et les écrasements) - Synchroniser les horloges sur tous les contrôleurs de domaine (heure et date) - Gérer le verrouillage des comptes - Changer les mots de passe - Assure la compatibilité avec les contrôleurs de domaine Windows NT Source

7 Volet technique - PKI Une PKI a 2 niveaux
CARoot (Niveau 1) est éteinte et n’est pas intégrée au domaine AD, Une CA secondaire est intégrée au domaine AD, Aucune communication directe entre la CARoot et la CA secondaire, Il est nécessaire de publier les chemins CDP et AIA pour avoir une PKI fonctionnelle CDP : liste de révocation AIA : Chemin des certificats d’autorités de certification

8 Volet technique - PKI Pourquoi ?
Permet de limiter les risques de compromission de la PKI, La CARoot étant éteinte ne sera pas compromise, Si la SubCA est compromise, alors nous révoquons son certificat sur la CARoot et de reconstruire une nouvelle SubCA pour avoir une nouvelle PKI fonctionnelle, Permets de renforcer la sécurité de notre architecture réseau, l’exécution de scripts ou encore la gestion des comptes par le biais d’un connecteur,

9 Volet technique - PKI Mise en place des liens IPSec grâce une règle définie par GPO Visibilité des liens établis sur les contrôleurs de domaine 

10 Volet technique - PKI Mise en place d'un connecteur permettant un miroir des comptes actifs entre l'OpenLDAP et l’AD, Extension de schéma LDAP de l’AD, Besoin d’étendre le schéma au niveau de l’AD pour la mise en place du connecteur (sécurisation des attributs sensible searchflag=128 ou 904), Après l’extension du schéma, penser à retirer les admins du groupe « Schema Admin » pour éviter des modifications du schéma AD

11 Volet technique - PKI Seuls les scripts signés par un éditeur approuvé peuvent être exécutés automatiquement, La liste des éditeurs approuvés est gérée par GPO

12 Volet technique – serveur RDS
NLA GPO Blocage des connexions RDP sur les différents FW

13 Volet technique – LAPS Le but du LAPS (local Administrator Password Solution) est d’avoir un mot passe administrateur unique et complexe pour tous les postes du domaine. Cela permet d’avoir une gestion centralisée des mots de passe

14 Volet technique - LAPS Fonctionnement de LAPS Côté Serveur :
Installation des modules administrations de LAPS (commandlet powerShell, extension de schéma LDAP, ADMX) Définition des paramètres de renouvellement des mots de passe et de leur dureté grâce à une GPO Autoriser les objets ordinateurs à modifier les attributs LAPS (ms-Mcs-AdmPwd et ms-Mcs-AdmExpiration) Côté client : Installation d’un agent Application des paramètres lors de l’application de la GPO Architecture de la solution LAPS : Source : © Microsoft

15 Fonctionnalités intéressantes
FGPP : Fine-Grained Password Policy, GMSA : Group Managed Service Accounts, Activer le mode "Account is sensitive and cannot be delegated", Restricted Admin Mode pour les admins, Les credential ne restent que sur l’hôte

16 Volet organisationnel et fonctionnel
La sécurité n'est pas que "Technique", Lever les résistances au changement des admins dans les habitudes d'administration ("A grand pouvoir, grandes responsabilités"), Convention de nommage : Le nommage permet d'automatiser des tâches Nomenclature Utilisateur Ordinateur OU Groupe GPO

17 Nomenclature Nomenclature GPO Nomenclature OU Nomenclature Ordis

18 Segmentation des rôles
Source : © Microsoft

19 Restrictions de connexion
Source : © Microsoft

20 Comment faire ? 1 VM dédiée ou 1 poste physique par admins,
vers internet, vers serveur RDS et/ou vers DCs, Centralisation des outils pour les admins de ressources de niveau 1 (LAPS Ui / RSAT / WinRM / PowerShell), Formation et sensibilisation des admins (AD, PowerShell, sensibilisation des risques PTH), 5 admins du DC, ~ 40 admins de niveau 1 (OU / GPO / computer / scripts).

21 Volet audit JRES2017 : Présentation de BTA et AD Control Path
JRES2019 : PingCastle & BloodHound PingCastle : Développé à la base pour Engie, Cartographie une archi AD et mesure le niveau de sécurité, Un niveau de risque est déterminé pour chaque DC / Forest sur la base de 4 catégories (Objets abandonnés / Comptes à privilèges / Relation d'approbation / Anomalies de sécurité), BloodHound : Développé par des experts sécurité AD de chez SpecterOps,

22 PingCastle Analyse d'information sur la sécurité dans un AD,
Génération de rapports détaillés, Evalue le niveau de sécurité d'après un modèle et des règles, Fonctionnement : Source : © PingCastle

23 PingCastle

24 PingCastle Audit : avril 2019

25 PingCastle Audit : mai 2019

26 PingCastle Audit : juillet 2019

27 PingCastle Audit : octobre 2019

28 PingCastle Résultat par domaine et par règle

29 PingCastle Descriptif d'une règle et des moyens de remédiation

30 PingCastle Avantages : Inconvénients :
Simple EXE à lancer sur un poste/serveur connecté à l'AD, Peu intrusif (seulement du requêtage LDAP/ADWS), Rapport HTML explicite, Possibilité d'envoyer le rapport par (chiffré ou non). Inconvénients : Pas de mise à jour automatique (déploiement en manuel), Lancement manuel sinon passer par une tâche planifiée pour l'automatisation du processus, Pas de tableau de bord ni d'historique dans la version open source.

31 BloodHound Outil inspiré d’AD Control Path (ANSSI),
Outil de reconnaissance (Red/Blue Team), Notion de graphe relationnel avec Neo4j, Communauté importante et active sur l'outil, Complément idéal à PingCastle sur des problèmes de configuration pour l'administrateur.

32 BloodHound L'outil permet : Audit des droits d'administrateur local,
Audit de comportement d'utilisateur privilégié, Audit des autorisations d'objet AD, Audit de contrôle de stratégie de groupe, Recherche des problèmes de configuration Kerberos.

33 BloodHound La collecte d'information via le binaire SharpHound :
MÉTHODE DE COLLECTE Group LoggedOn LocalAdmin Trusts RDP ACL DCOM Container GPOLocalGroup ObjectProps Session DcOnly ComputerOnly OU

34 BloodHound Les configurations abusives disponibles : Mouvement latéral
ACL Divers AdminTo GenericAll Kerberoast ExecuteDCOM AllExtentedRights HasSession CanRDP GenericWrite GpLink SQLAdmin WriteOwner AS-Rep Roast AllowedToAct WriteDacl AllowedToDelegate Owns ForceChangePassword

35 BloodHound (requête neo4j)
Exemple 1 : Recherche des OS vulnérables : Exemple 2 : Afficher tous les Admins du domaine Exemple 3 : Voir toutes les GPO Exemple 4 : Trouver les ordinateurs avec une description MATCH (H:Computer) WHERE H.operatingsystem =~ '(?i).*(7|2000|2003|2008|xp|vista|me).*' RETURN H MATCH (n:Group) WHERE n.objectsid =~ "(?i)S-1-5-.*-512" WITH n MATCH p=(n)<-[r:MemberOf*1..]-(m) RETURN p Match (n:GPO) return n MATCH (c:Computer) WHERE c.description IS NOT NULL RETURN c.name,c.description

36 BloodHound Menu Recherche + Infos Zoom Requête au format Neo4j

37 BloodHound Fig.4 Fig.1 Fig.3 Fig.2

38 BloodHound Pb de configuration sur un utilisateur (builtins)
But de l’attaquant : Domain Admin

39 BloodHound Pb de configuration sur un utilisateur (builtins) & RDP possible sur un DC Un administrateur du domaine à une session sur un DC

40 BloodHound Mode graphe permet de se rendre compte rapidement des problèmes (user / Computer / OU / GPO / …), Outil très intéressant pour le côté « Défense ». Blog de Pixis (expert en sécurité) : La modélisation en mode graphe permet de comprendre les relations et intrications complexes des objets et relations dans le système d’information, pour en ressortir des chemins d’attaque ou des comportements anormaux.

41 Perspectives Mettre en place une forêt d'administration dédiée (ESAE),
Notion de "Temporary Group Membership", Mettre une délégation des droits sur PowerShell au niveau des admins via JEA (Just Enough Administration), Focus particulier sur les postes/VM d'administration via Credential Guard et PAW (Privileged Access Workstation), Désactiver le mode "Debug Program" : SeDebug, Centraliser et corréler les événements EVTX.

42 Conclusion Durcir l'archi technique (LAPS / PKI / IPSec / RDP),
Segmenter le niveau fonctionnel et niveau physique, Limiter le nombre d’admins du Domaine (<10 idéalement), Contraintes : temporelle / budgétaire / humaine, Outils d'audit permettent d'avoir une vue "réelle" de la sécurité et des écueils éventuels, Besoin de passer par un audit externe pour ne pas avoir un biais de confirmation avec l'audit interne,

43 Conclusion Mettre en place un plan d’amélioration continue de l’infra AD, Tester les outils des attaquants pour comprendre les faiblesses de notre AD (BloodHound, Mimikatz, Metasploit,…), Suivre une formation avancée sur la sécurité Active Directory (ANSSI R2 : Former les administrateurs à l’état de l’art en matière de SSI), Nous avons monté en maturité en terme de sécurité, mais nous sommes conscients qu'il reste encore des étapes à franchir, Complexifier et allonger le travail des attaquants sur un AD pour "essayer" de détecter une attaque.

44 Des questions ?