Pentest story #1 : “Bonjour, je suis ADsteve-admin”

En tant que pentesteur, nous sommes confrontés à divers environnements, que certains comparent à des flocons de neige. De loin, ils semblent tous similaires, mais intrinsèquement, à leur manière, ils sont tous uniques. Parfois, nous tombons sur seulement l’un de ces flocons, si particulier qu’il nous invite à l’examiner à la loupe, l’étudier, voir ce qu’il se passe si on y touche. Voici l’histoire d’un de ces flocons.  

Lors d’audits internes, nous exécutons parfois des services, comme des serveurs de fichiers pour déplacer des éléments sur le réseau. Après avoir fait tourner un de ces services, nous avons constaté que quelqu’un cherchait à s’y authentifier. Il s’agissait d’un compte administrateur du domaine, qui s’authentifiait de manière répétée. Nous avons ainsi pu récupérer le hash de son mot de passe, le casser ou, éventuellement, relayer ces identifiants et compromettre d’autres systèmes sur le réseau. Au lieu de nous en tenir à cela, nous avons souhaité savoir « qui » se connectait et pourquoi. 

Après avoir inspecté le trafic réseau généré par ce mystérieux admin, il est apparu qu’il tentait de collecter des informations sur les utilisateurs connectés. Il s’est avéré que ce réseau disposait d’un système permettant au pare-feu d’identifier les utilisateurs connectés à un poste. Ces informations servaient ensuite à appliquer au niveau du pare-feu des règles spécifiques à l’IP du poste de travail. Ce comportement nous a suffisamment interpellés pour que nous nous demandions « Et… si ? ». 

Comme le réseau fait confiance aux données issues d’un poste pour appliquer les règles du pare-feu, que se passe-t-il si nous disons au système que nous sommes un utilisateur doté de droits d’administration ? Pouvons-nous faire appliquer d’autres règles, qui nous permettraient d’accéder à d’autres systèmes au sein d’autres réseaux ? Est-ce que nous pourrions alors compromettre plus de systèmes métier critiques auxquels nous n’aurions pas accès pour l’instant ? Des outils publics nous permettent-ils d’y parvenir ? Spoiler : les réponses sont oui, oui, oui et « en quelque sorte ». 

Pour réaliser ces tests, il nous fallait des outils qui reproduiraient la fonctionnalité en question. Après avoir étudié le protocole et d’autres outils, nous avons conclu qu’il n’en existait pas qui nous permettraient d’atteindre ce but, mais il existait des briques utilisables. Nous avons donc enrichi un outil existant avec ces briques et avons pu répondre à ces requêtes avec des informations arbitraires que nous contrôlions totalement. Nous avons donc pu nous faire passer pour n’importe quel utilisateur comme s’il était connecté sur notre système et, potentiellement, obtenir ses règles de pare-feu. 

Précédemment, nous avions analysé des informations issues du réseau interne. Nous opérions depuis un segment réseau que, pour l’instant, nous nommerons VLAN1. Nous avons trouvé un système dans un autre réseau virtuel local segmenté, que nous appellerons VLAN2. À ce stade, nous ne pouvions pas accéder à ce système dans VLAN2, supposément, du fait des règles de pare-feu. Nous avons aussi remarqué qu’un utilisateur, disons « steve–admin », avait accès à ce système. Cet utilisateur devenait alors une cible idéale pour se faire passer pour un utilisateur connecté. 

Nous avons lancé notre outil, renseigné « steve-admin » et attendu que le système interroge notre liste d’utilisateurs connectés – en nous demandant toujours si cela allait fonctionner. Après que le système nous ait interrogés et vu que « steve–admin » était l’utilisateur connecté, il nous a octroyé ses règles de pare–feu. Ce procédé nous a donné accès au système dans VLAN2 d’un point de vue réseau. Avec des identifiants collectés précédemment, nous nous sommes connectés et avons compromis le système cible. 

• Lire et appliquer les bonnes pratiques émises par l’éditeur : la mise en œuvre de la fonctionnalité que nous avons exploitée est indiquée comme non sûre par l’éditeur, mais elle est toujours supportée et peut être configurée. 
• Appliquer le principe de moindre privilège à vos environnements d’Active Directory : les comptes de services ne doivent pas se voir remettre les clefs du royaume.  
• Assurez-vous qu’ils ne sont autorisés à accéder qu’aux ressources dont ils ont réellement besoin dans l’intérêt de leurs fonctions. L’éditeur a décrit ce cas dans un guide de bonnes pratiques. 

• Savoir ce que l’on implémente : le fait qu’un éditeur de logiciels supporte certaines fonctionnalités ne veut pas systématiquement dire qu’elles sont sûres.  
• Il n’est jamais dommageable de vérifier ce qu’elles font, de se demander « Et si ? ».
   

Merci à Justin Perdok, Security Specialist Operations chez Orange Cyberdefense Netherlands, pour cet article.  

Cette story fait partie de l’édition 2021 du Security Navigator. Pour le télécharger, cliquez ici.