Quand « Hacker Va » au SSTIC, le cru 2024

03 septembre 2024

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.

Conférences et rumps sélectionnées au SSTIC 2024

Utilisation de DHCP pour contourner routeurs et pare-feux par Olivier Bal-Pétré

 

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 :

  1. Le client broadcaste un paquet DHCPDISCOVER pour demander une adresse IP et une configuration réseau.
  2. Un serveur DHCP répond et fournit une adresse IP via un paquet DHCPOFFER
  3. Le client répond au premier serveur DHCP dont il a reçu une réponse et envoie un paquet DHCPREQUEST identifiant le serveur.
  4. Le serveur retenu stocke l’adresse IP du client et répond par un message DHCPACK (ou DHCPNAK s’il ne peut attribuer l’IP).

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é :

  • D’un pare-feu avec trois interfaces pour 3 réseaux différents (192.168.1.0/24, 10.10.1.0/24 et 10.0.2.0/24)
  • Deux hôtes en 10.0.1.50 et 10.0.2.142
  • Un serveur DHCP en 192.168.1.50 : soit compromis par un attaquant, soit usurpé sur le réseau

 

Les tables de routage du pare-feu sont :

Permettant aux hôtes 1 et 2 de communiquer :

Attaque 1 – Usurpation d’un service

 

  • Le pare-feu va recevoir par l’attaquant via l’option 1 une IP, un masque de sous réseau et la route correspondante (192.168.1.0/24), mais aussi une route malveillante via l’option 121 (10.0.2.128/25) avec un masque de sous-réseau plus grand (/25 vs /24), donc plus précise que la route préalablement enregistrée et comme passerelle le serveur DHCP.

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 :

  • Globalement tous les paquets sont « drop » sauf ceux allant de l’hôte 1 à l’hôte 2 depuis eth1 vers eth2.
  • Le pare-feu est en mode dynamique (« stateful »).
  • Voici le schéma de l’attaque dans le cadre d’un simple 3-way TCP handshake (fonctionne aussi en UDP) :

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 :

  • Contrairement à la 1ère attaque, il n’est pas nécessaire d’avoir une forward chain spécifique, seulement que le pare-feu soit configuré en dynamique (stateful).

 

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

  • Utiliser du policy-base-routing : permet d’avoir différentes tables de routage et de le prioriser.
  • Changer les règles de pare-feu : créer des chain forward et ne pas utiliser par défaut conntrack.
  • Reverse path filtering : n’empêche pas l’attaque mais la rend plus compliquée.

 

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.

 

AD Miner – Analyse Active Directory par Emilien Vannier, Jean-Michel Besnard, Tanguy Boisset.

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 :

  • Le nettoyage de bases de données
  • La création de relations
  • La labélisation de nœuds
  • La recherche de chemins de compromission et de configurations dangereuses.

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 :

  • Le nombre de vulnérabilités par criticité.
  • Des informations synthétiques sur le système d’informations avec un résumé des objets Active Directory.
  • Une visualisation graphique des vulnérabilités par grand type et criticité.
  • Une visualisation par liste également.
  • L’évolution à travers le temps.

 

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 :

  • La vue synthétique
  • La présentation par listes extrêmement pratique, évitant des recherches fastidieuses dans BloodHound
  • La génération de fichiers CSV (exemple : liste des machines avec un OS obsolète), pratique pour les rapports de test d’intrusion.
  • La vision synthétique.

 

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 !

 

 

Rump – Contournement du chiffrement de disque Windows Bitlocker (Sylvain Leroy – Jérôme Maurin – Dionys Colson)

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 :

  • Sur un Windows déjà installé avec BitLocker d’activé, redémarrer le PC avec le Windows Recovery Environment (Shift + Reboot)
  • Le PC va redémarrer sur WinRE.
  • Débrancher/rebrancher à chaud le SSD au moment où la « roue » de chargement apparait.
  • A ce moment-là, les clés BitLocker ont été chargées en mémoire mais le RAMDISK ne détecte plus le disque dur.
  • On ouvre un shell de réparation.
  • Puis, on peut relancer la détection du disque avec la commande :

pnputils.exe /scan-devices

 

  • Sur un système non mis à jour, on obtient alors un accès en lecture/écriture du SSD.

 

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.

Autres présentations

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 :

  • Simulation d’un APT en Red Team : recherche et découverte de 0-day sur MobileIron par Mehdi Elyassa
  • dig .com AXFR +dnssec : Lister l’Internet grâce à DNSSEC par Aris Adamantiadis
  • Getting ahead of the schedule: manipulating the Kubernetes scheduler to perform lateral movement in a cluster par Paul Viossat
  • Action Man VS Octocat: GitHub action exploitation par Hugo Vincent
  • Les patates et Windows, une histoire d’amour et de privesc par Raphaël Huon & Théo B.
  • ntdissector, a swiss-army knife for your NTDS files par Julien Legras & Mehdi Elyassa
  • PowersheLLM : Un Large Language Model à l’épreuve de l’horreur par Frédéric Grelot, Pierre-Adrien Fons & Sylvio Hoarau.
  • Détection de Powershell malveillant par normalisation sémantique par Sylvain Peyrefitte.
  • Belenios: the Certification Campaign par Angèle Bossuat

Le coin des téléchargements pour votre boite à outils

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 !