Les top 10 vulnérabilités détectées lors de pentests internes

Ces dernières années, la cybersécurité est devenue de plus en plus importante pour les entreprises en raison de diverses menaces, notamment la fuite de données sensibles, la compromission des systèmes d'information (SI) internes et l’impact sur l’image des sociétés. Par conséquent, nos clients cherchent à renforcer leur sécurité. Une façon d'y parvenir est de mener des tests d’intrusion (pentests) internes.

Ce service consiste à simuler une cyberattaque, réalisée par des experts en sécurité, au sein du réseau de l'entreprise pour trouver des vulnérabilités dans le système et élever ses privilèges sur l'infrastructure, de la même manière qu'un véritable adversaire le ferait (mais sans causer de dommages réels). L'objectif est de trouver des faiblesses et de fournir des recommandations pour les corriger avant qu'un véritable attaquant ne puisse les exploiter.

Notre équipe de tests d’intrusion a mené de nombreux audits de sécurité internes pour divers clients au fil des années. Voici le top 10 des vulnérabilités qu’ils ont trouvées, comment ils ont pu les exploiter et des recommandations pour s’en prémunir.

1) Protocoles de nommage hérités

Windows utilise plusieurs protocoles de nommage pour identifier les ordinateurs ou les services à travers le réseau afin de faciliter l'accès aux utilisateurs. Le plus largement utilisé est le DNS (Domain Name System) : chaque ordinateur qui rejoint le domaine ou service est ajouté au serveur DNS, de sorte que lorsqu'un utilisateur demande une ressource spécifique, le service DNS répond avec l'IP correspondante.

Malheureusement, si un utilisateur fait une erreur lors de la requête d'une ressource, le serveur DNS ne peut pas répondre (par exemple : en supposant qu'un service CIFS (Common Internet File System) comme SMB (Server Message Block) existe à "ws-share.domain.tld", alors si l'utilisateur demande "w-share.domain.tld", le serveur DNS ne répondra pas car "w-share" n'est pas dans sa base de données). Dans ce cas, Windows essaiera toujours de répondre en utilisant d’autres protocoles tels que mDNS (Multicast DNS), NBNS (NetBIOS Name Service) ou LLMNR (Link-Local Multicast Name Resolution).

Tous ces protocoles sont des protocoles de broadcast, ce qui signifie qu'une requête est envoyée à tout le monde dans la tentative de trouver l'IP de "w-share.domain.tld". Le problème est que si quelqu'un sur le réseau répond à cette requête avec sa propre adresse IP, le client demandant "ws-share.domain.tld" sera redirigé pour initier un processus d'authentification, envoyant directement à l'attaquant une réponse NTLMv2, qui inclut le hash de son mot de passe. Dans ce scénario, l'attaquant peut rassembler les hashs des mots de passe de plusieurs utilisateurs et essayer de les casser hors ligne.

Pour prévenir cette menace, il est recommandé d'éviter d'utiliser d'anciens protocoles hérités en les désactivant et en n'autorisant que l'utilisation du DNS. Cela peut être fait via un Objet de Stratégie de Groupe (GPO).

2) Relais NTLM

Une autre technique largement utilisée est le relais NTLM (NT LAN Manager). Cette attaque repose sur l'absence de vérification de signature lors de l'authentification NTLM, lorsqu'un utilisateur tente d'accéder à un service (principalement LDAP - Lightweight Directory Access Protocol - ou SMB).

Les authentifications NTLM fonctionnent en 3 étapes :

1. Le client fait une demande d'authentification pour une ressource à un serveur.
2. Le serveur envoie un défi au client.
3. Le client envoie une réponse au serveur (c'est le défi chiffré à l'aide du mot de passe du client).

Les attaquants en position d'Homme du Milieu (MitM) peuvent intercepter la demande d'authentification entre un utilisateur et un service A, transmettant cette demande à un service B. Ensuite, lorsqu'ils reçoivent le défi du service A, ils le transmettent au client et attendent sa réponse, qu'ils enverront au service B. De cette façon, ils peuvent s'authentifier en tant que client auprès du service B, sans aucune connaissance de son mot de passe.

Cette attaque ne fonctionne plus si les services demandent la signature du client. Attention, activer la signature et exiger la signature sont différents : dans le premier cas, la signature est possible et non obligatoire, tandis que dans le second, elle sera demandée à chaque fois.

3) Mauvaise configuration de LAPS

