Pour les 20 ans du SSTIC, Intrinsec était présent afin d’assister à cette édition de 34 présentations et 22 rumps à Rennes, du 7 au 9 juin 2023.

Avant toute chose, un grand merci aux comités d’organisation et de programmation pour la qualité en tout point de cet événement.

Les conférences proposées lors de cet événement où la cybersécurité est à l’honneur ont balayé un large éventail de sujets. De la découverte de vulnérabilités sur Steam à celles sur des voitures Tesla en passant des protocoles Windows, du développement d’outils d’analyse de code source à une méthode de récupération de code PIN, ou bien encore l’emploi de l’intelligence artificielle au service de la cybersécurité, il y en avait pour tous les goûts. Je vous propose un retour d’expérience sur le SSTIC 2023 à travers le regard d’un pentester en deux temps : tout d’abord en revenant sur les présentations directement liées aux tests d’intrusion, l’objet de ce premier article, puis en exposant trois coups de cœurs, disponible ici.

Les présentations sont disponibles en vidéo sur le site du SSTIC, de même que le recueil des articles.

Les présentations et le métier de pentester

Parmi les différentes présentations et bien que les domaines de la cyber se recoupent tous, certains sujets présentés ont un lien plus étroit avec le métier de pentester que d’autres.

Découverte et exploitation de vulnérabilités chaînées

C’est notamment le cas de la conférence présentée par Kévin Gervot sur l’exploitation d’une attaque Client-Side Desync (CSD) menant ici à une XSS. Les CSD sont une variante des attaques de request smuggling qui ont été mises sur le devant de la scène l’année dernière et résultent en l’exploitation d’une désynchronisation client-serveur permettant de modifier arbitrairement la prochaine requête envoyée au serveur et de récupérer la réponse de celle-ci. Dans le cas présent, tout est parti d’un « bug de parsing ».

L’auteur développait une application Flask et utilisait la Web Server Gateway Interface (WSGI) de développement Werkzeug, solution qui lui permettait de mettre en place un serveur HTTP. Lors de ses phases de tests, il a rencontré le bug suivant, l’application Flask ne récupérant pas les paramètres POST :

Figure 1 – Bug de parsing (Extrait de la présentation du SSTIC – slide 2/27)

Le client communique avec Werkzeug qui sert d’intermédiaire et qui va traiter la « connection queue » de la manière définie par Flask, c’est-à-dire sans prendre en compte les paramètres POST ici, avant d’envoyer la requête au serveur. Les paramètres POST sont alors stockés dans la « connection queue » puis seront envoyés au serveur en préfixe de la prochaine requête. Ce comportement s’explique également par la gestion des connexions des nouvelles versions de Werkzeug qui forcent le mode « keep-alive » (lorsque les options « threaded » et « processes » sont activées dans la configuration). Ce mode permet d’indiquer au serveur de conserver la même « connection queue » pour l’ensemble des prochaines requêtes émises. Ceci conduit à un défaut de CSD, exploitable de cette manière :

Figure 2 – Exploitation d’une CSD (Extrait de la présentation du SSTIC – slide 12/27)

Se pose alors la question de comment aller plus loin à partir de cette première vulnérabilité pour augmenter la sévérité d’un scénario d’attaque sur cet environnement. En se renseignant sur une ancienne vulnérabilité de redirection libre affectant Werkzeug qui avait été corrigée, l’auteur a contourné le patch en faisant débuter la partie localisation réseau de l’url par des doubles slash ; cette partie sera enregistrée comme l’hôte de la prochaine requête. La redirection engendrée est de type 308, « permanent redirect », ce qui met en cache l’information de la nouvelle localisation dans le navigateur.

En combinant l’attaque CSD et la redirection libre, un attaquant est en mesure de forger un formulaire effectuant les actions suivantes lors de son envoie par une victime :

• Une première requête est envoyée vers l’application vulnérable. Elle est construite pour modifier la prochaine reçue par le serveur (exploitation de la CSD) ;
• La modification de la prochaine requête induit une redirection libre vers une ressource contrôlée par l’attaquant ;
• Lors du chargement d’un fichier script appelé sur la page de l’application, la redirection malveillante sera effective et mise en cache dans le navigateur ;
• La requête effectuée pour récupérer un fichier script récupèrera alors la ressource malveillante de l’attaquant qui sera exécutée par le navigateur : l’attaque aboutie en une XSS.

Cette découverte a donné lieu à la CVE-2022-29361, la preuve de concept au format vidéo set disponible ici. La remédiation résulte en la correction de la gestion des connexions « keep-alive » de Werkzeug, en coupant la connexion lorsqu’une requête HTTP est émise puis que sa réponse est envoyée.

Outils d’analyse de code

Les outils d’analyse de code peuvent être présents dans le quotidien d’un pentester, notamment pour des audits de code ou des tests d’intrusion en boîte blanche. Ce sujet a été traité par deux conférences sur l’outillage de recherche automatique de vulnérabilités, et par une troisième sur le dump de javascript au cours de la navigation d’un utilisateur.

Recherche automatique de vulnérabilités via Semgrep

