2 Cours Active Directory Securité V2 [PDF]

  • 0 0 0
  • Gefällt Ihnen dieses papier und der download? Sie können Ihre eigene PDF-Datei in wenigen Minuten kostenlos online veröffentlichen! Anmelden
Datei wird geladen, bitte warten...
Zitiervorschau

ACTIVE DIRECTORY – Sécurité AD Patrick CEREGHELLI – Consultant Sécurité – Ingénieur Systèmes – Chef de Projets [email protected]

[email protected]

Active Directory

1

Active Directory : sécurité AD ✓ Protocoles d’authentification NTLM et Kerberos ✓ Gestion des accès ✓ Attaques en environnement AD ✓ TP Attaques sur l’AD ✓ Sécuriser l’AD et les environnements Microsoft ✓ Sécuriser les accès à privilèges

Active Directory

2

Protocoles d’authentification ❑ NTLM ❑ Kerberos V5

Active Directory

NTLM et Kerberos ❑ Deux principaux mécanismes d'authentification existent sous Windows : NTLM et Kerberos. ❑ De par leur conception, ces deux mécanismes sont sensiblement différents et ne sont pas exposés aux mêmes problématiques

NTLM

KERBEROS

Protocole authentification basé sur un challenge-réponse

Protocole authentification basé sur l’utilisation de tickets

Echange direct avec la ressource

Utilisation d’un tiers de confiance → le contrôleur de domaine

Pas aussi sécurisé que Kerberos

Plus sécurisé que NTLM

Pas d’authentification mutuelle

Offre une authentification mutuelle

Ne supporte que « l’impersonation »

Supporte « l’impersonation » et la délégation

Impersonation: par exemple exécuter du code avec les droits d'un autre utilisateur. Délégation: par exemple exécuter du code avec les droits d'un autre utilisateur à travers le réseau Active Directory

4

Challenge d’authentification ❑ Microsoft a conçu différents protocoles d'authentification NTLM au travers des années. Ils permettent d'authentifier les ressources à travers le réseau. Il s'agit de protocoles dits de type « défi/réponse » (challenge/response) ✓ LM (alias LAN Manager ou LANMAN) : le protocole LM utilise le "Hashes" LM comme secret de l'algorithme de chiffrement DES afin de calculer la réponse d'un client à un défi (challenge) transmis par un serveur. Déconseillé aujourd’hui: faiblesse du "Hash" LM et de l'utilisation de l'algorithme DES ✓ NTLMv1 (alias NetNTLMv1) : le protocole NetNTLMv1 est similaire au protocole LM sauf que le secret utilisé est à présent le "Hash" NTLM d'un utilisateur. Il est déconseillé d'utiliser ce protocole aujourd'hui, car il est facile de mener des attaques afin de retrouver le mot de passe d'un utilisateur.

✓ NTLMv2 (alias NetNTLMv2) : il s'agit de la version la plus récente et la plus robuste du protocole NTLM. Il corrige certaines faiblesses du protocole NTLMv1 et remplace notamment l'algorithme de chiffrement DES par un HMAC-DES.

❑ L'établissement des protocoles LM, NetNTLMv1 et NetNTLMv2 est réalisé grâce au protocole NTLMSSP (NTLM Security Support Provider).

❑ L'authentification NTLM est supportée par de nombreux protocoles comme SMB, LDAP, HTTP(S), IMAP, SMTP, ou encore MS-SQL. Pour cela, l'authentification NTLM est encapsulée au sein du protocole concerné. ❑ La capture d'un challenge (LM, NTLMv1, NTLMv2) sur un réseau peut permettre d'effectuer des attaques par dictionnaire ou force brute afin de retrouver les mots de passe en clair, mais également d'effectuer du relai NTLM Active Directory

5

Algorithme de stockage des mots de passe sous Windows ❑ LM Hash ("Hash" LM alias Lan Manager Hash): format de stockage des mots de passe utilisé sur les anciens systèmes Windows (antérieurs à Windows NT 4). Il est également présent sur les nouveaux systèmes Windows afin d'assurer la rétrocompatibilité, mais est désactivé par défaut depuis Windows Vista, car son niveau de sécurité est considéré comme très faible. Il est préférable d'utiliser le format NT Hash. ❑ NT Hash (communément appelé NTLM) : format de stockage des mots de passe utilisé sur les systèmes Windows modernes. Bien que vulnérable à certaines attaques, il est beaucoup plus robuste que LM. ❑ Ces « Hashes » peuvent être présents : ✓ dans la base SAM (Security Accounts Manager) pour le stockage des comptes locaux ✓ dans la base Ntds.dit de l'Active Directory pour le stockage des comptes de domaine

✓ dans la mémoire du processus « lsass.exe » (Local Security Authority Server Service) d'une machine sur laquelle une ou plusieurs authentifications ont été réalisées. ❑ Une fois en possession de ces « Hashes », il est possible: ✓ de réaliser des attaques par dictionnaire ou force brute afin de tenter de retrouver les mots de passe en clair ✓ d'effectuer des attaques de type pass-the-hash

Active Directory

6

Algorithme de stockage des mots de passe sous Windows

Active Directory

7

Les échanges NTLM processus d'authentification

Trois étapes nécessaires au processus d'authentification : ❑ NTLMSSP NEGOTIATE : la première étape consiste à négocier le protocole qui sera utilisé. Pour cela, le client transmet au serveur une demande d'authentification en précisant les versions du protocole NTLM acceptées. ❑ NTLMSSP CHALLENGE : le serveur répond au client en précisant les versions NTLM acceptées. Cette réponse contient également un « challenge » à résoudre. ❑ NTLMSSP AUTH : le client résout le challenge et le transmet au serveur (accompagné de diverses informations telles que le login, le domaine associé si applicable, etc.).

Gestion des Identités

8

Fonctionnement NTLM avec un compte local au serveur 1. Authentification interactive de l’utilisateur sur le client Accès d’un utilisateur à un serveur avec un client ✓ Calcul d’un hash du mot de passe par le système 2. Le client envoie le nom d’utilisateur au serveur en clair 3. Le serveur génère un nombre aléatoire sur 16 octets (challenge) et l’envoie au client

5

4. Le client chiffre le challenge avec le hash du mot de passe de l’utilisateur et retourne le résultat au serveur (response) 5. Le serveur utilise le nom d’utilisateur pour extraire le hash du mot de passe de sa base « SAM » locale. Il chiffre le challenge avec le hash du mot de passe, Il compare la réponse fournit par le client et le challenge généré. Si ils sont identiques → authentification réussi

Active Directory

9

Fonctionnement NTLM avec un compte de domaine 1. Authentification interactive de l’utilisateur sur le client Accès d’un utilisateur à un serveur avec un client

✓ Calcul d’un hash du mot de passe par le système

2. Le client envoie le nom d’utilisateur au serveur en clair 3. Le serveur génère un nombre aléatoire sur 16 octets (challenge) et l’envoie au client 4. Le client chiffre le challenge avec le hash du mot de passe de l’utilisateur et retourne le résultat au serveur (response) 5. Le serveur envoie au contrôleur de domaine (DC) ✓ Le nom d’utilisateur ✓ Le challenge ✓ La réponse 6. Le DC utilise le nom d’utilisateur pour extraire le hash du mot de passe de sa base ntds.dit. Il chiffre le challenge avec le hash du mot de passe

7. Le DC compare la réponse fournit par le client et le challenge qu’il a généré. Si ils sont identiques (authentification réussi), il notifie le serveur Active Directory

10

Kerberos ❑ Le protocole Kerberos est le protocole sécurisé

