C’est avec une joie non dissimulée que notre équipe krAKen s’est rendue du 5 au 7 juin 2024 dans la très cyber capitale de Bretagne, Rennes. Durant 3 jours, s’est déroulé le SSTIC 2024, 21ème édition de ce Symposium sur la Sécurité des Technologies de l’Information et des Communications.
Avec 21 ans d’existence, le SSTIC est la plus ancienne conférence francophone de cybersécurité se tenant chaque année dans la capitale bretonne.
Il est à noter que le SSTIC n’est pas sponsorisé, entièrement financé par les inscriptions et géré par une association à but non lucratif.
Le SSTIC est orienté principalement sur des conférences techniques, avec une seule track de conférences permettant de tout voir pour qui serait suffisamment assidu.
Le symposium est intégralement diffusé (mis à part quelques rumps) en direct, gratuitement, sur Internet via une solution open source. Les vidéos sont déjà intégralement en ligne avec les slides, un éventuel « acte » en PDF (article de la présentation) et des liens comme les blogs posts et GtiHub associés. Tout peut être retrouvé à cette adresse : https://www.sstic.org/2024/programme/ pour le cru 2024 (tout comme les conférences des années précédentes).
Pour certains membres de l’équipe, il s’agissait de leur 1ère venue, quand d’autres sont des habitués. Toutefois, aucun membre n’a été déçu de sa venue pour cette édition 2024 du SSTIC, que ce soit pour la qualité des présentations (talks et rumps), mais aussi l’organisation, l’accueil sympathique et le social event.
Ce sont donc plus de 800 inscrits qui se sont réunis pour assister à un marathon de 31 conférences (15 à 45 minutes) et 25 rumps. Les rumps durent 3 minutes et leur orateur peut continuer, ou pas, passé ce délai, à « l’applaudimètre inverse » (l’auditoire doit applaudir pour arrêter la rump).
Traditionnellement, le SSTIC est ouvert et clôturé par deux présentations d’une heure, toutes deux réalisées par Airbus cette année.
La session d’ouverture, passionnante, a été réalisée par le RSSI du groupe Airbus, Pascal Andrei, qui a pu bien différencier les concepts de « Safety » et « Security ». Un panorama des contraintes et menaces auxquelles doit faire face un tel géant de l’aviation, que ce soient les menaces cyber, mais aussi physiques, de sabotage et enjeux géopolitiques (GPS jamming/spoofing) a été présenté. Une plongée éminemment intéressante dans le monde de l’aéronautique où la sécurité est la priorité numéro une de toute personne y travaillant.
La session de clôture a été menée brillamment par Philippe Biondi à propos de la « complexité », concept à la fois indispensable mais tout aussi problématique en cybersécurité. Une réflexion étayée de nombreux exemples pertinents.
Il est à noter aussi l’importance du « réseautage » et de la socialisation lors de ce symposium.
Lors des repas de la pause méridienne, les tables sont volontairement composées de personnes venant de divers horizons pour pouvoir discuter, échanger et créer des liens entre professionnels de la cybersécurité.
Le jeudi soir un social event est également organisé dans le Couvent des Jacobins, où l’on peut à la fois profiter du superbe cadre des lieux, ainsi que d’une nourriture de qualité et surtout faire de belles rencontres entre passionnés.
Notre équipe a également participé le mercredi soir à une soirée avec des talks dans un restaurant rennais, organisé par deux Discord de cybersécurité, en particulier celui des meetups Hack-The-Box France.
Passons maintenant au résumé des conférences qui ont tout particulièrement plu à notre équipe.
Lien : https://www.sstic.org/2024/presentation/utilisation_de_dhcp_pour_contourner_routeurs_et_pare-feux/
NB : l’ensemble des illustrations proviennent des slides de l’auteur, Olivier Bal-Pétré. Ceci est un résumé des points importants du travail de l’auteur.
Le DHCP (Dynamic Host Configuration Protocol) est un protocole réseau de type client-serveur qui permet d’allouer dynamiquement des IPs et des configurations aux clients.
Les pare-feux ne peuvent pas toujours être configurés avec des IPs statiques notamment quand ils sont connectés à des réseaux tiers (WANs…) et ont donc recours au DHCP. Tout comme les machines dans des architectures virtualisées, les postes de travail, les opérateurs télécom, les réseaux résidentiels et publics. Il est, au final, massivement employé.
Bref rappel du fonctionnement du DHCP :
La réponse DHCPOFFER, prend cette forme :
Elle comprend notamment une adresse IP et un masque de sous-réseau (option 1), mais aussi des options qui pourront influencer la table de routage du client, en particulier une liste de routes arbitraires (option 121).
Attaques
Environnement :
Le réseau cible est composé :
Les tables de routage du pare-feu sont :
Permettant aux hôtes 1 et 2 de communiquer :
Attaque 1 – Usurpation d’un service
Quand l’hôte 1 va faire une requête de connexion auprès du pare-feu à l’hôte 2, c’est la route la plus précise (masque de sous-réseau le plus grand) qui sera choisie et donc la passerelle (serveur DHCP) contrôlée par l’attaquant.
Ceci permet de rediriger un flux réseau vers l’attaquant.
Cas particulier des VPN :
La grande majorité des VPN utilisent une interface virtuelle pour chiffrer les paquets. Pour choisir quel paquet est à envoyer en clair et quel paquet est à chiffrer, ce sont les mécanismes de routage qui sont utilisés et on peut ainsi envisager de la fuite de données en clair en interférant sur le routage (principe démontré en août 2023 dans TunnelCrak et en mai 2024 dans Tunnelvision)
Limites/pré-requis :
Il faut que les paquets soient acceptés par le pare-feu et puissent être routés de eth1 à eth0 (sous Linux, par exemple, il faudra la forward chain ad-hoc pour accepter ce type de paquet).
Attaque 2 – Vol de connexion
L’infrastructure est la même que dans l’attaque précédente.
Ces règles de pare-feu sont activées :
L’attaque consiste à « voler » la connexion en train de s’établir entre l’hôte 1 et 2, les paquets allant de l’hôte 2 à l’hôte 1 suivent la route la plus précise qui est du coup la route malveillante qui va diriger les paquets vers la « passerelle » 192.168.1.50 qui n’est autre que le serveur DHCP contrôlé ou usurpé par l’attaquant.
A partir du paquet 2, les paquets sont acceptés car on a la ligne « ct state established accept » dans la configuration (mode stateful), qui fait que le pare-feu accepte tous les paquets qui correspondent à une connexion déjà établie (la liste des connexions établies sous Linux est gérée par conntrack, composant de Netfilter).
On voit dans les lignes de suivi conntrack ci-dessous que les IPs et ports sont stockées mais pas les interfaces.
BSD, qui utilisant PF (Packet Filter), est aussi vulnérable. PacketFilter comme Netfilter accepte les connexions établies sans vérifier l’interface.
De ce fait, les paquets SYN-ACK et ACK, faisant partie de la table de suivi de conntrack, seront acceptés alors que normalement la communication entre les 2 interfaces eth0 et eth2 n’est pas permise. Une connexion TCP est ainsi établie entre l’attaquant et l’hôte 2 permettant à l’attaquant ensuite d’envoyer un flux applicatif à travers cette connexion TCP vers un service exposé sur l’hôte 2 normalement accessible que depuis l’hôte 1.
Une des utilisations potentielles est également de « voler » une connexion vers l’interface d’administration du pare-feu souvent exposée sur une interface spécifique, non accessible depuis l’extérieur.
Limites/pré-requis :
Pare-feux du marché testés par l’auteur :
Ces attaques sont potentiellement utilisables avec d’autres protocoles modifiant les tables de routage comme OSPF.
Remédiation
Commentaire :
Cette approche est extrêmement intéressante et ouvre des perspectives d’attaques potentiellement très efficaces et sûrement peu surveillées. Le potentiel vol d’une connexion vers l’interface d’administration d’un pare-feu depuis une interface normalement non autorisée peut-être tout particulièrement intéressante avec le nombre important de vulnérabilités présentes sur ces interfaces et l’utilisation potentielle d’identifiants par défaut. Les attaques seront à adapter aux différentes architectures rencontrées lors des tests d’intrusions. Des outils permettant une exploitation simplifiée pourraient peut-être être créés.
Cette problématique est également à garder en tête lors d’audits de configuration et d’architecture.
Lien : https://www.sstic.org/2024/presentation/AD_Miner_Active_Directory_Audit_Control/
NB : l’ensemble des illustrations ci-dessous sont tirées des slides de la présentation.
Active Directory / BloodHound
La sécurité Active Directory (AD) est un enjeu majeur de la cybersécurité actuelle, l’AD étant très majoritairement utilisé aussi bien en entreprise que chez les acteurs publics. De ce fait l’AD est la cible privilégiée des acteurs de la menace et notamment par les gangs de ransomware et les APT.
De nombreux outils commerciaux ou gratuits sont disponibles à la fois pour les équipes offensives et défensives.
Parmi ces outils, nous pouvons bien évidemment citer BloodHound de SpecterOps qui permet d’avoir grâce à la théorie des graphes, une approche par chemins d’attaques au sein d’un AD, outil très largement utilisé par la communauté offensive.
Toutefois, dans des AD complexes, il est vite compliqué de s’y retrouver au sein de graphes complexes entre des milliers d’objets AD :
Grâce à des requêtes de type Cypher, il est possible d’interroger la base de données (Neo4j) de BloodHound pour retrouver des chemins d’attaques spécifiques.
Toutefois, il est compliqué d’avoir une vision globale de l’AD en utilisant BloodHound seul, la simple représentation graphique ayant ses limites. Il reste également peu abordable pour des gens moins techniques d’un point de vue offensif. Il est d’ailleurs beaucoup plus utilisé par les équipes offensives que défensives.
Présentation générale d’AD Miner
C’est à ces limitations que répond AD Miner développé par nos collègues de Mazars Tech et mis à disposition en open source.
AD Miner vient directement récupérer les informations stockées dans la base de données Neo4j où les données ont été injectées via un ingestor (sharphound rusthound, bloodhound-python, netexec, AzureHound, etc.).
AD Miner c’est environ 150 scripts python dont les rôles principaux sont :
L’ensemble des informations sont stockées dans un rapport statique en HTML sans dépendance, pouvant être transféré sans problème de ce fait à un client ou un collègue sous le format d’une archive.
Optimisation
L’outil a été optimisé pour utiliser au maximum le CPU pour faire des requêtes multiples pour dépasser la limitation initiale de Neo4J Community Edition d’un core de CPU par requête.
Le gain observé est important, car lors de leurs tests sur un Intel Core i9 13900, sur un AD avec 25 000 objets, le temps est réduit de 2 heures à 45 heures.
Du clustering est également proposé.
Pondération des chemins d’attaque
Un autre avantage d’AD Miner est de ne pas forcément chercher seulement les chemins les plus courts (philosophie de BloodHound) mais aussi d’autres chemins, parfois plus longs, mais plus facilement exploitables. Ils utilisent pour cela la méthodologie de pondération des graphes présentées par Riccardo Ancarini en 2019 (https://riccardoancarani.github.io/2019-11-08-not-all-paths-are-equal/) via le plugin GDS (Graph Data Science).
Certains éléments recevront une pondération spécifique (ex : adminTo = 10, CanRDP = 40, memberOf = 0).
On voit dans cet exemple le chemin en vert qui est plus long, mais plus aisé à exploiter que des chemins plus courts.
Classement des chemins d’attaques
Les chemins d’attaques sont classés par niveau de dangerosité et présentés sous la forme d’un graphique de ce type :
Évolution dans le temps
Il est possible de visualiser graphiquement dans le temps, avec plusieurs extractions de données répétées, l’évolution des différentes vulnérabilités découvertes.
Vue par listes
Un apport très important d’AD Miner par rapport à BloodHound, est une vision qui n’est pas centrée que sur une représentation par graphes, mais aussi par listes. Ceci est vraiment très pratique quand on s’intéresse à plusieurs occurrences d’une même vulnérabilité et plusieurs chemins d’attaque.
Vue synthétique
Dès qu’on arrive sur la page d’accueil d’AD Miner, on a à notre disposition une synthèse globale des résultats, permettant une vue d’ensemble immédiate de la sécurité de l’Active Directory (à l’image de PingCastle). Y sont présentés :
Commentaire :
Avant cette présentation, j’avais eu la chance de tester AD Miner en pentest interne et j’en ai retiré de nombreux avantages à l’utiliser avec principalement :
Je retiens de cette présentation également les graphes d’évolution dans le temps qui peuvent être vraiment un outil précieux pour les équipes défensives et la pondération des chemins, permettant ainsi de valoriser des chemins d’attaques qui ne seraient pas forcément mis en avant par BloodHound.
De plus, il s’agit d’un projet Open Source et gratuit, ce qui est une excellente initiative !
Lien : https://static.sstic.org/rumps2024/SSTIC_2024-06-06_P11_RUMPS_08.mp4
Cette présentation a permis de faire une démonstration de la CVE-2024-20666 (corrigée par Microsoft par la mise à jour de sécurité KB5034441 du 9 Janvier 2024).
Les équipes d’Eternilab, lors de la création d’une solution open source de déploiement de postes Windows sécurisés (Gallus) ont découvert une anomalie avec BitLocker.
Pour leur solution, ils utilisent le « Microsoft Deployement Toolkit » (MDT) et l’injection de drivers de disque dans le « Windows Preinstallation Environment » (WinPE).
Toutefois, si aucun driver n’est initialement injecté, le SSD n’est pas reconnu et alors un shell est automatiquement lancé par MDT.
Si l’on charge des drivers à ce moment-là avec drvload.exe, il s’avère que la clé BitLocker n’est pas demandée car déjà en mémoire et que l’on peut accéder en lecture/écriture au SSD avec un Windows préalablement installé et chiffré avec BitLocker.
Pour généraliser ce phénomène observé et le simplifier, la proposition est de :
pnputils.exe /scan-devices
Commentaire :
Un PC Windows avec BitLocker, où il n’y aurait pas de pin de TPM et pas la mise à jour KB5034441 de sécurité d’installée est donc vulnérable à cette attaque.
Elle pourra être exploitée en cas d’accès physique à un poste et donnera ainsi un accès complet à un disque dur protégé normalement par BitLocker et à tous les secrets qu’il contient.
Cette solution est tout particulièrement intéressante face à un poste durci avec un mot de passe de BIOS et l’impossibilité de démarrer le PC via un périphérique USB et la présence d’un SSD chiffré par BitLocker.
J’ai retenu de nombreuses autres présentations qui m’ont tout particulièrement intéressé. S’il ne fallait en choisir que quelques-unes, ce qui est difficile devant un programme d’une telle qualité, les talks seraient :
Une liste, on l’espère la plus exhaustive possible des outils présentés durant le SSTIC :
Le SSTIC est un événement incontournable de la cybersécurité francophone. Le niveau technique est véritablement très impressionnant et ne peut que rendre humble mais aussi curieux l’auditoire. Le côté networking/social est une part très importante également du symposium et permet la création de liens entre professionnels présents ici, tous autour d’une même passion.
Un évènement annuel à ne pas manquer ! Mais en cas d’absence, la présence du live puis de l’ensemble des talks et documents associés, ainsi que la majorité des rumps, en ligne très rapidement est extrêmement appréciable.
Merci aux organisateurs, aux intervenants et à tout le personnel des social events !