Comme il est très difficile de gérer les ordinateurs dans de grands environnements, Microsoft a ajouté une solution pour automatiser la gestion du compte administrateur local, appelée LAPS (Local Administrator Password Solution). Cette solution ajoute deux nouvelles propriétés aux objets ordinateur : "ms-Mcs-AdmPwd" et "ms-Mcs-AdmPwdExpirationTime" (un mot de passe en clair et sa date d'expiration).

Par défaut, seuls les comptes a hauts privilèges peuvent lire les propriétés "ms-Mcs-AdmPwd", mais comme certains groupes ont souvent plus de privilèges qu'ils ne devraient, il n'est pas rare de trouver des utilisateurs autorisés à lire ces propriétés, même s'ils ne le devraient pas, ce qui leur accorde des droits d'administrateur local.

Une autre mauvaise configuration que notre équipe rencontre est lorsque les utilisateurs ont des droits étendus sur un ordinateur A. Dans ce scénario, si l'utilisateur a le droit d'ajouter un nouvel ordinateur au domaine, il peut ajouter un ordinateur B (sur lequel il a des privilèges d'administrateur) et synchroniser son mot de passe d'administrateur local avec l'ordinateur A (écrasant son propre mot de passe). Ensuite, comme il est déjà administrateur local sur la machine, il n'a plus qu'à lire la propriété "ms-Mcs-AdmPwd" pour obtenir le mot de passe.

L'utilisation de LAPS est un moyen très efficace de protéger les ordinateurs, mais il peut être difficile de restreindre les utilisateurs d'avoir un accès en lecture ou des droits étendus sur le mot de passe.

4) Permissions de partage

Lors des tests d’intrusion internes, une fois qu'un auditeur de sécurité a un compte, il peut vérifier s'il y a des partages ouverts sur le réseau et vérifier s'il y en a un qui sont configurés avec des restrictions faibles, telles qu'un accès "anonyme", un accès "lecture complète" ou un accès "écriture".

L'accès "anonyme" à un partage signifie que n'importe qui, même sans compte, peut accéder à ce partage. Donner un accès en "écriture" à trop de personnes peut également entraîner la modification de données par les utilisateurs (par exemple, des binaires) pour introduire des portes dérobées. D'autre part, donner un accès en "lecture" à tout le monde peut aboutir à une exposition d'informations critiques.

Il est difficile de gérer correctement les permissions en raison du nombre d'utilisateurs et de groupes, ou même du nombre de partages disponibles, mais avoir une politique de partage forte et restreinte réduit la surface d'attaque.

5) Abus de stratégie de groupe

Les stratégies de groupe (GPO – Group Policy Object) sont une fonctionnalité qui aide les administrateurs à gérer et contrôler l'environnement de travail des utilisateurs et des comptes d'ordinateurs au sein d'une organisation. Un attaquant qui dispose d'un compte dans le domaine peut accéder aux partages SYSVOL (volume système) de n'importe quel contrôleur de domaine pour récupérer ces GPO. Si les administrateurs utilisent les GPO pour pousser et exécuter des scripts sur les ordinateurs, ceux-ci peuvent contenir des informations critiques telles que des identifiants.

Un autre risque survient lorsqu'un utilisateur a trop de droits (comme CreateChild, WriteProperty ou GenericWrite) sur une GPO. Dans ce scénario, un utilisateur peut la modifier pour prendre le contrôle des ordinateurs auxquels la GPO s'applique.

Pour résoudre cette vulnérabilité, n'écrivez pas de mots de passe en clair dans les GPO et vérifiez soigneusement qui a des privilèges d'écriture sur vos GPO.

6) Mauvaise configuration du modèle ADCS

ADCS (Active Directory Certificate Service) est un service utilisé pour émettre et gérer des certificats pour les utilisateurs, les ordinateurs ou les services. Il vous permet de configurer des modèles qui seront ensuite utilisés pour générer des certificats. Cependant, comme ces modèles sont très modulables, ils contiennent également des options dangereuses. Par exemple, certains modèles peuvent être utilisés pour authentifier les utilisateurs sur le domaine, donc si le modèle permet à un utilisateur de demander un certificat au nom d'un autre compte (option "ENROLLE_SUPPLIES_SUBJECT"), un attaquant pourrait tout aussi bien demander un certificat et ajouter dans le champ SAN (Subject Alternative Name) le nom d'un administrateur de domaine. L'ADCS émettra donc un certificat valide à l'attaquant, qu'il pourra utiliser pour s'authentifier en tant qu'administrateur de domaine.