pour authentifier un utilisateur (ou un ordinateur) qui souhaite accéder à une ressource (partage de fichiers) sur un serveur membre d’un domaine Active Directory. ❑ Dans un scénario type, il y a 3 acteurs : ✓ Le client C (l’utilisateur dans notre cas) qui souhaite s’authentifier auprès d’un serveur S. ✓ Le serveur S (le serveur de fichiers, soit le compte ordinateur du serveur S) qui doit s’assurer de l’authenticité de C. ✓ Le tiers de confiance, le KDC (le contrôleur de domaine Active Directory).

Active Directory

❑ Développé initialement au MIT, dans le cadre

du projet Athena au début des années 80 ❑ Version courante : Kerberos V5 ✓ Améliorations par rapport à V4 ✓ Standards IETF : RFCs 1510 et 1964 ✓ V4 et V5 sont non-interopérables ❑ Principes ✓ Basé sur la notion de « Ticket » ✓ Cryptographie à Clefs secrètes ✓ Authentification mutuelle ✓ Tickets limités dans le temps ✓ Mécanismes anti-rejeux

11

Architecture et terminologie Kerberos L’architecture de Kerberos constitue une architecture 3 tiers : ✓ un client ✓ un serveur de ressources ✓ une autorité approuvée Un « royaume » Kerberos : ✓ est une organisation logique dans laquelle s'exécute au moins une AA, ✓ est capable d’authentifier les « principaux » déclarés sur ce serveur. Un « principal » Kerberos ✓ est un client Kerberos, identifiable par un nom unique (un utilisateur, un client, un serveur sont des « principaux » Kerberos) Une autorité approuvée (AA) ✓ stocke les informations de sécurité relatives aux principaux, serveur dit « de confiance » et dont on présuppose qu’il est parfaitement sécurisé ✓ génère et gère les clefs de session, reconnu comme tel par le client et le serveur ✓ Un KDC (Key Distribution Center), nom donné dans Windows à l’autorité approuvée. Active Directory

12

Services Kerberos ❑ Deux types de services sont requis : ✓ un service d’authentification (AS ou Authentication Service) qui délivre des TGT (Ticket Granting Ticket)

✓ un service d’octroi de tickets (TGS ou Ticket Granting Service) ✓ La durée de vie du TGT (10 heures) et de Ticket de service (10 heures)

❑ Dans Kerberos, un KDC génère et stocke les clefs secrètes des principaux qui lui sont rattachés. ✓ Dans WinXX, La clé secrète est directement dérivée du mot de passe de l’utilisateur ✓ Pour des raisons de sécurité, ces clefs secrètes ne servent que lors de la phase initiale d’authentification ✓ Dans toutes les autres phases, on utilise des clefs de session « jetables »

❑ Un ticket est une structure de données constituée d’une partie chiffrée et d’une partie en clair. ✓ Les tickets servent à authentifier les requêtes des principaux (un utilisateur, un client, un serveur) ✓ Deux type de tickets :Ticket Granting Ticket (TGT) et Ticket de Service (TGS)

Active Directory

13

Structure du ticket Kerberos et protocole PAC ❑ Le protocole d’authentification Kerberos standard permet l’authentification mais ne permet pas le contrôle des accès. ❑ En effet, le modèle du contrôle d’accès de Windows est basé sur les SID (Security Identifier), Microsoft a donc développé le protocole PAC qui est une extension du protocole Kerberos. ❑ Le protocole PAC permet de récupérer depuis l’annuaire le SID de l’utilisateur et des groupes auxquels il appartient (dont SID History) et de les stocker dans le champ Authorization Data du TGT. Champ tkt-vno realm sname flags key crealm cname transited authtime starttime endtime renew-till caddr authorization-data

Active Directory

Description Version (5) Royaume d'origine du ticket Nom de l'AA ayant délivré le ticket Drapeaux d'états du ticket Clef de session pour l'échange futur Royaume d'origine du client Nom du client Liste des royaumes ayant pris part dans le schéma d'authentification Horodatage de l'authentification Indique à partir de quand le ticket est valide Indique l'expiration du ticket Pour ticket renouvelables ; indique jusqu'à quand le ticket peut être renouvelé Contient 0 ou une liste d'adresses depuis lesquelles le ticket est utilisable Champ utilisé par les applications pour passer des données spécifiques

Clair

Chiffré

14

Les Algorithmes utilisés par Kerberos Le paramètre Network Security – configure encryption types allowed for Kerberos permet de définir les algorithmes de chiffrement que Kerberos peut utiliser. Algorithme des-cbc-md5 aes128-cts-hmac-sha1

Sel Oui Oui

aes256-cts-hmac-sha1 rc4-hmac-MD5

Oui Non

Gestion des Identités

Complément d’informations Protocole moyennement sécurisé. Protocole de chiffrement fortement sécurisé (nouveauté de Windows 7 / Windows 2008 R2) Protocole historique. Faiblement sécurisé. A désactiver.

15

Authentifiant ➢ Un Authentifiant est un message contenant un nom et un timestamp, le tout chiffré avec la clé de session de l’utilisateur ➢ L’authentifiant intègre l’heure et date du jour. Cela permet à Kerberos d’empêcher une attaque par rejeu en autorisant par défaut que 5 minutes de décalage horaire entre le client C, le serveur S et le contrôleur de domaine (le KDC).

Active Directory

16

Données associés à une session d’authentification

Active Directory

17

Accès à une ressource

Authentification Initiale

Demande d’un ticket de service

Accès au service

Active Directory

La requête initiale contient (en clair) l’identité du requérant et le serveur pour lequel on demande un TGT. Le serveur KDC émet un TGT pour le client La partie chiffrée l’est avec la clef Kc du client => seul le bon client peut déchiffrer cette partie On utilise le TGT obtenu précédemment pour requérir un Ticket de Service Le serveur KDC émet un Ticket de Service pour le client et pour le service considéré

On utilise le Ticket de Service obtenu précédemment pour accéder au service Le serveur de ressources valide alors (ou non) la requête

18

Processus d’accès à un service

Source: https://beta.hackndo.com/kerberos/ Active Directory

19

Génération et transmission d’un ticket Kerberos ➢ Génération du ticket par le KDC et transmission au client, ➢ Traitement du ticket par le client et préparation de la requête au serveur ➢ Traitement de la requête par le serveur et poursuite des échanges.

Génération d’un ticket par le KDC

Active Directory

Traitement par le client

Traitement par le serveur de ressource

20

Contrôle des Acquis Quels sont les mécanismes d’authentification disponible pour Windows Qu’est ce que un « hash » ? Ou sont localisés les « Hashes » ? Comment fonctionne NTLM ? Qu’est ce qu’un KDC Windows ? Qu’est ce qu’un ticket Kerberos ?

Citer deux types de tickets kerberos

Active Directory

21

Gestion des accès ❑ Les SID (Security Identifier) ❑ Les permissions (permissions NTFS, permissions de partages, permissions sur les entrées de registre, permissions sur les objets Active Directory…). ❑ Les privilèges systèmes. ❑ Les processus. ❑ Les jetons d’accès. Active Directory

Le Security Identifier (SID): présentation ❑ Un identificateur de sécurité (SID) est une structure de données au format binaire qui contient un nombre variable de valeurs. Les premières valeurs de la structure contiennent des informations sur la structure du SID. ❑ Un SID est un identifiant de sécurité unique. ✓ Les comptes utilisateurs, groupes et les comptes ordinateurs de l’annuaire AD disposent d’un SID. ✓ Les comptes utilisateurs et les groupes de la base SAM (base de compte locale) disposent aussi d’un SID ❑ Notation Standard au format chaine: S-R-X-Y1-Y2-Yn-1-Yn

Comment Description S R X

Y

Indique que la chaîne est un SID Indique le niveau de révision Indique la valeur de l’autorité d’identificateur Représente une série de valeurs de sous-autorités, où n correspond au nombre de valeurs.