Un premier outil d’analyse de code source, Semgrep, a été présenté par Claudio Merloni comme une aide à la recherche de vulnérabilités. Différents prismes d’analyses sont possibles pour identifier des défauts de sécurité, de configuration ou de syntaxe par exemple et se traduisent par l’application de règles pour retrouver des motifs définis. Ces règles sont déclarées sous forme de fichiers YAML. La communauté très active de l’outil lui permet de supporter un large panel de langages ainsi que de disposer d’une riche bibliothèque de règles dédiées.

Dans un premier temps l’outil parse les fichiers de code source à l’aide de tree-sitter afin de représenter le code sous forme d’arbre (AST) pour ensuite pouvoir l’analyser. Différents modes d’analyse sont disponibles : search, taint, extract ou join. Le principal mode, search, propose d’analyser les fichiers un à un pour une question de rapidité, et d’effectuer une analyse « intra procédurale » ; il peut être amélioré à l’aide du mode taint. Ce mode permet de suivre une variable non fiable (issue d’une entrée utilisateur par exemple) tout au long de sa chaîne d’exécution. Le mode extract, quant à lui, correspond à l’analyse de code inclus dans un autre langage en prenant en compte plusieurs fichiers (par exemple pour analyser l’ensemble du JavaScript dans des fichiers HTML). Finalement, le mode join permet de lier les résultats trouvés à l’aide de règles différentes et de mettre en avant le potentiel lien existant, ce qui peut s’apparenter à de l’analyse inter procédurale.

L’utilisation de semgrep et ses différents modes permet de mettre en lumière des vulnérabilités présentent dans un code source, comme illustré durant la présentation avec la détection de SSRF et de SQLi.

Recherche automatique de vulnérabilités via Weggli

La présentation qui a suivi, a quant à elle répondu à la question : Est-ce que les outils d’analyse automatique de code fonctionnent dans la vraie vie ? En réponse à cette problématique, l’auteur, Kevin Denis (@0xMitsurugi), s’est donné une semaine pour utiliser un de ces outils, Weggli, qui reprend la philosophie de Semgrep, c’est-à-dire la recherche de motifs dans du code.

La première étape a donc été de trouver des motifs. Pour ce faire, une piste a d’abord été suivie : écrire des vulnérabilités puis générer des règles pour les détecter. Ce processus manquait cependant de réalisme réduisant considérablement les chances de trouver des vulnérabilités sur des environnements en production à l’aide des motifs définis.

Finalement, une autre piste s’est avérée plus fructueuse, celle de travailler en amont sur les motifs pouvant être source de défauts et de les affiner pour détecter des vulnérabilités ciblées, en s’intéressant par exemple à l’utilisation de fonctions sensibles comme strcpy et strncpy. L’auteur a divisé ses règles, disponibles sur github, en 3 catégories :

• • Les fonctions dangereuses
  • La gestion de la stack
  • Les différents types de malloc

La principale problématique rencontrée était de trouver un équilibre entre la précision des motifs pour repérer les défauts et le nombre de faux positifs relevés. En effet, moins les motifs sont précis et plus le nombre de résultats remontés augmente, ce qui fait augmenter le nombre de réels défauts mais également de faux positifs, rendant l’analyse plus difficile.

Pour illustrer sa réponse à la problématique initiale, l’auteur a appliqué ses règles à Qemu, Samba et VLC, et a trouvé des défauts dans Samba et VLC. La vulnérabilité remontée sur VLC a donné lieu à la CVE 2022-41325, dont l’exploitation est relativement simple en l’absence d’ASLR, pouvant mener au crash de VLC ou à de l’exécution de code arbitraire sous certaines conditions.

Cette présentation a donc mis en évidence que les outils d’analyse de code, avec l’aide d’un chercheur en sécurité (ou un pentester), peuvent effectivement permettre de découvrir des véritables vulnérabilités.

Analyse JavaScript

Par ailleurs, l’analyse JavaScript de l’activité d’un utilisateur sur son navigateur a été présentée par Erwan Abgrall, par le biais de l’outil ChromeDump. Celui-ci permet de récupérer le code JavaScript exécuté au cours d’une navigation dans Chrome à l’aide des Chrome devtools protocols et des Websockets. Bien que le cas d’usage premier soit plutôt l’analyse défensive d’une application Web compromise, ce qui a d’ailleurs fait l’objet de la présentation, l’outil ne semble pour autant pas dénué d’intérêt dans le cadre d’un pentest. En effet, l’outil propose de récupérer le profil de navigation, l’activité JavaScript, de conserver les URL, les ressources, les requêtes et les réponses échangées, et de récupérer les captures d’écran pour les différentes actions effectuées. De plus, une fonctionnalité d’unpacking permettant de désobfusquer les premières couches de JavaScript est disponible. Ces résultats pourraient permettre de mieux appréhender certains comportements applicatifs du côté client.

Enrichir ses recommandations

D’autres présentations peuvent également être intéressantes du point de vue des tests d’intrusion pour améliorer les recommandations proposées aux clients, telles que celle sur l’outil Mercator permettant de cartographier un SI, ou encore sur les outils gmsad et OpenWec développés par le CEA pour étendre certains concepts Windows à des environnements Linux.