Une autre vulnérabilité que notre équipe a trouvé lors des tests d’intrusion est celle des modèles qui peuvent être modifés par n'importe quel "utilisateur authentifié". Dans ce cas, nous sommes en mesure de modifier les options du modèle pour autoriser "l'authentification client", et nous pouvons modifier le sujet du certificat afin de générer un certificat au nom d'un administrateur de domaine, compromettant ainsi l'ensemble du SI.

Les entreprises devraient vérifier les droits de leur modèle ADCS pour restreindre l'accès à sa modification, et elles doivent s'assurer que les utilisateurs ne sont pas en mesure de fournir le sujet du certificat.

7) Utilisation de SPN pour les comptes utilisateurs (kerberoasting)

Une vulnérabilité pas si nouvelle mais toujours présente est l'utilisation de SPN (Service Principal Name) pour des comptes non techniques – l'attaque dite de  “kerberoasting”. Le SPN est un identifiant d'une instance de service (par exemple, MSSQL01_svc/sql.domain.tld:1433 représente le compte MSSQL01_svc sur sql.domain.tld). Si un compte a la propriété "servicePrincipalName", chaque utilisateur peut demander un TGS (Ticket-Granting Service) pour son service. Ce TGS inclut un chiffrement du mot de passe du compte, donc un attaquant peut demander un TGS et essayer de casser le mot de passe hors ligne. Ce n'est pas si dangereux pour les comptes de service, car les mots de passe sont généralement aléatoires et suffisamment longs, donc plus difficiles à craquer, mais cela devient problématique pour les comptes utilisateurs, car la plupart du temps, même avec une bonne politique de mot de passe, il est plus facile de les craquer avec un bon dictionnaire et des ensembles de règles efficaces.

Donc, ne définissez pas la propriété SPN pour les comptes utilisateurs et assurez-vous d'appliquer une bonne politique de mot de passe pour limiter la possibilité que les attaquants cassent les mots de passe.

8) Systèmes et logiciels obsolètes

Une menace à laquelle nous sommes fréquemment confrontés lors des tests d’intrusion internes est la découverte de systèmes ou de logiciels obsolètes, qui sont vulnérables aux Vulnérabilités et Expositions Communes (CVE). Il est difficile d'avoir une bonne politique de mise à jour, en particulier dans les grandes entreprises, mais cela pourrait être une entrée facile pour les attaquants, car de nouvelles vulnérabilités sont découvertes et exploitées chaque jour, et de nombreux PoC (Preuves de Concept) sont souvent disponibles.

Les organisations doivent mettre en place une bonne politique de mise à jour pour limiter la possibilité que les cyberattaquants exploitent ces vulnérabilités.

9) Mauvaise configuration de SCCM

Récemment, lors d'un audit interne, notre équipe a trouvé un moyen de compromettre l'ensemble du domaine d'un client en abusant de la mauvaise configuration du service SCCM (System Center Configuration Manager). Ce produit aide les administrateurs à installer, gérer et configurer les ordinateurs dans un domaine. Malheureusement, le compte utilisé pour effectuer les tâches de configuration était un compte de domaine avec trop de droits (droits d'administrateur de domaine).

Le fait est qu'un administrateur local d'un ordinateur géré par SCCM peut déchiffrer le mot de passe NAA (Network Access Account) de SCCM, car il n'est protégé que par l'API de protection des données Windows. Sachant, que des moyens d’élever ses privilèges sur un poste ou un serveur sont très souvent trouvés par nos experts.

Microsoft recommande de ne pas utiliser de comptes de domaine pour effectuer la configuration des ordinateurs ou, du moins, de restreindre les permissions.

10) Politique de mot de passe faible

Enfin, la vulnérabilité la plus courante à laquelle nous sommes confrontés lors de nos audits est d'avoir des mots de passe utilisateurs faibles. Comme la puissance de calcul augmente, il est plus facile pour les attaquants de casser des mots de passe plus complexes, et encore plus facile lorsque la politique de mot de passe utilisée est faible. Par exemple, cet article montre comment un mot de passe de 8 caractères avec des majuscules, des minuscules et des caractères spéciaux prend 5 jours à être récupéré et coûte 3000$.

L'Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) recommande une longueur de mot de passe entre 9 et 11 caractères pour protéger les données de faible sensibilité, 12 à 14 pour le contenu de sensibilité moyenne, et 15 ou plus pour un niveau de sensibilité élevé à très élevé. Ils recommandent également d'utiliser des majuscules, des minuscules, des chiffres et des caractères spéciaux. Les comptes hautement sensibles devraient également utiliser l'authentification multifactorielle (MFA).