✓ Y1-Y2-Yn-1: identificateur de domaine. ✓ -Yn: est l’identificateur relatif. Il distingue un compte ou un groupe de tous les autres comptes et groupes du domaine. ❑ S-1-5-21-1712426984-1618080182-1209977580-1109 : ✓ S-1-5- : indique que le SID a été généré par Windows Security_NT_Authority. ✓ 21-1712426984-1618080182-1209977580 : représente l’identifiant unique du domaine. ✓ 1109 : c’est l’identifiant unique de la ressource (un compte utilisateur dans notre cas).

Active Directory

23

Le Security Identifier (SID): exemples ❑ SID du groupe intégré « administrateurs »

✓ S-1-5-32-544: Ce SID comporte quatre composants: o Un niveau de révision (1) o Valeur de l’autorité d’identificateur (5, AUTORITE) o Un identificateur de domaine (32, Builtin) o Un identificateur relatif (544, administrateurs) ❑ SID du groupe Domain Admins dans le domaine « contoso » ✓ S-1-5-21-1004336348-1177238915-682003330-512 o Un niveau de révision (1) o Une autorité d’identificateur (5, AUTORITE) o Un identificateur de domaine (21-1004336348-1177238915-682003330, contoso) o Un identificateur relatif (512, administrateurs de domaine) ❑ Références https://docs.microsoft.com/fr-fr/windows/security/identity-protection/access-control/security-identifiers https://support.microsoft.com/fr-fr/help/243330/well-known-security-identifiers-in-windows-operating-systems

Active Directory

24

Le Security Identifier (SID): quelques exemples S-1-5-Domain-500

S-1-5-Domain-501 S-1-5-Domain-502

S-1-5-Domain-512

S-1-5-Domain-513 S-1-5-Domain-515

Active Directory

✓ Chaque ordinateur dispose d’un compte d’administrateur local et chaque domaine dispose d’un compte d’administrateur de domaine ✓ Le compte d’administrateur est le premier compte créé lors de l’installation du système d’exploitation. Administrateur Le compte ne peut pas être supprimé, désactivé ou verrouillé, mais peut être renommé. ✓ Par défaut, le compte d’administrateur est membre du groupe administrateurs et ne peut pas être supprimé du groupe. ✓ Compte d’utilisateur pour les personnes qui n’ont pas de compte individuel Invité ✓ Contrairement à la connexion anonyme, Guest est un compte réel qui peut être utilisé pour la connexion interactive. Le compte invité ne nécessite pas de mot de passe, mais il peut en avoir un. ✓ Un compte d’utilisateur utilisé par le service KDC (Key Distribution Center). Le compte existe krbtgt uniquement sur les contrôleurs de domaine. ✓ Un groupe global avec des membres autorisés à administrer le domaine. Par défaut, le groupe administrateurs de domaine est membre du groupe Administrateurs sur tous les ordinateurs ayant rejoint le domaine, y compris les contrôleurs de domaine. Administrateurs de ✓ Domain Admins est le propriétaire par défaut de tout objet créé dans l’annuaire Active Directory du domaine domaine par n’importe quel membre du groupe. ✓ Si des membres du groupe créent d’autres objets, tels que des fichiers, le propriétaire par défaut est le groupe administrateurs. Utilisateurs du ✓ Groupe global incluant tous les utilisateurs d’un domaine. Lorsque vous créez un objet utilisateur dans domaine Active Directory, l’utilisateur est automatiquement ajouté au groupe. Ordinateurs de ✓ Un groupe global incluant tous les ordinateurs ayant rejoint le domaine, à l’exception des contrôleurs domaine de domaine.

25

Le Security Identifier (SID): accès avec les SID ❑ Dans les environnements Microsoft, le contrôle des accès se fait à l’aide de jetons d’accès. Un jeton d’accès contient entre autres le SID du compte de l’utilisateur et le SID de chaque groupe dont est membre directement ou indirectement l’utilisateur (groupe membre d’un autre groupe). ❑ Le SID est stocké au niveau de l’attribut objectSid qui est géré par le système. Un administrateur ne peut pas modifier la valeur de cet attribut ou affecter le SID d’un compte utilisateur qui a été supprimé à un autre compte utilisateur

Active Directory

26

Le Security Identifier: SID ❑ Quand on donne des permissions à un utilisateur sur un dossier appelé Partage (onglet Security), c’est le SID de ce compte qui dispose des permissions dans le système de fichiers NTFS. ✓ Windows résout le SID en un nom dans l’onglet Security pour le confort des utilisateurs. ✓ Si on supprime le compte utilisateur et que l’on ferme / ouvre de nouveau la session (ou redémarrage), l’ancien compte utilisateur apparaît sous forme d’un SID. ❑ Pour afficher le SID d’un utilisateur, utilisez la console ADSIEDIT.MSC, l’éditeur d’attribut dans des consoles Active Directory Users and Computers ou l’outil PSGETSID (http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx).

❑ Certains SID s’affichent sous la forme suivante : S-1-5-32-544, S-1-5-32-545. Il s’agit du SID des groupes par défaut de la base SAM ou d’entités de sécurités connues (Well-known Security Principal) comme Authenticated Users. ❑ Le SID (attribut objectSid) est différent du GUID (objectGuid) qui est l’identifiant unique d’un objet dans la forêt Active Directory.

Active Directory

27

Les permissions ❑ Les permissions NTFS sont basées sur 13 permissions. ✓ (onglet Security dans les propriétés d’un dossier / fichier) ✓ La permission la plus importante est Take ownership. Elle permet de devenir propriétaire d’un fichier / dossier. Hors le propriétaire d’un fichier / dossier peut modifier les permissions et se donner un accès aux fichiers / dossiers. ❑ Les permissions sur les entrées de registre sont basées sur 11 permissions. La permission la plus importante est Write owner. Elle permet de devenir le propriétaire de la clé ou de l’entrée de registre. Le propriétaire dispose du droit de modifier les permissions.

❑ Les permissions sur les objets Active Directory sont beaucoup plus complexes. ❑ Les permissions NTFS, les permissions sur le registre et les permissions sur l’annuaire Active Directory dispose d’un mécanisme appelé Héritage qui permet de propager les permissions d’un conteneur parent (un dossier, une clé de registre ou une OU par exemple) à des objets enfants (fichiers, entrées de registre, compte utilisateur / groupe). ✓ L’héritage peut être désactivé si besoin.

Active Directory

28

Règles AGLP: groupes et permissions

Serveur de Ressources, d’Application …

Partition Domaine

User1

User2 (SID User)

Global Group

Global Group

Permission Ressource

(ACL sur SID GL)

Local Group (SID GL)

(SID GG)

Permission Ressource

Local Group

(SID GG)

Account  Global Group  Universal Group  Local Group  Permission

Active Directory

29

Les permissions Permissions au niveau de l’Active Directory

Active Directory

Permissions au niveau du DNS

30

Les permissions Permissions au niveau du système Dossier/Fichier

Active Directory

Permissions au niveau du registre

31

Les privilèges ❑ Les privilèges sont des droits donnés à un utilisateur ou un groupe d’utilisateurs ✓ ✓ ✓ ✓

Par exemple le fait de pouvoir contourner les permissions NTFS (Take ownership of files or other objects) accéder à la mémoire utilisée par tous les processus (Debug programs) ouvrir une session localement (Allow Log on locally). Les comptes administrateur et SYSTEM dispose de tous les droits sur une machine Windows car ils disposent d’un accès presque complet au système de fichiers (permissions NTFS) et de tous privilèges.

❑ Les privilèges sont au nombre de 44 sur une machine Windows Server 2012 R2 et se configurent sous forme de paramètres de GPO dans Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | User Rights Assignment ✓ https://docs.microsoft.com/fr-fr/windows-server/identity/adds/plan/security-best-practices/appendix-b--privileged-accountsand-groups-in-active-directory ✓ https://docs.microsoft.com/fr-fr/windows/security/threatprotection/security-policy-settings/user-rights-assignment

