Afin de déterminer le niveau de sécurité de ses filiales, un grand groupe a mandaté SERMA NES pour un audit RedTeam.
Un audit RedTeam se distingue d’un audit classique par la taille variable de son périmètre (non fourni initialement par le client) et par les méthodes de compromissions. Tous les coups, ou presque, sont autorisés : lock-picking, duplication de badge… Le but étant d’identifier les données sensibles qu’un attaquant déterminé pourrait obtenir.
Un audit RedTeam se distingue d’un audit classique par la taille variable de son périmètre (non fourni initialement par le client) et par les méthodes de compromissions. Tous les coups, ou presque, sont autorisés : lock-picking, duplication de badge… Le but étant d’identifier les données sensibles qu’un attaquant déterminé pourrait obtenir.
L’objectif du consultant : obtenir les données de R&D et compromettre l’infrastructure du client
Les données R&D font partie des informations sensibles voire vitales pour certaines entreprises : innovations, veille technique, développement d’outils spécifiques …
Une première attaque a été menée au siège social en France. Quatre solutions pour obtenir un accès sur le réseau de l’entreprise : auditer les IPs visibles depuis Internet ; compromettre une personne interne via une ingénierie sociale ; se rendre à proximité d’un bâtiment lié à l’entreprise et attaquer les WiFi associés ; entrer dans les bâtiments de l’entreprise et connecter un micro-ordinateur sur un port Ethernet.
Le client dispose de 10 IPs externes, n’ayant mené à aucune piste.
Grâce à des adresses mails trouvées sur Internet, le consultant a pu effectuer une attaque d’ingénierie sociale. Les personnes ayant répondu, sensibilisées et formées à ce genre d’attaque, n’ont pas mordu à l’hameçon. La suite des opérations nous emmène sur le terrain, au pied du siège social. La première attaque consiste à analyser les Wifi disponibles. Le bâtiment propose un WiFi protégé par certificat et les attaques par création de faux hotspot WiFi n’ont rien donné. Il reste une option : entrer dans le bâtiment et connecter un micro-ordinateur sur un port Ethernet. Malgré une sécurité bien présente, le consultant parvient à entrer dans les locaux par la porte de derrière, utilisée par le personnel. Après un rapide tour des environs, le constat est le suivant : les ports Ethernets sont protégés par certificat (802.1x) ; les périphériques faibles (imprimantes, téléphones…) sont récents et correctement configurés ; les ordinateurs visibles requièrent une carte à puce pour s’authentifier.
Le réseau du siège social est imprenable directement, mais qu’en est-il des filiales ?
Le consultant rejoue le même scénario auprès d’une des filiales à l’étranger. Les IPs internet sont peu nombreuses et aucune ne présente de vulnérabilité exploitable. Il n’a pas été possible d’obtenir des adresses email pour effectuer une ingénierie sociale.
Sur le terrain, deux wifi étaient proposés : un WiFi public sans authentification, ainsi qu’un WiFi privé protégé par un certificat. Après plusieurs jours d’écoute sur le WiFi public, aucune donnée ne nous est parvenue. La création de faux hotspot WiFi n’a pas donné plus de résultat.
Il reste l’intrusion physique. Dans la salle d’attente de l’accueil, un téléphone en VoIP était accessible en libre accès. Après avoir vérifié la connectivité, le consultant a installé discrètement un micro-ordinateur avec une carte SIM téléphonique.
Le premier scan montre que le réseau VoIP n’est pas départagé du réseau des usagers internes. Les scans réseaux remontent de nombreux serveurs et machines d’utilisateurs classiques.
Les postes internes sont correctement configurés, les trames LLMNR et autre quick-win ne sont pas visibles sur le réseau.
Parmi les serveurs trouvés, l’un d’eux hébergeait un serveur MSSQL sur un Windows 2008 R2 avec les identifiants par défaut. Le module xp_cmdshell, disponible après connexion, a permis au consultant d’exécuter un des outils de la librairie SERMA NES pour récupérer les identifiants de connexion de toutes les personnes s’étant connectées au serveur.
Un administrateur de domaine (appelé ici ) s’était connecté sur ce serveur après le dernier redémarrage, permettant ainsi d’obtenir son mot de passe en clair. Après un scan plus approfondi, il s’est avéré que le réseau du pays en question était connecté en MPLS (Multiprotocol Label Switching) au réseau France, le reliant ainsi directement au siège social en France.
Grâce au compte , il a été possible de se connecter à tous les PC et d’obtenir des informations sur les usages du réseau : partages de fichiers (NAS), serveurs mails, applications web internes, clients lourds internes…Via ces informations, il a été possible de récupérer rapidement les informations de R&D : documents Excel, Word…
Ainsi, à partir du réseau d’une filiale du client située à l’étranger, il a été possible de se connecter aux machines du siège social et de récupérer les informations de R&D en compromettant l’intégralité du réseau.