Cet article constitue la deuxième partie de POV : un pentester au SSTIC 2023, et fait suite au retour d’expérience des présentations du SSTIC liées au métier de pentester.

Top 3 – Coups de cœur

Parmi la programmation de qualité de cette édition, trois présentations ont particulièrement attiré mon attention, aussi bien par les sujets présentés que la manière de présenter. C’est un avis subjectif, et je vous invite à regarder d’ores et déjà le replay de ces présentations.

Deep Attack Surfaces, Shallow Bugs

Présentée par Valentina Palmiotti @Chompie1337, cette conférence fait écho à un tweet publié en décembre dernier à propos d’une vulnérabilité critique trouvée au sein d’un protocole d’authentification Windows (https://twitter.com/chompie1337/status/1602757336908660736).

Une première partie est dédiée au chemin de découverte d’une vulnérabilité. Plusieurs étapes sont systématiquement présentes :

• • Le choix de la cible
  • La découverte du bug
  • L’exploitation de celui-ci
  • La réussite ou l’échec

L’auteure met en avant la rareté des publications de chercheurs qui racontent leurs échecs alors que c’est ce qui est obtenu la majorité du temps. Elle décrit ces échecs comme étant inhérents au métier et également indispensables. C’est en suivant une approche méthodique que les chercheurs trouvent des vulnérabilités, et la complexité réside principalement en l’identification de l’endroit où se trouve un défaut plutôt qu’en l’identification de la vulnérabilité même. Elle souligne également que la majorité des défauts retrouvés sont souvent les mêmes, ce qui peut s’avérer être lassant.

Elle distingue ainsi 2 approches de recherche. L’une pour un profil de chercheur « monogame » : le chercheur se concentre sur un seul projet pour en maîtriser le code autant que possible, ce qui permet d’éviter de perdre du temps sur le changement de sujet. L’autre pour un chercheur moins loyal envers ses cibles, qui se lasse plus rapidement et qui change donc régulièrement de périmètre. C’est le cas de l’auteure qui a déjà obtenu des résultats pour différents OS ou composants kernel par exemple. Le choix des cibles répond à différents critères comme son historique de développement, l’accessibilité au code source, l’architecture, etc.

Dans un second temps, l’application de cette méthode a permis d’illustrer le procédé de recherche. L’objectif était de trouver une vulnérabilité critique dans un composant sur lequel il y en avait peu ou pas de découvertes par le passé. La surface d’attaque envisagée devait donc satisfaire les critères suivants :

1. « High Severity » : Le bug trouvé doit avoir un impact majeur au sens large
2. « Ubiquitous » : La surface d’attaque doit être présente sur de nombreux systèmes avec une configuration par défaut
3. « Complex » : La cible doit présenter des fonctionnalités complexes avec des entrées utilisateur non fiables, avec des briques ajoutées au fil du temps
4. « Unpopular » (optionnel) : Le projet ne doit pas avoir été trop audité par des chercheurs pour que les vulnérabilités triviales ne soient pas encore percées à jour

Elle s’est donc penchée sur l’environnement Windows puis, après avoir listé les protocoles et serveurs qui présentent un intérêt majeur en suivant les critères énoncés, SMB a été élu. Ensuite, elle a listé et catégoriser les différentes briques de SMB afin de distinguer les briques suivantes : « Netbios », « Dialect/Capability Negotiation », « Session Setup / User authentication », « Client File Ops & other ». Après avoir évalué chacune, l’authentification a été sélectionnée. Voici la chronologie du processus de sélection :

Figure 1 – Processus de sélection de la cible (Extrait de la présentation du SSTIC slide 41)

L’authentification Windows se base sur la SSPI (Security Support Provider Interface) en employant des SSP (Security Support Providers) sous la forme de DLL. Les principaux SSP sont Keberos, NTLM, PKU2U, CredSSP, SPNEGO, NEGOEXTS. Ces deux derniers n’ayant que très peu de vulnérabilités à leur actif (une pour SPNEGO et aucune pour NEGOEXTS) sont choix s’est naturellement porté sur ces deux-là.

Une fois la cible déterminée, la phase d’analyse du code a pu débuter en commençant par trouver l’implémentation de NEGOEXT (chargé au démarrage dans LSA) puis en effectuant du reverse engineering sur ce protocole. Après avoir lu la documentation du protocole, le but était alors de trouver la fonction de parsing de messages. Une fois identifiée et après plusieurs passes d’analyse : une race condition peut être exploitée suite à l’envoi de multiples requêtes Negoex Session Setup. Son exploitation peut permettre à un attaquant d’exécuter du code arbitraire à distance.

Finalement, à la problématique de : « Trouver un bug avec un impact majeur dans une technologie très utilisée et complexe », Chompie répond par la CVE-2022-37958, une vulnérabilité dans SPNego NegoEx menant à une RCE. Et pour le mot de la fin, la recherche de surface d’attaque est tout autant un art que la recherche de vulnérabilités.

CERTA/CERT-FR : Retour sur 20+ ans de CERT à l’ANSSI

Le sous-directeur des opérations de l’ANSSI, Mathieu Feuillet, est intervenu pour la présentation de clôture en revenant sur l’historique du CERT de l’ANSSI et ses principales activités.

Du CERT-A, créé en prévision du bug de l’an 2000, au CERT-FR que l’on connaît maintenant, la structure a progressivement grandi en réponse aux menaces cyber et en suivant des évolutions aussi bien structurelles qu’au niveau des moyens mis en œuvre. En parallèle, le CERT-FR participe également au développement l’écosystème de CSIRTs en soutenant les différents acteurs. Aujourd’hui, les opérations menées au cœur de l’agence répondent aux attaques d’espionnage, de déstabilisation et d’irruption du cybercrime.

La compromission de Bercy en 2011 a été fondatrice de l’activité opérationnelle de l’agence. En effet, la détection de cet incident, campagne « liée en sources ouvertes à la Chine », correspond à la première opération de grande ampleur qui a permis de définir des principes appliqués de nombreuses fois par la suite. Cet événement a été le marqueur du début du ciblage constant de la France à des fins politiques, diplomatiques, économiques et industrielles. Une timeline des attaques subies par un secteur régalien a été présentée, et souligne l’omniprésence des attaques avec systématiquement au moins 4 activités malveillantes simultanées :

Figure 2 – Périodes d’activité malveillante pour un secteur régalien X (Extrait de la présentation du SSTIC slide 21)

Durant les 3 années suivantes, les attaques permanentes étaient frontales, de grande ampleur et ciblaient aussi bien l’administration que les organismes d’importance vitale. Ces derniers ont alors été inclus au périmètre d’intervention. Ensuite, à partir de 2017, ces attaques sont revenues, plus discrètes qu’auparavant et ont davantage ciblé les ESN et autres structures en aval de leurs cibles pour rebondir sur celles-ci dans un second temps. Finalement, depuis 2021 et toujours dans la même optique de rebond, les structures ciblées sont de plus en plus petites et manquent généralement de moyens de sécurité. En complément des entités ciblées énoncées, les équipements embarqués comme des routeurs, pare-feu ou bornes Wi-Fi sont également visés.

L’année 2021 est celle à ce jour qui compte le plus de campagnes de compromission massive. De nouvelles techniques ont été déployées, notamment la publication de certains marqueurs et modes opératoires des attaquants pour freiner les attaques. 2021 est également l’année de Pégasus, l’espionnage de certaines personnalités grâce à la compromission de leurs téléphones, mais aussi de Solarwinds et Log4j pour lesquelles des opérations d’anticipation ont été développées pour mieux prévenir les potentielles victimes.

Par ailleurs, au sujet de la déstabilisation, l’agence a notamment dû lutter contre l’hacktivisme qui a largement émergé suite aux attentats de 2015 et à la guerre en Ukraine en 2022. Ces actions malveillantes s’inscrivent dans un contexte politique et se traduisent principalement par des dénis de service et de la défiguration (par exemple l’opération de sabotage de TV5 Monde en 2015, ou de Ka-Sat en 2022).

Quant au cybercrime, l’émergence de rançongiciels a débuté en 2018 avec le ciblage de grosses entités (« big game hunting »), moins précis et davantage opportuniste qu’auparavant. Les victimes sont généralement les entreprises les moins sécurisées par rapport à la moyenne (« En matière de cybercrime c’est comme quand vous êtes coursés par un lion, faut pas courir plus vite que le lion, faut courir plus vite que quelqu’un d’autre »). Les impacts de ce type d’attaque varient, et se matérialisent de manière concrète. Par exemple, pour les établissements de santé, les conséquences concernent directement les patients.

En conclusion, les actions défensives sont indispensables et fonctionnent face à l’augmentation de la menace.

Bug hunting in Steam: a journey into the Remote Play protocol

Une autre présentation de recherche de vulnérabilités, cette fois-ci avec Valentino Ricotta (@face0xff), a été exposée, concernant un protocole de la plateforme Steam. L’auteur a ciblé cette plateforme du studio Valve pour des raisons de popularité, il s’agit de la plus utilisée par les joueurs en ligne, ainsi que pour la pluralité des fonctionnalités proposées. La surface d’attaque pour viser un joueur comprend les composants des jeux, le moteur source commun aux jeux Valves, l’API steamworks ou encore le client Steam. Ce dernier comporte moins de recherches de vulnérabilités et a donc été choisi par l’auteur.

Lors de son analyse du client, Valentino a été confronté au protocole « Remote Play », non documenté, permettant à un joueur qui ne possède pas le jeu de jouer au travers d’un autre joueur qui, lui, le possède, alliant streaming et contrôle distant (ce qui fait écho à sa présentation de l’an passé sur RDP).

Plus précisément, il nous explique le fonctionnement de ce protocole : pour débuter une session, l’hôte envoie un lien d’invitation à l’invité, puis une connexion directe est établie entre eux (P2P / relai transparent). Le client peut alors attaquer l’hôte et réciproquement. Le cas le plus impactant est celui de l’attaque de l’invité (le client) : le seul prérequis pour l’invité est de disposer d’un client Steam. En exploitant le wrapper « steam:// » qui peut être caché sur une page Web, un attaquant (l’hôte) pourrait établir une connexion avec des utilisateurs.

Une fois le comportement du protocole déterminé, son implémentation a été étudiée. Une phase de reverse a permis de déterminer le cheminement logique des flux réseaux qui passent successivement par :

1. La réception réseau, l’interface pour échanger les données
2. Le traitement du header des paquets, qui introduit le concept de channel
3. La répartition des paquets suivant leur channel.

Figure 3 – Représentation logique des flux réseau (Extrait de la présentation du SSTIC slide 31)

L’auteur explique que les channels sont des couches d’abstraction pour paralléliser l’envoi de données suivant s’il s’agit de flux audio, vidéo, de contrôle, etc. Il a d’ailleurs choisi de s’intéresser à 3 d’entre eux (contrôle, statistiques et données) et à défini de cette manière sa surface cible :

• • Les messages de contrôle (une centaine de types de messages)
  • L’HID distant qui ajoute des messages de contrôle traité avec plus de priorité
  • Les codecs audio et vidéo

Pour trouver des vulnérabilités, la première étape de sa démarche était de réimplémenter Remote Play en incluant le client et le serveur, dans l’idée de réaliser efficacement des preuves de concept. Cette démarche a évolué en un fuzzer, rpfuzz, qui offre la possibilité d’interagir directement avec le client (invité) ou le serveur (hôte), de conserver un historique des paquets, de les répéter et les modifier, ainsi que d’organiser les paquets pour jouer un scénario précis. La modification des paquets s’effectue à l’aide d’un autre outil développé par l’auteur, pbfuzz.  Voici l’architecture de l’environnement de test :

Figure 4 – Schéma de l’environnement de tests (Extrait de la présentation du SSTIC slide 62)

Finalement, ceci a conduit à la découverte d’une dizaine de vulnérabilités qui impactent toutes les plateformes. Les deux principales qui ont été corrigées et présentées impactent les messages de contrôle et sont de type :

• • « Format string » : son exploitation permet de faire fuiter des informations mémoire du client : casser l’ASLR et scanner la mémoire par exemple
  • « Request Forgery » : l’attaque peut mener à une fuite de ressources locales ou au scan du réseau interne par exemple