Active Directory

32

Les privilèges ❑ Act as part of the operating system (SeTcbPrivilege) : ce privilège permet d’outrepasser certains contrôles lors de l’ouverture de session. Il est réservé aux processus censés ouvrir les sessions des utilisateurs. Winlogon.exe et le service seclogon ont besoin de ce privilège. Il est recommandé de donner ce privilège à personne. Par défaut, il n’est assigné à personne. ❑ Add workstations to domain (SeMachineAccountPrivilege) : permet d’ajouter une machine dans le domaine (jusqu’à 10 stations de travail par défaut). Par défaut ce privilège est donné aux groupes Authenticated Users. Si vous ne souhaitez pas qu’un utilisateur standard puisse joindre une machine au domaine, ce privilège doit être reconfiguré. ❑ Back up files and directories(SeBackupPrivilege) : permet de sauvegarder les données même sans avoir les permissions. Ce privilège est très critique et est donné aux groupes Backup Operators et Server Operators. C’est pour cette raison que les administrateurs de contenus ne doivent pas être membre de ces 2 groupes. ❑ Create a token object (SeCreateTokenPrivilege) : ce privilège permet de créer un jeton d’accès. Il n’est donné à aucun compte utilisateur et cela doit rester ainsi. ❑ Debug programs (SeDebugPrivilege) : ce droit permet à un utilisateur d’ouvrir n’importe quel processus, d’accéder à son espace mémoire et de copier ses ressources. Normalement, aucun service de production ne doit reposer sur ce privilège, il sert en général au développement d’applications et au troubleshooting avancé. Par défaut, les Administrateurs ont ce privilège. ❑ Enable computer and user accounts to be trusted for delegation (SeEnableDelegationPrivilege) : permet de définir qui peut autoriser ou non un utilisateur / ordinateur à faire de la délégation Kerberos. ❑ Generate security audits (SeAuditPrivilege) : détermine qui peut générer des événements dans le journal sécurité. Ce privilège est important car il existe une stratégie de groupe qui permet de bloquer l’ouverture de session quand le journal Security est plein (sauf pour les administrateurs). Un attaquant pourrait générer des milliers d’événements d’audit dans le seul but de bloquer l’ouverture de session pour les utilisateurs standards. ❑ Impersonate a client after authentication (SeImpersonatePrivilege) : permet à un processus de prendre l’identité d’un utilisateur qu’il aurait authentifié. Il faut étudier la pertinence de laisser ce privilège à un Administrateur. Par défaut, les Administrateurs, SERVICE, LOCAL SERVICE et NETWORK SERVICE ont ce privilège.

❑ Manage auditing and security log (SeSecurityPrivilege) : détermine qui peut consulter et vider le journal Security. Par défaut les administrateurs disposent de ce droit. Seules les personnes en charge du suivi des actions sur l’annuaire (audits et contrôles) devraient disposer du droit d’effacer le journal Security sur les contrôleurs de domaine. ❑ Restore files and directories (SeRestorePrivilege) : permet de déterminer les comptes utilisateurs qui peuvent passer outre les permissions lors des opérations de restauration. L’utilisateur dispose d’un équivalent des permissions NTFS Traverse Folder / Execute file et Write. ❑ Take ownership of files or other objects (SeTakeOwnershipPrivilege) : permet de devenir propriétaire d’un fichier, clé de registre (entre autres) et donc de redéfinir les permissions NTFS sur ce fichier ou clé de registre. Active Directory

33

Les processus ❑ Un processus est généré pour chaque exécutable qui démarre sur le système Windows (un service ou une application). ❑ On peut voir la liste des processus dans le « Task Manager » ❑ Il est possible de personnaliser l’affichage des colonnes pour visualiser entre autres l’exécutable qui a généré le processus, sa consommation mémoire, …etc.

Active Directory

34

Les services ❑ Pour visualiser et configurer les services, vous pouvez utiliser la console MMC « services.msc » ou éditer les entrées de registre sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. ❑ Les services sont des exécutables qui démarrent manuellement ou automatiquement dans le contexte d’un compte utilisateur. Les services peuvent s’exécuter dans le contexte d’un compte utilisateur, d’une entité de sécurité (System, Local System, Network Service…), ❑ Le service NETLOGON s’exécute avec le compte System (compte système local) et lance l’exécutable « c:\windows\system32\lsass.exe »

Active Directory

35

Les jeton d’accès ❑ Pendant l’ouverture de session interactive/non-interactive, un jeton de sécurité est crée pour représenter l’utilisateur qui se connecte. Tous les programmes qu’exécute l’utilisateur héritent d’une copie de ce jeton initial. ❑ Un jeton d’accès est généré par le processus Lsass.exe (service Netlogon) une fois que l’utilisateur est authentifié avec le protocole Kerberos ou NTLM. Un jeton d’accès contient : ✓ Le SID et les SID History du compte de l’utilisateur ✓ Le SID et SID History de tous les groupes du domaine dont l’utilisateur est membre directement et indirectement (groupe membre d’un autre groupe…). ✓ Le SID de tous les groupes de la base SAM locale auxquels l’utilisateur appartient (comme Administrators) ✓ La liste des privilèges (comme SeDebugPrivilege) dont dispose l’utilisateur sur la machine locale.

❑ Un jeton d’accès permet d’accéder à une ressource (ex: validation des ACL sur les volumes en NTFS)

Active Directory

36

Les jeton d’accès ❑ Il existe deux types de jeton d’accès : ❑ Jeton primaire (Primary Token) : ce type de jeton est généré lors des ouvertures de session interactive (locale) ou Batch et sont dit de type 2 dans les événements du journal de sécurité. Jeton qui identifie le contexte de sécurité d’un processus. Ils ne sont pas exploitables. ❑ Impersonation jeton (Impersonation Token) : ce type de jeton est généré lors des ouvertures de session réseau et sont dit de type 3 dans les événements du journal de sécurité. Jeton qui est utilisé pour prendre temporairement une autre identité ✓ Les Impersonation Tokens, qui autorisent à utiliser un contexte de sécurité différent de celui du processus courant. Ils implémentent quatre niveaux d'impersonation : ✓ Anonymous : non utilisé ; ✓ Identify : permet d'identifier l'utilisateur, mais pas d'effectuer des actions en son nom ; ✓ Impersonate : permet d'effectuer des actions locales dans le contexte de l'utilisateur ; ✓ Delegate : permet d'effectuer des actions distantes dans le contexte de l'utilisateur.

Active Directory

37

Visualisation des jetons d’accès SID : S-1-5-2 Nom : Réseau Description : Un groupe qui inclut tous les utilisateurs qui se sont connectés par l’intermédiaire d’une connexion réseau. L’appartenance est contrôlée par le système d’exploitation. SID : S-1-5-11 Nom : Utilisateurs authentifiés Description : Un groupe qui inclut tous les utilisateurs dont les identités ont été authentifiées lorsqu’ils se sont connectés. L’appartenance est contrôlée par le système d’exploitation. SID : S-1-5-21domaine-513 Nom : Utilisateurs du domaine Description : Un groupe global qui, par défaut, inclut tous les comptes d’utilisateurs dans un domaine. Lorsque vous créez un compte d’utilisateur dans un domaine, il est ajouté par défaut à ce groupe. https://support.microsoft.com/fr-fr/help/243330/well-known-security-identifiers-in-windows-operating-systems Active Directory

38

Contrôle des Acquis Qu’est ce qu’un SID Windows ?

Qu’est ce qu’une permission Windows ? Qu’est ce qu’un privilège ?

Active Directory

39

