Face à des attaques internes de plus en plus nombreuses, la sécurité des infrastructures réseaux est un enjeu central pour garantir la confidentialité et l’intégrité des données ainsi que la continuité des activités d’une organisation.
Il existe plusieurs moyens d’évaluer la sécurité d’un réseau interne. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion interne (ou pentest interne). Nous y détaillons les principes et objectifs ainsi que des use cases de tests d’intrusion en boite noire et grise d’un réseau interne.
Plan détaillé de l’article :
- En quoi consiste un test d’intrusion interne ?
- Périmètre d’un test d’intrusion interne
- Méthodologie d’un test d’intrusion interne
- Impacts des diverses exploitations de failles sur un réseau interne
- Réaliser un test d’intrusion interne avec Vaadata, entreprise spécialisée en sécurité offensive
En quoi consiste un test d’intrusion interne ?
Un test d’intrusion interne consiste à évaluer la sécurité d’un réseau interne dans la position d’un attaquant parvenant à s’introduire dans celui-ci. Dans ce type d’audit, un pentester va donc simuler le comportement d’un attaquant via l’exploitation de failles de sécurité potentielles afin de mesurer leurs impacts et proposer des correctifs pour renforcer la sécurité du réseau.
Pour ce faire, on considère généralement deux scénarios :
- Attaquant sans compte (sur le domaine) ou test d’intrusion interne en boite noire : Dans ce cas de figure, on suppose que l’attaquant est présent sur le réseau, mais ne dispose d’aucun accès préalable sur les équipements. C’est le scénario qui considère au mieux un attaquant qui parvient à se brancher physiquement sur les prises réseau, se connecter au réseau wifi ou à compromettre un équipement non lié au domaine d’une organisation. Par ailleurs, dans un contexte Active Directory, cela signifie que le pentester ne dispose d’aucun compte utilisateur appartenant au domaine. De fait, son objectif sera d’obtenir un accès valide sur un équipement (serveur, poste utilisateur, compte du domaine, etc.).
- Attaquant avec compte (sur le domaine) ou test d’intrusion interne en boite grise : Ici, on suppose que l’attaquant est présent sur le réseau et dispose d’un accès valide sur un service interne ou un équipement. C’est le scénario qui considère un attaquant qui parvient à compromettre le compte d’un collaborateur (via phishing par exemple), un poste de travail ou un équipement relié au domaine, ou encore à atteindre l’objectif du scénario précédent. En outre, dans un contexte Active Directory, le pentester disposera alors d’un compte valide sur le domaine sans privilège particulier. Ainsi, son objectif sera, à partir de ce compte, d’accéder à des actifs sensibles de l’entreprise, le plus souvent en élevant ses privilèges.
Périmètre d’un test d’intrusion interne
Un test d’intrusion est une opération sur-mesure. De fait, il est possible de tester toutes les composantes de votre réseau interne ou de se focaliser sur les éléments les plus à risque, en fonction du besoin identifié.
Lors d’un test d’intrusion interne, l’objectif des pentesters sera de trouver tous types de vulnérabilités pouvant compromettre la confidentialité et l’intégrité des données stockées et échangées ainsi que la continuité des activités d’une organisation.
Ainsi, les tests couvrent (liste non exhaustive) :
- Les serveurs
- Les équipements réseaux
- Les postes de travail
- Le WI-FI
- L’Active Directory
Pour plus d’informations, vous pouvez consulter notre article qui explore les vulnérabilités et attaques les plus courantes sur l’infrastructure réseau.
Méthodologie d’un test d’intrusion interne
La méthodologie va dépendre du scénario choisi (boite noire ou boite grise) et de la présence d’un Active Directory sur le réseau. Mais dans les deux cas de figure, il s’agira dans un premier temps pour le pentester de réaliser une phase de reconnaissance et de découverte du réseau.
Reconnaissance et découverte du réseau
Lors de cette phase, le pentester va s’intéresser à sa position dans le réseau et aux équipements autour de lui. Il va énumérer le type d’équipement, les services exposés et écouter passivement les communications. De cette manière, il pourra identifier :
- Les serveurs ou les services exposés et leur version.
- Les services exposés n’exigeant pas d’authentification.
- Les communications n’utilisant pas la signature ou le chiffrement.
- La position des serveurs sensibles sur le réseau.
- La présence d’autres réseaux (VLANs).
Suite à cette reconnaissance, le pentester pourra lancer les tests correspondants à chaque scénario.
Tests d’intrusion interne en boite noire (scénario d’une attaque sans compte)
Détection et exploitation de services vulnérables
En l’absence de compte valide, le pentester va concentrer ses efforts sur les attaques n’exigeant aucune authentification. Cela passe notamment par l’analyse des services ou serveurs exposés ainsi que leurs versions. Cette analyse servira à la détection de vulnérabilités publiquement connues qui affectent des composants non mis à jour dans le réseau.
En effet, pour un attaquant, la présence de composants non mis à jour représente une porte d’entrée potentielle. Certaines vulnérabilités publiquement connues ont un fort impact sur les composants ou serveurs ; comme l’exécution de code à distance (RCE).
Pour les détecter, l’attaquant a juste à énumérer les versions des services ou systèmes d’exploitation accessibles, et à comparer les versions observées avec des bases de données de vulnérabilités connues.
Si l’on prend l’exemple du système d’exploitation Windows, une version non mise à jour peut permettre à un attaquant d’obtenir des accès administrateur sur la machine sans authentification préalable. En effet bon nombre de vulnérabilités publiquement connues, comme celle nommée Eternal Blue (MS17-010), sont encore découvertes lors de nos audits. Elles sont la conséquence directe d’un système déprécié ou d’une politique de mise à jour insuffisante.
Cet exemple cité sur les machines Windows vient s’appliquer sur tous les services et les systèmes du réseau. La présence de systèmes non mis à jour est donc une porte d’entrée fortement probable pour l’attaquant sans compte.
Écoute et rejeu de communication sans signature ou chiffrement
Étant donné sa position au sein du réseau, l’attaquant dispose de moyens pour écouter passivement ou activement les communications réseaux.
Cette écoute passe généralement par l’empoisonnement de protocoles tel que ARP, NBT-NS ou LLMNR.
De cette manière, l’attaquant sera en mesure d’observer et d’analyser le trafic réseau même si sa machine n’est pas le destinataire initial des échanges. Le pentester se trouvera alors en position « Man-In-The-Middle ».
Cette écoute peut même devenir active en rejouant certaines requêtes précises. Dans le cadre du scénario d’un attaquant sans compte (en boite noire donc), il s’agit d’une attaque particulièrement efficace ; en particulier dans un environnement Active Directory, avec l’attaque NTLM Relay sur les ports SMB.
Cette attaque est rendue possible grâce à l’absence du mode de signature du protocole SMB.
Les raisons pour lesquelles cette attaque est si efficace sont les suivantes :
- Le protocole SMB est très répandu dans un réseau interne.
- La signature de ce protocole est désactivée par défaut.
- Les conséquences d’une attaque NTLM Relay sont souvent inconnues ou sous-estimées.
De son côté, pour réaliser cette attaque, l’attaquant a simplement besoin d’être présent sur le réseau et de lancer des outils open-source. Ces outils vont placer l’attaquant en position « Man-In-The-Middle » et relayer les authentifications NTLM observées.
La conséquence est l’obtention d’une session SMB valide sur les machines n’imposant pas la signature. Par ailleurs, cette opération est invisible pour l’utilisateur victime.
L’impact de la session obtenue va dépendre des privilèges de l’utilisateur victime. Si l’utilisateur ne dispose pas de droits administrateur alors cette session permettra uniquement d’obtenir un accès aux partages de fichiers exposés par les serveurs ciblés. Mais, si un seul des utilisateurs victimes dispose de droit administrateur, alors l’attaquant sera en mesure d’user de cette session SMB pour écrire ou lire l’ensemble des fichiers, ou encore récupérer l’ensemble des hashs des mots de passe présents sur la machine cible. En fonction de la nature de ces hashs, l’attaquant pourra, soit les casser pour obtenir les valeurs des mots de passe en clair, soit les utiliser directement sur d’autres services.
Dans cette situation, l’attaquant passe directement dans les conditions du second scénario (attaquant avec compte).
Même en l’absence du protocole SMB et d’un contexte Active Directory, le rejeu ou l’écoute de protocoles non signés ou non chiffrés peut également s’effectuer avec d’autres protocoles. C’est le cas par exemple du protocole http qui n’assure pas la confidentialité des échanges.
Dans le cas où le réseau dispose de serveurs web à usage interne, mais que ceux-ci n’utilisent pas le protocole sécurisé HTTPS, alors l’attaquant sera en mesure d’obtenir le contenu des échanges client-serveur par simple écoute réseau. Dès lors que des identifiants sont échangés, via une page de login par exemple, alors l’attaquant aura également connaissance de ses identifiants et pourra s’en servir pour accéder à ce service.
Accès aux services n’exigeant pas d’authentification
Sur un réseau, il arrive que des services soient exposés sans exiger d’authentification. Ce type de situation peut se produire lorsqu’un service FTP ou SMB autorisent les sessions anonymes, par exemple.
Dans ces conditions, l’attaquant pourra interagir avec le service pour voir si des informations sensibles sont exposées (fichiers, clés, données personnelles, etc.). Parfois, il arrive que ces services permettent l’accès en écriture à ces sessions anonymes. Dans ce cas, l’attaquant aura l’occasion de déposer des fichiers malveillants pouvant piéger d’autres utilisateurs utilisant ce service. C’est le cas par exemple avec le dépôt d’un fichier SCF malveillant dans un partage de fichiers SMB.
Tout utilisateur visitant par la suite le partage de fichiers avec l’explorateur Windows tentera une connexion SMB vers un serveur contrôlé par l’attaquant. Cette connexion va divulguer un secret de connexion netNTLMv2 à l’attaquant. Le calcul du mot de passe de l’utilisateur peut être effectué à partir de ce secret.
La réussite du calcul dépendra alors de la complexité du mot de passe de l’utilisateur. Si le mot de passe s’avère insuffisamment complexe, l’attaquant obtiendra la valeur en clair du mot de passe et pourra alors réutiliser le compte ainsi obtenu dans le cadre du 2nd scénario.
Mise à l’épreuve de la politique de mot de passe
Comme évoqué précédemment, le succès de certaines attaques va dépendre de la complexité de mots de passe des utilisateurs ou des services du réseau.
S’il est difficile dans le premier scénario d’obtenir une liste exhaustive de tous les utilisateurs, il reste possible à l’attaquant d’essayer de se connecter aux services exposés avec des identifiants par défaut ou fortement probables. C’est ainsi qu’avec des recherches sur les services ou les modèles de certains équipements, l’attaquant puisse parvenir à s’y connecter.
On pense ici à certaines marques d’imprimantes ou aux interfaces web accessibles avec les combinaisons d’identifiants « admin:admin ». Le pentester va ici s’appuyer sur le résultat de la phase d’énumération des services et tenter, dans la limite de ce qu’autorise la politique du réseau, les couples identifiants / mot de passe les plus probables.
Chez Vaadata, nous poussons cette opération plus loin en récupérant les identifiants et les mots de passe qui ont fait l’objet d’une fuite par une source extérieure. Par exemple, la fuite du réseau social professionnel LinkedIn, qui a eu lieu en 2017. Ce type de fuite a une chance de divulguer des mots de passe toujours en cours d’usage. Une connexion valide intervient alors si l’utilisateur utilise ce même mot de passe aussi bien sur les sites externes que pour accéder au service interne de son entreprise. Dans ce cas, l’attaquant obtiendra un compte valide et rentrera dans les conditions du second scénario.
La mise à l’épreuve de la politique de mot de passe se produira également à chaque fois que l’attaquant interceptera un secret de connexion ou hash de mot de passe. En effet, le mot de passe en clair de l’utilisateur peut être calculé à partir de ces secrets. Que ce soit des hashs récupérés sur des postes compromis ou des hashs capturés lors d’une authentification NTLM, la politique de mot de passe de l’entreprise rendra plus ou moins difficile la récupération des valeurs de mot de passe en clair.
L’application d’une bonne politique de mot de passe est donc essentielle pour assurer une résistance aux attaques décrites ci-dessus.
Test d’intrusion interne en boite grise (attaquant avec compte)
Dès lors qu’un attaquant dispose d’un compte, Il est en mesure d’accéder certains services de moindre privilège. C’est-à-dire des services qui sont accessibles à tout utilisateur authentifié. L’objectif de cette phase est de vérifier que ces services n’exposent pas de secrets permettant d’effectuer une élévation de privilèges.
Dans un contexte Active Directory, l’auditeur s’intéressera à la base LDAP, aux GPOs et aux comptes de services.
Inspection de l’annuaire LDAP
Cet annuaire qui est accessible à tous les utilisateurs authentifiés, contient la liste des utilisateurs et des machines du domaine. En plus de fournir des informations utiles à l’attaquant pour compléter la phase d’énumération, il arrive parfois que des mots de passe soient inscrits dans le champ description des objets LDAP. Une inspection de ces champs description est souvent fructueuse dans la découverte de nouveaux comptes valides.
Une autre utilisation de l’annuaire LDAP par l’attaquant est la découverte des comptes de service. En effet, ceux-ci sont des cibles privilégiées à cause de leur comportement avec le protocole d’authentification Kerberos.
Kerberoasting
Cette attaque cible les comptes de services disposant de droits importants. Par exemple, un compte administrateur auquel on aurait associé les propriétés d’un compte de service.
Dès que l’attaquant dispose d’un compte valide, Il est possible de demander un ticket Kerberos pour accéder aux services du domaine. Ce ticket peut être demandé même si l’utilisateur n’a initialement pas accès au service.
La génération de ces tickets sera effectuée au moyen du secret (mot de passe) des comptes de service associés. Une logique cryptographique permet à l’attaquant de retrouver le mot de passe d’origine du compte de service si la complexité de son mot de passe est insuffisante. Cette opération est ce qu’on appelle l’attaque « Kerberoast ».
La compromission de ce mot de passe permettra l’accès à un nouveau compte et aux services associés. Dans le cas de notre exemple, cela signifie que l’attaquant aurait obtenu le mot de passe du compte de l’administrateur.
Délégation kerberos
Une autre manière d’exploiter les comptes de service, est d’abuser de leurs propriétés de délégation. En effet, le fonctionnement du protocole d’authentification Kerberos autorise une machine ou un compte de service à se faire passer pour un autre utilisateur. Ce principe que l’on nomme délégation existe sous plusieurs formes et a sans cesse été amélioré avec les nouvelles versions de Windows. Les formes successives de la délégation rendent complexe sa configuration.
La conséquence est qu’une mauvaise configuration de ce principe peut être exploitée par un attaquant afin d’obtenir une élévation de privilèges. Pour ce faire, l’attaquant va usurper un compte disposant de plus de privilèges à partir de la compromission d’un compte de service ou d’une machine apte à la délégation.
Ainsi, l’analyse des acteurs de cette délégation est un point d’attention à avoir pour le pentester.
Inspection des « Group Policies »
Il s’agit des stratégies de groupe dans un domaine Active Directory. Elles déterminent l’ensemble des règles d’administration et de configuration sur les machines Windows du parc.
Détection d’utilisation de GPP « Group Policy Preferences »
Une des méthodes d’audit consiste à inspecter le partage de fichier SYSVOL à la recherche de mots de passe. En effet, ce partage de fichier, qui contient des information les stratégies de groupe, est accessible en lecture à tous les utilisateurs. Des mots de passe peuvent être exposés dans ce partage de fichier, soit parce qu’ils sont présents en clair dans des scripts, soit parce qu’ils sont définis dans une « GPP » (Group Policy Preferences). A l’origine, les GPP stockaient des secrets en assurant leur confidentialité.
Seulement, suite au partage de la clé privé de l’algorithme de chiffrement sur la documentation publique de Microsoft en 2012, tous les secrets stockés par GPP peuvent aujourd’hui être déchiffrés.
Analyse des GPO « Group Policy Object »
Une autre méthode consiste à repérer des configurations problématiques permettant une élévation de privilèges dans les stratégies de groupe elle-même. On s’intéressera par exemple aux utilisateurs disposant de droits trop importants et non nécessaires. La détection de ces défauts de configuration est effectuée en consultant l’ensemble des stratégies de groupe.
Un outil de visualisation graphique de ces stratégies, et d’autres propriétés, sous forme de graphe permettra au pentester de détecter les chemins d’attaques et de parvenir à les énumérer même dans les organisations complexes.
Analyse de la configuration de ADCS (Active Directory Certificate Services)
La solution ADCS fournit des services personnalisables pour l’émission et la gestion de certificats numériques utilisés par les logiciels qui emploient des technologies à clé publique.
Dans le cas qui nous intéresse, ces certificats numériques peuvent être utilisés pour l’authentification des comptes d’ordinateurs, d’utilisateurs ou de périphériques sur un réseau.
Bien que les fonctionnalités apportées par la solution viennent grandement faciliter les opérations de gestion des certificats, une mauvaise configuration de cette solution peut impacter la sécurité globale du domaine.
En effet, la configuration de la solution va venir définir, comment un certificat peut être demandé, par quelle entité et pour quoi faire. Certaines configurations problématiques de cette solution permettront à un attaquant de générer des certificats d’authentification à la place d’autres utilisateurs, permettant ainsi d’usurper le compte de l’utilisateur associé au certificat généré. De cette façon, une élévation de privilèges devient possible.
Impacts des diverses exploitations de failles sur un réseau interne
Les différents scénarios et tests présentés ont pour objectif l’évaluation de l’impact d’un attaquant sur le système audité. À la fin du 2nd scénario, l’auditeur est en mesure d’évaluer l’impact maximal d’un attaquant. Cet impact va dépendre du niveau de privilèges obtenu.
Un système qui ne parvient pas à se prémunir des attaques citées ci-dessus à de fortes chances de permettre à un attaquant d’obtenir le plus haut niveau de privilèges.
Dans un contexte d’Active Directory, il s’agit des privilèges d’administrateur du domaine. Entre autres, en obtenant les privilèges d’un administrateur de domaine, un attaquant sera capable de compromettre l’ensemble des machines et comptes du domaine (postes utilisateur, serveurs Windows, partage de fichiers, etc.). Cependant, l’impact de l’attaquant ne s’arrête généralement pas là. La divulgation des secrets présente sur les machines du domaine permet généralement l’attaquant d’atteindre les ressources extérieures au domaine.
On pense ici au mot de passe d’administration des sites web, des environnements cloud et des clés d’accès aux systèmes non Windows. Aussi, un attaquant qui se retrouve avec ce niveau de privilèges sera en mesure de déployer un malware sur l’ensemble du réseau. C’est le cas par exemple des attaques par ransomware.
Réaliser un test d’intrusion interne avec Vaadata, entreprise spécialisée en sécurité offensive
Il est important pour tout gestionnaire d’un réseau interne ou Active Directory d’évaluer le niveau de résistance de leur réseau face aux attaques décrites dans cet article. Cette évaluation peut être réalisée par l’un des audits que nous proposons. Qu’elle soit pratiquée en boîte noire ou en boîte grise, nous vous proposons d’identifier les failles de votre système et de vous accompagner dans leur correction.
Contactez-nous pour échanger sur vos enjeux et besoins.
Auteur : Benoit PHILIPPE – Pentester @Vaadata