Attaques en environement AD ❑ Attaques sur l’Active Directory ❑ Les « Hashes » (empreintes) ❑ Outils pour récupérer les hashes ❑ Mimikatz, outils powershell ❑ Panorama des attaques sur l’authentification ❑ TP Active Directory

Attaques sur Active Directory ? L’annuaire Active Directory, un actif de plus en plus ciblé par les cybercriminels… et à risque Les raisons sont multiples

✓ Microsoft est très répandu dans les entreprises ✓ AD a une position centrale au sein du système d’information ✓ L’annuaire porte le poids de l’historique et suit la vie de l’entreprise o Ces mises à niveau, refontes, migrations sont souvent menées par l’infrastructure et la sécurité n’est pas embarquée (nombreux problèmes de configuration et nombreux risques post migration) o Quelques exemples de problèmes rencontrés : SID history, comptes AD krbgt à risque, récupération d’un grand nombre de comptes inutiles et à privilège,…

✓ La démocratisation de la connaissance des failles kerberos l’outillage pour les exploiter fait qu’un « script kiddy » est désormais capable en peu de temps de réaliser une attaque Golden ticket. ✓ les hackers vont chercher l’accès le plus rapide et efficace au système d’information de l’entreprise ou l’organisation ciblée. L’AD est la porte d’entrée, ils n’ont plus qu’à trouver la clé pour pénétrer au sein du SI o Le Pirate pourra avoir accès aux données, aux emails, aux appareils mobiles et poste du PDG et autres fonctions décisionnaires qui détiennent les informations confidentielles de l’entreprise.. o Du fait de sa structure globale et centrale, l’AD donne accès au réseau de partenaires, clients, prestataires de l’entreprise qui sont interconnectés au SI de l’entreprise

✓ Le maillon faible de l’AD : le manque de formation et d’investissement Active Directory

41

Attaques sur Active Directory ? Plusieurs éléments permettent à un attaquant de compromettre Active Directory. On peut citer par exemple:

✓ Les vulnérabilités non patchées des systèmes Windows ✓ Les mauvaises configurations d’Active Directory ✓ Mauvaises habitudes d’administration (administrateurs du domaine se connecte aux postes clients, serveurs,…) ✓ Architecture non sécurisée (par définition, un annuaire est ouvert, on peut lire des informations)

Cinématique d’une attaque visant Active Directory

Active Directory

✓ Stratégie de mots de passe (mots de passe faible notamment pour les administrateurs, fréquence de changement inexistante, comptes de services avec privilèges ex: compte backup) ✓ La non compréhension des risques liés à Active Directory de la part de certains managers

42

Quelques outils: PsExec, Nessus, Enum4Linux Psexec • Exécution de programmes sur une machine distante • Permet pour exemple de récupérer une invite de commande en mode interactif • Utilisable avec un login/mot de passe ou hash (à vérifier) Affichage d’une invite de commande du poste ayant l’adresse IP 192.168.1.1 en mode interactif psexec.exe 192.168.1.1 -u domaine\utilisateur -p motdepasse -s -i cmd.exe Nessus • Scan de ports / services • Identification de vulnérabilités et classement par criticité • Tests de conformité (système d’exploitation, services, équipements, etc.) • Création de politique spécifique • Interface Web d’administration • Gestion des utilisateurs Enum4linux • Extraire de nombreuses informations de services Windows et Samba (liste des utilisateurs et groupes d’un domaine, politique de sécurité, liste des partages) • Nécessite un compte sur le domaine sauf si les « null sessions » sont activées Exemple liste des membres par groupe enum4linux.pl -u admin -p mot_de_passe -G 192.168.1.1

Active Directory

43

Quelques outils: Nmap Nmap • • •

Scan de ports / services Identification de l’OS (plus ou moins fiable) Nombreux plugins disponibles (vulnérabilités, screenshots, récupération d’informations, smbpsexec, etc)

Scan de tous les ports TCP en SYN avec identification des services (65535) nmap -sS -sV -PN -T4 -p- -O -vvvv -iL fichier_liste_ip_ou_ranges -oA output Scan enum session avec la technique PTH nmap -p445 --script=smb-enum-shares --script-args=smbuser=administrateur,smbhash=9c014340dd2bffb7aad3b435b51404ee 192.168.1.1

Scan enum session avec login et mdp nmap -p445 --script=smb-enum-sessions --script-args=smbuser=digitaluser,smbpass=digitalpass 192.168.1.1 Screenshots des services Web (plugins disponibles sur Internet) nmap -sV -p80,443,8443,8080,9090 --script /usr/share/nmap/scripts/http-screenshot 192.168.1.1

Active Directory

44

Quelques outils: Mimikatz ❑ L’outil Mimikatz a été développé par Benjamin Delpy ❑ Rendu public en 2007. Mimikatz fonctionne sur les versions supérieures à Windows 2000 (les versions 32 et 64 bits sont supportées) : XP, 2003, Vista, Seven, 2008, 2008R2, 8, 2012. ❑ Mimikatz est organisé autour de différents modules (liste non exhaustive) : ✓ standard : intègre les commandes de base de l'outil. ✓ crypto : interagit avec les modules cryptographiques de Windows CryptoAPI [CAPI]et CNG [CNG], ainsi que l’extraction de certificats et de clés.

✓ sekurlsa : extrait les hashes et mots de passe des sessions Windows en cours. ✓ system : intègre des commandes système de base telles que l’obtention de l’utilisateur et de l’ordinateur courant. ✓ nogpo : permet de contourner certaines GPO Windows triviales. ✓ samdump : permet d’extraire les hashes de la base SAM de l’équipement Windows, via la base de registre ou des fichiers plats.

✓ inject : injection de bibliothèques dans des processus Windows. ✓ ts : manipulation des sessions Terminal Server (autorise le dépassement du nombre maximal de connexions simultanées notamment). ✓ divers : contient diverses fonctions majoritairement expérimentales.

❑ Enfin, un pilote mimikatz.sys est également fourni et permet ainsi d’avoir un point d’entrée en mode utilisateur dans le noyau. Source https://connect.ed-diamond.com/MISC/MISC-066/Utilisation-avancee-de-Mimikatz

Active Directory

45

Quelques outils: WCE ❑ Support la technique Pass-The-Hash (PTH) ❑ Vol de mots de passe en mémoire (sans et avec injection) ❑ Vol de tickets Kerberos ❑ Dump des mots de passe Windows en clair ❑ Usurpation via la création d'un token spécifique pour l'exécution de programmes

Exécution d’une invite de commande possédant un token spécifique au compte utilisateur1 du domaine domaine1 wce.exe -s utilisateur1:domaine1:aad3b435b51404eeaad3b435b51404ee:9c014340dd2bffb7aad3b435b51404ee -c cmd.exe Récupération des mots de passe Windows en mémoire wce.exe -w

Dump des tickets Kerberos wce.exe -K

Active Directory

46

Quelques outils: ntdsutil ❑ Outil de ligne de commande qui fournit des fonctionnalités de gestion des services de domaine AD ❑ Utile dans un pentest pour sauvegarder la base contenant les informations des utilisateurs et groupes d’un AD Copie du fichier ntds.dit, SYSTEM et SECURITY dans le répertoire C:\test C:\>ntdsutil ntdsutil: activate instance ntds ntdsutil: ifm ifm: create full c:\test ifm: quit ntdsutil: quit

Active Directory

47

Quelques outils: Responder, Metasploit, John the ripper Responder ❑ Outil « python » permettant d’effectuer du MITM et du spoofing sur de nombreux protocoles ❑ Permet d’émuler des services sur certains protocoles ❑ Les fonctionnalités sont à définir pour certaines dans le fichier de configuration prévu à cet effet Metasploit ❑ Outil pour le développement et l'exécution d'exploits ❑ Création de binaires (.exe, .pdf, .apk, .java, etc.) comportant une charge malveillante visant à prendre le contrôle de l’équipement cible ❑ Nombreux modules disponibles (SMBLogin, psexec, post-exploitation, etc.) ❑ Dispose de fonctionnalité permettant le rebond John the ripper ou oclhashcat ❑ Cassage de mots de passe via dico, brute-force ou encore table arc-en-ciel ❑ Oclhashcat ajoute le cassage via la puissance du GPU

Active Directory

48

Quelques outils: PowerShell Dsinternals: modules de la communauté pour le Hacking Active Directory https://www.powershellgallery.com/packages/DSInternals/2.16.1 https://www.dsinternals.com/en/list-of-cmdlets-in-the-dsinternals-module/

✓ 2 modes de fonctionnement : en ligne et hors ligne. ✓ Permet de lire / modifier le LMHASH et le NTHASH d’un compte, installation simplifiée (PowerShell V5) : InstallModule DSInternals PowerSploit : modules de la communauté https://github.com/PowerShellMafia/PowerSploit

✓ Collection de scripts PowerShell pour la phase de découverte et d’exploitation ✓ Principales fonctionnalités : injection de code, injection de DLL, détection d’antivirus, scan de ports, Keylogger, copie de fichiers verrouillé, intégration Mimikatz

Active Directory

49

Les « Hashes » (empreintes) ❑ Lsass (Local Security Authority Process) est le processus de Microsoft du Serveur local d'authentification de sécurité responsable pour l'authentification de l'identification de l'utilisateur et de l'application de la politique de sécurité. ❑ Winlogon est un processus qui réalise la fonction de gestion de connexion Windows, traitant la connexion de l'utilisateur et sa fermeture de session dans Windows. ❑ Plusieurs bibliothèques intégrées à Windows, les Authentication Packages, implémentent différents mécanismes permettant de s'authentifier sur un système ou une ressource distante (MSV1_0, Wdigest, Kerberos, TsPkg, etc.). ❑ A priori, seul le package MSV1_0, introduit avec Windows NT4, est basé sur un mécanisme défi/réponse impliquant les hashes LM et NTLM.

Source: https://www.microsoftpressstore.com/articles/article.aspx?p=2228450&seqNum=8

❑ Les packages Wdigest, Kerberos et TsPkg conservent ce mot de passe sous une forme chiffrée mais réversible. Gestion des Identités

50

Outils pour récupérer les « hashes » Programme Mimikatz

Meterpreter WCE

Procédure privilege::debug sekurlsa::logonPasswords Full divers::secrets Full (voir note sur les tâches planifiées) Hashdump cachedump wce.exe -w wce.exe -l -v

Données récupérables Hashes LM/NTLM de comptes locaux Hashes LM/NTLM en mémoire Mots de passe en mémoire Certificats et clés en mémoire Hashes LM/NTLM de comptes locaux Hashes MS-CACHE Hashes LM/NTLM en mémoire Mots de passe en mémoire

Source: https://connect.ed-diamond.com/MISC/MISC-068/Faiblesses-des-mecanismes-d-authentification-de-Windows-quelles-solutions

Active Directory

51

Panorama des attaques sur l’authentification ❑ L'attaque Pass-the-Hash [PTH] est relativement connue. Elle vise à extraire le hash NTLM de l'utilisateur et à injecter ce hash à la place de son mot de passe pour réaliser, à sa place, des authentifications réseau. Cette attaque s'appuie sur le fournisseur de sécurité NTLM, déconseillé par rapport à Kerberos qui peut donc être désactivé. Des attaques similaires existent pour Kerberos (quelques exemples) : ✓ Over-Pass-the-Hash: l'attaque vise à passer le hash de l'utilisateur de la même façon que pour NTLM. En effet, les demandes de tickets Kerberos sont signées par un dérivé du mot de passe de l'utilisateur.

✓ Pass-the-ticket: l'attaque vise à importer directement le ticket Kerberos d'un utilisateur (TGT, Ticket¬Granting Ticket) pour demander des tickets d'accès (TGS, Ticket-Granting Service) à sa place. Le TGT est visible avec la commande klist tgt et est valide habituellement 8 heures. Les TGS sont visibles avec le commande klist. ❑ Golden ticket: l'attaque vise à générer directement des tickets Kerberos (TGT) à la demande en connaissant le secret qu'utilise les contrôleurs d'un domaine : un dérivé du mot de passe du compte krbtgt. ❑ Silver ticket: l'attaque permet, en connaissant un dérivé du mot de passe du service visé de générer directement un ticket d'accès au service (TGS), la dernière étape de l'authentification Kerberos auprès d'un tiers.

Active Directory

52

Panorama des attaques sur l’authentification Kerberos est un protocole d'authentification, utilisé au sein d'Active Directory et reposant sur un mécanisme de tickets, émis par deux services de distribution du KDC (Key Distribution Center) Les TGT sont chiffrés avec l'un des secrets (clé RC4, dont la valeur est identique au "Hashes" NTLM, ou clés AES 128/256 bits) du compte « krbtgt » du domaine et permettent l'obtention de tickets de service.

Pass the hash over pass the hash pass the ticket golden ticket silver ticket. Active Directory

53

Attaque « Pass the Hash » ❑ L'attaque Pass the Hash est une attaque connue depuis longtemps et qui reste fonctionnelle sur les versions de Windows récentes. Le concept est simple, lors d'une authentification Windows, les « hashes » LM et NTLM sont utilisés afin d'identifier l'utilisateur. ❑ La récupération des "Hashes LM et NTLM suffit pour s'authentifier sur d'autres équipements ou services. Il n'est donc pas nécessaire de les « casser » afin d'obtenir un accès sur d'autres services. ❑ Si nous disposons des droits SYSTEM ou d'administration sur le poste client ou le serreur, il est possible d’extraire les hashes des comptes locaux qui sont dans la base SAM. ❑ Sur un réseau interne, on constate généralement que l'administrateur local est identique sur l'ensemble des machines du réseau ou sur une grande partie, c'est-à-dire que le même mot de passe est réutilisé pour ce compte et sur différentes machines. ❑ Les phases d'authentification reposent sur des défis/réponses possible à résoudre même si l'on ne dispose que du hash, qui est stocké en mémoire par Windows. En conséquence, tous les hashes LM/NTLM obtenus sur un système Windows peuvent alors être chargés dans la session en cours afin de les « passer » lors des phases d'authentification réseau et ainsi usurper l'identité d'un autre utilisateur dont le hash a été dérobé

Active Directory

54

Attaque par Golden Ticket avec Mimikatz Golden ticket: l'attaque vise à générer directement des tickets Kerberos (TGT) à la demande en connaissant le secret qu'utilise les contrôleurs d'un domaine : un dérivé du mot de passe du compte krbtgt.

✓ Pour pouvoir modifier le TGT, ou en forger un nouveau, il faudrait connaitre la clé qui l’a chiffré, c’est à dire celle du KDC. Cette clé, c’est en fait le hash NTLM du compte krbtgt. Ce compte est un simple compte, sans droits particuliers (au niveau système ou Active Directory) et même désactivé. ✓ Si jamais un attaquant parvient à trouver le hash NTLM de ce compte, il est alors en mesure de forger des TGT avec des PAC arbitraires. ✓ Il suffit de forger un TGT avec comme information que l’utilisateur de ce ticket fait partie du groupe “Administrateurs du Domaine”, et le tour est joué. Source: https://beta.hackndo.com/kerberos-silver-golden-tickets/

Active Directory

55

Attaque par Golden Ticket avec Mimikatz

Active Directory

56

Attaque avec un Silver Ticket Silver ticket : l'attaque permet, en connaissant un dérivé du mot de passe du service visé de générer directement un ticket d'accès au service (TGS), la dernière étape de l'authentification Kerberos auprès d'un tiers.

❑ Si un attaquant parvient à extraire le mot de passe ou le hash NTLM d’un compte de service, il peut alors forger un ticket de service (TGS) en choisissant les informations qu’il veut mettre dedans afin d’accéder à ce service, sans passer par le KDC. ❑ L’attaquant construit ce ticket forgé qui est appelé Silver Ticket. Source: https://beta.hackndo.com/kerberos-silver-golden-tickets/

Active Directory

57

Attaque avec un Silver Ticket

Active Directory

58

TP Objectifs du TP : Evaluer et expérimenter des attaques sur l’environnement Microsoft (postes clients Windows et annuaire Active Directory) Vous disposez de : ➢ 1 serveur Windows 2016 server en tant que contrôleur de domaine « ActiveDirectory » sur le domaine « ADTESTX.NET » ➢ 1 Windows Seven intégré au domaine AdtestX.net : W7-X ➢ 1 Windows 10 intégré au domaine AdtestX.net : W10-X

Active Directory

59

Sécuriser AD et les environnements Microsoft ❑ Problèmes courants sur les environnements Windows ❑ Comment sécuriser les environnements Windows ❑ Sécuriser AD et Azure AD ❑ Sécuriser le poste de travail ❑ Architecture sécurisée Active Directory

Active Directory

Problèmes courants sur les environnements Windows ✓ Systèmes déployés avec les réglages par défaut ✓ Nombre important d’administrateurs ! ✓ Les comptes « administrateur » et les comptes de service ont beaucoup trop de privilèges d’accès ✓ Mauvaise utilisation des comptes administrateurs de domaine (on se connecte sur les postes, les serveurs) ✓ Mots de passe trop courts pour les administrateurs et les comptes de service ✓ Les comptes administrateurs locaux ne sont pas gérés correctement (fréquence de changement des mots de passe ?)

✓ Mots de passe trop courts pour les comptes de service ✓ Les comptes administrateurs locaux ne sont pas gérés correctement ✓ Les contrôleurs de domaine n’ont pas les tout derniers correctifs ✓ Les serveurs n’ont pas les tout derniers correctifs

✓ Trop de programmes/services sont exécutés sur les contrôleurs de domaine (séparation des fonctions ?)

Active Directory

61

Comment se protéger des attaques sur l’authentification Actions de protection ✓ Une des premières actions entreprises par les équipes de défense en cas de suspicion de compromission du domaine est de renouveller deux fois consécutif le mot de passe du compte « krbtgt » ✓ Auditer le compte « krbtgt » régulièrement ✓ Les solutions du marché permettent la détection de l'usage de golden tickets, notamment la solution Microsoft Advanced Threat Analytics (ATA)

✓ Limiter les accès au contrôleurs de domaine ✓ Appliquez le principe de moindre privilège • Limitez l’accès des utilisateurs à ce dont ils sont réellement besoin • Limitez les accès Admin et Administrateur de domaine

• Utilisez avec modération les comptes Admin et seulement pour des modifications approuvées ✓ Installez sur les postes des protections pour empêcher les cyber attaquants de charger des modules comme « mimikatz » ✓ Utiliser un bastion pour sécuriser vos comptes à privilèges ! ✓ Surveillez les activités sur les fichiers et le comportement des utilisateurs

✓ Créez des alertes relatives à un comportement connu indiquant des attaques par Golden ou Silver Ticket

Active Directory

62

Comment sécuriser les environnements Windows Les comptes à privilèges

Stratégies de mots de passe

✓ Ne pas autoriser la connexion avec des comptes privilégiés sur des machines considérées comme « à-risque ».

✓ Ne pas réutiliser les mots de passe.

✓ Restreindre le nombre de comptes à hauts privilèges sur l’AD

✓ Utiliser NTLMv2 uniquement, ou encore mieux, Kerberos (sic).

✓ Ne pas autoriser les comptes locaux à ouvrir des sessions à distance et désactiver les comptes d'administration locaux.

✓ Limiter le nombre de données d'entrées MS-CACHE stockées localement.

✓ Utiliser des postes et des comptes dédiés à l'administration du domaine.

✓ Vérifier les mots de passe par rapport à des listes noires

✓ Créer les tâches planifiées avec des comptes dédiés, disposant de privilèges limités.

✓ Vérifier la réutilisation de mots de passe

✓ Ne pas intégrer les utilisateurs aux groupes d'administration locaux.

✓ Vérifier les autorisations et l’utilisation des comptes administrateurs ✓ Ne pas se connecter avec des comptes sensibles sur un poste « à risque ». ✓ Créer des groupes d’accès à granularité plus fine ✓ Retirer les privilèges non requis ✓ Mettre en œuvre l’authentification multi facteur ✓ Mettre en œuvre une solution PIM/PAM

Active Directory

63

Comment sécuriser les environnements Windows

Gouvernance AD ✓ Mettre en place une gouvernance (Active Directory ?)

✓ Revues sur les droits d’accès, audit ✓ Processus efficaces et opérationnels (ISO 27001 ?) ✓ Impliquer le personnel technique ✓ Impliquer les managers

Active Directory

64

Sécuriser AD et Azure AD

Détection des attaques (ATA / ATP)

Tests d’intrusions Durcissement protocoles authentification (Kerberos, NTLM) PRA/PCA Active Directory Durcissement du système d’exploitation

Sécurisation des postes d’administration Délégation de l’administration

Audit des changements liés aux infrastructures et objets Automatisation du cycle de vie des objets Réduction des privilèges des comptes de services

Gestion des comptes administrateurs locaux Mise en place de politique de mots de passe / MFA

Définition de l’architecture cible - gouvernance des annuaires Active Directory / Azure Active Directory Source Metsys

Active Directory

65

Sécuriser le poste de travail Windows Defender Advanced Threat Protection (ATP) Credential Guard

Device Guard

Windows Hello

Enterprise Data Protection

BitLocker

Délégation d’administration (Tier 0 / Tier 1 / Tier 2)

Un OS supporté (APPV – UE/V)

Secure Boot

LAPS

Un OS à jour

Utilisateur standard (administrateur)

Un antivirus à jour Source Metsys

Active Directory

66

Architecture sécurisée Active Directory VXXX est un groupe français regroupant plusieurs sociétés membres présentes en France et à l’International. Il conçoit des solutions de sécurisation des accès physiques pour les sites d’importance vitale dans les deux domaines « Détection périmétrique d’intrusion » et « Contrôle et sécurisation des accès ». Il est issu du rapprochement en 2014 de SORHEA (détection d’intrusions) et de TIL Technologies (contrôle d’accès). Le groupe VXXX emploie environ 150 personnes réparties sur cinq sites dont deux en France. Chaque société possède son historique et savoir-faire. Le groupe est dans une phase d’acquisition et de rachat de sociétés. Les objectifs de la direction sont de faciliter le travail collaboratif avec des projets structurants tels que la migration vers office 365, définir un cadre d’interconnexion efficace pour les sociétés existantes et futures et renforcer la sécurité globale du SI Sociétés TXXX AXXX ARXXX PXXXX-USA VXXX EXXX TXXX

Active Directory

Commentaires

TXXX.fr AXXX.local

80 personnes + TST

Domaine DNS « arX.fr » SAMBA. 1 machine ARX à son propre tenant O365 « fait tout ou presque » + pfsense. corp.local (A RENOMMER) Géré par IQ (infogérant) Pas d’AD

Utilisateurs 0365

Eurocloture.local TDSI à son propre tenant O365

Source Metsys

Active Directory

67

Architecture sécurisée Active Directory Eléments ayant influencé le choix de l’architecture

Foret Administration Active Directory

TXXX.fr Cloud, Office 365 Administrateurs

Azure Active Directory

AXXX.local Fédération + synchronisation des comptes dans le cloud Corp.local

EXXX.local

XXX Relation approbation AD unidirectionnelle Relation approbation AD bidirectionnelle

Active Directory

AD connnect

Service PKI Service données AD FS commun

Foret Active Directory « VXXX » pour les Services commun à toutes les entités

cloud

➢ Conserver l’indépendance des structures. On évite la solution un seul « tenant » office 365 au niveau de la forêt AD commune « VXXX » pour éviter les problématiques de migration dans le cloud en cas de départ d’une des sociétés. ➢ Possibilité d’accéder à des applications en mode SaaS communes impliquent de fédérer et synchroniser les identités dans le cloud. ➢ Administration centralisée et sécurisée. L’orientation prise favorise la sécurité avec la mise en place d’une forêt AD d’administration. Ce type d’architecture en général réservé aux grandes entreprises, ➢ Partage au travers d’une forêt Active Directory de services communs. Cette structure servira de socle pour la création de services commun à l’ensemble du groupe (service de certificats, service de données partagée, applications communes). Ce domaine « commun » sera lui aussi géré par la forêt d’administration.

68

Architecture sécurisée Active Directory

❑ Pour les comptes administration, une architecture en tiers de confiance empêchera l’élévation de privilège pour un attaquant ayant volé des identifiants. ❑ Chaque compte est « cantonné » à son périmètre. Cela évitera que le « hash » d’un compte administrateur du domaine AD ne se retrouve sur un nombre important d’ordinateurs. Cela prépare le contrôle et la séparation des tâches. Source Metsys

Active Directory

69

Sécuriser les accès à privilèges ❑ Qu’est-ce qu’un compte à privilèges ? ❑ Les comptes à privilèges dans l’entreprise ❑ Pourquoi la sécurisation des accès à privilèges est-elle importante ? ❑ Mettre en place une solution PAM (Privileged Access Management)

Active Directory

Qu’est-ce qu’un compte à privilèges ? ❑ Un accès à privilèges signifie que l’utilisateur dispose de droits d’accès de type administrateur à un système. ✓ Par exemple, un droit d’accès à privilèges sur Microsoft Exchange Server permet à l’utilisateur qui en dispose de créer, modifier et/ou supprimer des comptes e-mail sur ce serveur ✓ Un utilisateur privilégié est une personne avec un accès administratif à des systèmes critiques pour modifier les configurations du système, installer des logiciels, modifier des comptes utilisateurs, accédez à des données sécurisées

❑ Plus généralement, un compte à privilèges, ou accès « root », permet de modifier les configurations d’un système, d’installer et désinstaller des programmes, de créer ou supprimer des comptes d’utilisateurs, ou encore d'accéder à des données sensibles. ✓ C’est la raison pour laquelle les accès à privilèges doivent être contrôlés et supervisés. Tout comme il doit être possible de révoquer ces droits à tout moment.

❑ Il existe des solutions de gestion des accès à privilèges: PAM pour Privileged Access Management (Wallix et Cyberark) et de gestion des identités privilégiées: PIM pour Privileged Identity Management ❑ Les comptes à privilèges, tels que les administrateurs de Active Directory disposent d’un accès direct ou indirect à la plupart ou à la totalité des ressources d’une organisation informatique. Cela rend la compromission de ces comptes un risque important pour l’entreprise. Active Directory

71

Les comptes à privilèges dans l’entreprise A D M I N I S T R AT E U R S DE DOMAINE

A D M I N I S T R AT E U R S BASES DE DONNEES

❑ Principe de privilège minimal ❑ Groupes imbriqués

❑ Ségrégation des rôles ✓ Administrateurs de domaine ✓ Administrateurs de serveurs A D M I N I S T R AT E U R S DE SERVEURS

✓ Administrateurs de poste de travail ✓ Administrateurs de bases de données

A D M I N I S T R AT E U R S D E P O S T E S D E T R AVA I L

IoT IoT

A D M I N I S T R AT E U R S RESEAUX

Domaine AD.ENT1.FR Active Directory

72

Pourquoi la sécurisation des accès à privilèges est-elle importante ? ❑ Les cybercriminels se concentrent sur l’accès à privilèges des systèmes Windows et des annuaires comme Active Directory (AD) pour accéder rapidement à toutes les données ciblées des organisations. ❑ Les approches de sécurité traditionnelles se sont concentrées sur le réseau et les pare-feu comme périmètre de sécurité principal, mais l’efficacité de la sécurité réseau a été considérablement réduite par deux tendances : ✓ Les organisations hébergent des données et des ressources en dehors de la limite réseau traditionnelle sur les ordinateurs portables, les appareils tels que les téléphones mobiles et les tablettes, les services Cloud et les appareils mobiles (BYOD) ✓ Les pirates ont une capacité et des outils permettant des suivre et d’obtenir des accès sur des stations de travail situées dans les limites du réseau par le biais de techniques (hameçonnage, attaques web et e-mail) ❑ Ces facteurs nécessitent la création d’un périmètre de sécurité moderne à partir des contrôles d’identité et d’autorisation, en plus de la stratégie de périmètre de réseau classique.

❑ Un périmètre de sécurité est défini comme un ensemble de contrôles cohérents entre les ressources et leurs menaces. Les comptes à privilèges sont effectivement en mesure de contrôler ce nouveau périmètre de sécurité. il est donc essentiel de protéger l’accès à privilèges

Active Directory

73

Mettre en place une solution PAM (Privileged Access Management)

Une solution de PAM que l’on appelle aussi bastion va permettre : ✓ Des mots de passe sécurisés dans un coffre-fort dédié.

✓ Accordez des privilèges aux utilisateurs uniquement pour les systèmes sur lesquels ils sont autorisés. ✓ Évitez que les utilisateurs privilégiés aient ou aient besoin de mots de passe système locaux ✓ Gérez l'accès de manière centralisée et rapide sur un ensemble disparate de systèmes hétérogènes. ✓ Créez un audit inaltérable pour toute opération privilégiée.

Active Directory

74

Séparer le réseau d’Administration du réseau Bureautique ❑ Un chemin « bleu » dans lequel un compte d’utilisateur standard est utilisé pour l’accès non privilégié aux ressources, telles que la messagerie électronique et la navigation Web, ainsi que le travail quotidien. ❑ Chemin « rouge » dans lequel l’accès privilégié se produit sur un appareil renforcé pour réduire le risque de hameçonnage et d’autres attaques par le Web et par courrier électronique.

Active Directory

75

Privileged Access Management: Architecture Wallix ❑ L'intégration à Active Directory permet de gérer les informations d'identification AD

Accès Externe avec MFA

❑ Les comptes cibles locaux (root,. \ Administrateur) peuvent être utilisés pour se connecter à la cible

WAN

❑ Authentification auprès d'une application distante (RDS) à l'aide de scripts Auto IT

VIP WAB-AM

✓ Client lourd

✓ Client Web.

WAB-AM 1

Accès Interne

Desaster Recovery

VIP WAB

❑ Authentification sur les actifs télécoms (ssh par ex) ❑ L'authentification à l'aide de comptes génériques est possible, la responsabilité est conservée.

TARGETS

Active Directory

WAB-AM 1

WAB Master RDS Applications

Router /Switch

WAB DR

WAB Slave

Windows Servers

WAB DR Linux Servers

76

Privileged Access Management: connexion ❑ 3 types de connexion possibles: ✓ Comptes: utilisez un compte principal différent du compte secondaire ✓ Mappages de comptes: le même utilisateur est utilisé comme compte principal et compte secondaire. ✓ Ouverture de session interactive: l'utilisateur doit spécifier la connexion secondaire (manuel) ❑ Les droits sont définis à l'aide de groupes. ❑ L'autorisation donne accès à un groupe d'utilisateurs pour un groupe d'appareils

Active Directory

77