Toute la magie du hacking moderne ne tiendrait-elle pas dans ce nœud ? Le fuzzing…

par Gilbert Thierry NLO · Publié 10 septembre 2026 · Mis à jour 11 septembre 2026

L’innovation dans le piratage existe aussi, sans qu’il soit toujours nécessaire de réinventer la roue. Comme dans le monde réel, les hackers sont passés maîtres dans l’art des détournements d’usage. Ils perçoivent en un clin d’œil le potentiel d’un outil, d’une philosophie, d’un procédé ou d’une technique… et le fuzzing en est une parfaite illustration.

L’idée derrière le concept

Également appelé test de robustesse, le fuzzing est une technique utilisée dans des pipelines de développement logiciel et en sécurité informatique, dans le but de détecter des erreurs logicielles, des bugs ou failles de sécurité susceptibles de compromettre le fonctionnement d’un logiciel ou de porter atteinte à l’intégrité ou à la confidentialité des données qu’il manipule.

L’affichage ou le retour de données à une personne non autorisée, à l’issue d’une requête malformée visant une base de données, un plantage entraînant l’indisponibilité de l’application, l’enregistrement de données invalides, l’exécution de code malicieux contenu dans des données fournies en entrées, sont des éléments qui coulent généralement de source dans le viseur des équipes de sécurité. A cela nous pouvons ajouter la recherche de(s):

Problèmes de validation des entrées : Lorsque l’application ne vérifie pas si vous lui fournissez des données erronées.
Dépassements de tampon : Lorsque l’application tente de faire tenir une quantité excessive de données dans un espace limité.
Vulnérabilités d’injection : Lorsque l’application exécute accidentellement votre requête SQL, pourtant parfaitement légitime.
Erreurs de logique : Lorsque l’application dysfonctionne parce que vous lui avez demandé de diviser par zéro par exemple.

Bien évidemment, pour l’organisation exploitant le logiciel dans le cadre d’un usage normal, ces effets ne sont pas du tout souhaitables et représentent de fait des risques de sécurité.

Des fuzzers, qui sont des plateformes de test de fuzzing, permettent de déployer plusieurs techniques capables de mettre en évidence ces vulnérabilités en fonction du contexte et de la nature de l’entité numérique à éprouver.

Domaines d’application et types de fuzzing

Domaines d’application

Bien que l’on ait largement mentionné l’application du fuzzing sur un logiciel, il faut dire que les différentes techniques y relatives s’appliquent à un éventail numérique bien plus large. On parlera notamment d’ « Application fuzzing », « Protocol Fuzzing » ou de « File Format Fuzzing ».

Application Fuzzing :

Il s’applique à toutes les briques qui peuvent composer un logiciel. Il peut s’agir des modules principaux, des services ou encore des Interfaces de Programmation d’Applications (API).

Concrètement, il sera question de tester aussi bien

les fonctionnalités d’interfaces graphiques telles que les boutons ;
les champs de saisie de formulaires ;
les options des programmes en ligne de commande ; que des commandes d’API ;
tout ce qui permet d’interagir avec un logiciel et ses composantes.

Dans le cas des applications web par exemple, on pourra tester la robustesse

des URL des paramètres ;
des formulaires ;
du contenu généré par l’utilisateur ;
des requêtes RPC qui permettent d’exécuter du code distant enregistré sur un serveur, comme s’il était sur la machine locale ;
des en-têtes ;
des cookies ;
etc.

Concernant les API qui travaillent souvent dans l’ombre de l’application principale, les tests pourraient notamment s’appliquer aux charges utiles JSON/XML, les paramètres de requête et les en-têtes.

File Format Fuzzing :

Fournir à un programme un fichier dont le format ne correspond pas aux standards, mais dont le contenu est malformé ou malveillant, constitue l’essence même du fuzzing de formats de fichiers (File Format Fuzzing).

Alors qu’une application installée sur une machine en local ou accessible via le web (application web) est susceptible de recevoir des

fichiers images (.jpg, .jpeg, .png, …) ;
feuilles de calcul (.xslx, .xlsm, .xls, .xslt, …) en provenance de Microsoft Excel, d’Open Office Calc ou autre ;
fichiers texte formatés type Word, Writer ou autre (.docx, .docm, .doc, .odt, …) ;
fichiers PDF ;
et bien d’autres,

le fuzzing de format de fichier permet de créer des fichiers corrompus pour les soumettre au logiciel pour traitement afin de voir si cela provoque des bugs, des trashs ou des effets inattendus notamment à l’affichage, si l’application tente elle-même de lire des fichiers corrompus qu’elle aurait préalablement accepté en entrée. Mais d’une manière générale, il s’agit de relever tout comportement inapproprié de l’application, aussi bien à l’entrée qu’à la sortie des fichiers.

Qu’il s’agisse de l’entrée ou de la sortie, la lecture des fichiers se fait via un parseur. Un parseur ou analyseur syntaxique est un composant logiciel qui analyse un flux de données brutes (texte, fichier, code) pour en vérifier la structure et le traduire dans un format exploitable par un programme. Sa tâche est d’interpréter des structures imbriquées, de calculer des tailles de tampons et de lire des entêtes complexes. Il occupe donc une place critique au sein d’une architecture logicielle et c’est précisément ce composant qui est ciblé lorsque l’on teste les fonctionnalités avancées d’un format.

Si un fuzzing basique se contente de tester le parseur sur sa capacité à rejeter des en-têtes malformés. Un fuzzing de format de fichier avancé (structure-aware) va forcer le parseur à exécuter le code métier de décompression. C’est au cœur de ces algorithmes de décompression que le parseur manipule dynamiquement la mémoire vive (allocations sur le heap encore appelé tas pour désigner la zone mémoire exploitée pendant le mécanisme d’allocation dynamique de la mémoire, tables de fréquence, matrices de transformation) : c’est là que résident les failles les plus critiques. Les méthodes de compression d’images ou de vidéos sont notamment concernées par ces dernières avancées.

Une illustration du fuzzing de format de fichier peut être faite en prenant le cas de la faille MS04-028 (CVE-2004-0200) au sein de la bibliothèque Microsoft GDI+.

Lors du fuzzing appliqué au décodeur JPEG, l’injection de mutations ciblées sur les en-têtes et métadonnées du format, plus particulièrement sur le segment de commentaire COM (Comment Marker, 0xFFFE), a permis de mettre en évidence un défaut d’assainissement des entrées.

La génération d’une trame comportant un champ de longueur nulle suivi d’un bloc de données malformé a provoqué un sous-dimensionnement de l’allocation mémoire (heap buffer overflow). L’absence de validation des bornes lors du traitement du flux binaire par le parseur permettait ainsi la corruption du tas et l’exécution de code arbitraire à l’ouverture de l’image.

Protocol Fuzzing :

En informatique, les protocoles sont partout. Sans eux, aucune communication entre divers composants d’un système informatique. Les protocoles définissent les règles de communication. L’un des plus connu est HTTP ou sa variante sécurisée obligatoire de nos jours HTTPS, qui sont utilisés pour l’échange de données sur le web.

Le fuzzing de protocole permet donc de tester le comportement d’un serveur lorsqu’un contenu malveillant est envoyé via un protocole donné. Pour ce faire, un outil de fuzzing de protocole envoie des paquets falsifiés à l’application testée, ou agit éventuellement comme un proxy, modifiant les requêtes à la volée et les rejouant. Ici, l’objectif principal est d’empêcher que les requêtes de protocole ne soient interprétées à tort comme des commandes et exécutées par le serveur.

Prenons l’exemple emblématique de la vulnérabilité Heartbleed (CVE-2014-0160) au sein de la bibliothèque OpenSSL. Cette faille critique résidait dans l’implémentation de l’extension Heartbeat du protocole TLS/DTLS (RFC 6520).

Lors de l’analyse de protocole par fuzzing de mutation guidé par la couverture de code (coverage-guided fuzzing), l’envoi de requêtes TLS Heartbeat spécifiquement altérées combinant un champ de longueur surévalué (payload length) et une charge utile sous-dimensionnée, a provoqué une sous-régression du contrôle de bornes (bounds check missing). Sans vérification préalable de la taille effective du tampon, le serveur renvoyait le contenu adjacent de la mémoire vive (out-of-bounds read), divulguant jusqu’à 64 ko de données sensibles (clés privées RSA, identifiants de session, données utilisateurs) par requête.

Une fois le correctif déployé, des harnais de test de fuzzing continu (harnessing) basés sur des désinfecteurs de mémoire (AddressSanitizer / ASan) et des moteurs comme libFuzzer ont été appliqués. Cette approche de fuzzing de régression a permis de valider la sanctuarisation de la gestion de la mémoire sans introduire de nouveaux comportements indéterminés ou effets de bord au niveau du transfert TLS.

Types de fuzzing

Le fuzzing peut être pratiqué dans diverses conditions, selon qu’on puisse ou non avoir accès au code source. Nous distinguons à cet effet :

Le Black-Box Fuzzing ou fuzzing en boîte noire : permet d’effectuer des tests sur une application sans avoir connaissance de la structure de son code. C’est le fait d’être ignorant de ces rouages internes qui en fait une boîte noire. Ainsi, le testeur en sécurité, se contentera des différentes interfaces fournies par l’application : ce qu’il voit, les champs qu’il peut remplir, les boutons sur lesquels il peut cliquer, les chemins ou URLs disponibles ou potentiellement disponibles, etc. Une bonne expérience et une connaissance notable des méthodes et pratiques de conception logicielle permettent à tout expert averti de savoir où « frapper », par où passer, quoi tester et comment affiner progressivement les différents essais pour mettre la cible applicative dans tous ses états.
White-Box Fuzzing ou fuzzing en boîte blanche : contrairement au fuzzing en boîte noire, les tests de sécurité se déroulent ici en connaissance de cause. L’architecture, le code source des différentes composantes sont clairement connus du testeur. Cela permet ainsi une analyse du code source pour guider l’injection de données et atteindre les parties les plus profondes de l’application, offrant une couverture de code maximale. Si de toute évidence le fuzzing en boîte blanche pourrait permettre un meilleur contrôle qualité, le fuzzing en boîte noire a pour principal atout comparatif, un déploiement plus rapide fidèle aux conditions réelles d’une attaque externe.
Gray-Box Fuzzing (fuzzing en boîte grise) : il s’agit d’une combinaison des 2 types ci-dessus évoqués ; le testeur a une connaissance partielle de la structure interne du logiciel qu’il teste. Comparé à ceux-ci, le fuzzing en boîte grise offre un meilleur compromis en utilisant une instrumentation légère pour guider le test et explorer le code efficacement.

Techniques de fuzzing

En lisant jusqu’ici, vous avez sans aucun doute relevé certains termes étranges combinés au fuzzing, notamment lorsque nous avons fait allusion au fuzzing mutatif.

Il s’agit en effet, d’une technique parmi tant d’autres, car la production de données altérées utilisées pour éprouver directement un logiciel, les fonctionnalités entourant un parseur de logiciel, ou un protocole, peut se faire de façon plus ou moins sophistiquées en fonction des techniques employées.

Techniques de base

Fuzzing par génération :

Le fuzzing par génération consiste à créer des cas de test en générant des entrées valides et invalides selon divers critères tels que les formats de fichiers, les protocoles réseau ou les structures de données spécifiques à l’application.

Fuzzing par mutation :

Également appelé fuzzing aléatoire, le fuzzing par mutation consiste à modifier les entrées existantes en les mutant de manière aléatoire. Les fuzzers basés sur la mutation prennent un ensemble d’entrées valides et effectuent des mutations sur celles-ci.

On distingue plusieurs techniques de fuzzing par mutation parmi lesquelles :

Inversion du bit de poids faible (LSB) : consiste en la modification du bit à la fin de chaque entier binaire ;
L’obfuscation des requêtes HTTP: se fait en ajoutant une entrée aléatoire à chaque en-tête HTTP ;
Modèles (templates) : repose sur l’utilisation d’une structure ou d’un format de données valide et augmente de ce fait la probabilité qu’une entrée testée par fuzzing soit acceptée par le système cible.

Fuzzing d’évolution :

Les fuzzers basés sur le fuzzing d’évolution utilisent des techniques qui partent d’un ensemble de cas de test initiaux et les améliorent itérativement en fonction de leur capacité à déclencher des vulnérabilités. Il est à n’en point douter que c’est de ce comportement que vient le mot évolution. Ici, on adapte, on peaufine on fait évoluer de façon continue.

Pour aller un peu plus en profondeur, les techniques de fuzzing évolutionnaire exploitent des algorithmes génétiques et les approches basées sur le retour d’information pour générer et affiner les cas de test.

Les algorithmes génétiques utilisent les concepts de mutation, de croisement et de sélection pour trouver des solutions à des problèmes complexes. La génération des cas de test repose sur un framework de fuzzing et les réponses obtenues des cibles de fuzzing. Le premier ensemble de cas de test est créé à l’aide d’une approche générative ou par mutation, et les cas de test suivants sont créés par progression génétique.

Ce type de technique a donc la particularité de combiner et d’ajouter un plus aux précédentes. Ce faisant, il est possible de générer automatiquement des cas de test optimisés, plus susceptibles de révéler des vulnérabilités.

Techniques avancées

Stateful Fuzzing ou fuzzing avec état :

Le fuzzing avec état consiste à envoyer des données anormales ou imprévues (données aléatoires) en respectant une séquence d’actions logique qui tient compte de la mémoire et de l’historique du système (avec état). On parle aussi de test par injection de données aléatoires avec état.

Ces caractéristiques sont telles que sa mise en œuvre peut aider à simuler divers parcours utilisateurs complexes, en envoyant des séquences d’entrées inattendues ou invalides afin d’évaluer la réaction du système à chaque étape.

À la manière d’un joueur qui chercherait à faire planter tous les niveaux d’un jeu vidéo, cette approche conserve la mémoire des actions précédentes pour éprouver des logiques métiers critiques, comme un processus d’achat en ligne où l’ajout soudain de 100 articles au panier permet d’identifier des dysfonctionnements ou des failles de sécurité.

Toutefois, il faudra noter que le stateful fuzzing s’applique autant aux logiciels qu’aux protocoles et aux formats de fichiers complexes. S’il faut donc retenir 2 mots à son sujet, c’est état et étape à tester. L’exécution d’un protocole peut aussi se faire par étapes au cours desquelles l’entrée de l’une dépend de la sortie de l’autre.

Idem pour les fichiers complexes dont certains formats stockent des tables d’indexation ou un état interne. Le fuzzer modifie des métadonnées ou des séquences de blocs pour tester la réaction du parseur de fichiers lors de la lecture pas à pas.

Differential Fuzzing :

Le differential fuzzing (ou test par injection différentielle) est une technique de sécurité qui consiste à soumettre des données aléatoires ou malformées identiques à deux implémentations distinctes censées réaliser la même tâche, afin de détecter des divergences de comportement à la manière de deux gladiateurs s’affrontant dans une arène.

Qu’il s’agisse de comparer deux logiciels ou bibliothèques de traitement (comme deux parseurs JSON ou moteurs JavaScript), deux parsers de fichiers, ou deux piles de protocoles réseau (telles que deux implémentations du protocole TLS ou deux serveurs HTTP traitant la même requête), cette approche identifie immédiatement les failles.

Si le composant A plante ou interprète une requête différemment du composant B, cela met en évidence des bogues de logique, des ambiguïtés de spécification ou des vulnérabilités critiques sans même nécessiter de connaître le comportement interne exact des systèmes comparés.

Concolic fuzzing :

Le concolic fuzzing (contraction de concrete et symbolic) est une technique avancée d’analyse logicielle qui allie exécutabilité pratique et rigueur mathématique, mêlant ainsi la science de l’analyse formelle à l’art de l’exploration dynamique.

En exécutant le programme avec des données réelles (exécution concrète) tout en évaluant simultanément le chemin emprunté sous forme de contraintes logiques (exécution symbolique), cette méthode s’applique à l’ensemble du spectre informatique : des logiciels d’application et des parseurs de fichiers jusqu’aux piles de protocoles réseau et aux pilotes de bas niveau.

Lorsqu’un choix de branchement ou une condition réseau est rencontré, un solveur logique (solveur SMT) calcule instantanément de nouvelles entrées capables de forcer l’exécution vers des zones de code jusque-là inaccessibles, permettant de découvrir des failles profondes et des cas limites extrêmement complexes que les tests aléatoires classiques ne pourraient pas forcément atteindre.

AI/ML-Based Fuzzing :

L’intégration de l’intelligence artificielle et de l’apprentissage automatique dans les processus de fuzzing permet de gagner en efficacité et même en efficience dans la recherche de vulnérabilités. Cette avancée technologique qui gagne du terrain dans l’univers de l’industrie logicielle peut être utilisée de diverses manières.

Pour la génération des données d’entrée

Les larges modèles de langage en anglais « Large Language Model » ou LLM particulièrement déployés dans des chatbots, qui sont des applications capables de dialoguer et d’interagir comme des humains au travers de prompts, peuvent être utilisés pour générer des graines initiales pertinentes et diversifiées pour le fuzzing.

Ce faisant, ils permettent d’améliorer les points de départ des campagnes de fuzzing et peuvent de ce fait, conduire à une découverte plus rapide des vulnérabilités.

Pour l’analyse des plantages et autres résultats

Pour aider les développeurs à économiser un temps et des efforts considérables dans le tri et le débogage des vulnérabilités, l’IA peut automatiser l’analyse des plantages et autres résultats de fuzzing.

Pour une lecture plus complète et approfondie du code source et la génération de correctifs

Les algorithmes mis en œuvre ont la capacité de lire entièrement le code. Ils peuvent ainsi, prioriser les cas de tests pour un optimum de performance mettant d’abord en avant les sections de code les plus critiques susceptibles de contenir des vulnérabilités, pour ensuite générer automatiquement des correctifs.

Pour aller plus loin, l’apprentissage par renforcement est utilisé pour entraîner les fuzzers à apprendre de leurs expériences et à améliorer leur capacité à trouver des vulnérabilités au fil du temps. Qui plus est, des mécanismes de collaboration existent afin que des fuzzers alimentés par l’intelligence artificielle puissent se partager des informations et apprendre les uns des autres.

A quel moment se produit le détournement d’usage ?

N’importe quelle technique de fuzzing peut voir son usage détourné. Alors que conçues pour solidifier, des black-hackers peuvent s’en servir pour fragiliser et détruire, à l’image d’un couteau que l’on pourrait utiliser pour de bonnes ou de mauvaises actions. Les nouvelles avancées sont particulièrement appréciées en la matière.

Le fuzzing par IA peut ainsi être utilisé par les pirates informatiques en deux phases : l’exploration et l’exploitation.

Dans la première phase, les acteurs malveillants analysent et comprennent le fonctionnement du système ciblé.

Après avoir cerné les schémas du système cible, ils passent à la seconde phase qui vise à

bombarder intentionnellement la cible de données construites avec soin,
observer et évaluer les résultats,
utiliser l’IA pour identifier les vulnérabilités et perfectionner l’attaque afin de détruire complètement la cible.

Avec l’IA comme catalyseur, les combinaisons de données malveillantes et adaptatives sont générées avec une précision redoutable. Les différents retours étapes par étape peuvent amener les hackers à découvrir et exploiter des vulnérabilités jusque-là inconnues (vulnérabilités zero-day).

Un exemple historique majeur où des techniques avancées de fuzzing ont été détournées par des cyberattaquants pour découvrir des failles inédites (zero-day) et causer un impact dévastateur est l’utilisation du fuzzing de protocoles et de composants noyau dans les ransomwares industriels et les cyberarmes de type Stuxnet ou WannaCry.

L’un des impacts les plus perceptibles sur le plan historique reste la découverte et l’exploitation de failles zero-day dans le protocole réseau SMBv1 de Windows (qui ont ensuite mené aux attaques mondiales WannaCry et NotPetya en 2017).

En appliquant précisément cette méthode impliquant l’exploration et l’exploitation, les attaquants ont procédé ainsi qu’il suit:

Phase d’exploration : Les attaquants ont d’abord analysé le fonctionnement interne de la pile réseau de Windows et du protocole SMB, un système complexe gérant le partage de fichiers en réseau.
Phase d’exploitation :
Ils ont bombardé le serveur SMB de paquets réseau soigneusement structurés mais altérés (fuzzing de protocole).
En observant les plantages du noyau Windows (kernel crash), ils ont ajusté pas à pas la structure des paquets envoyés.
Cette itération précise a permis de transformer un simple plantage en une vulnérabilité d’exécution de code à distance (Remote Code Execution), donnant naissance à l’exploit EternalBlue.

L’impact a été massif et planétaire :

Paralysie d’infrastructures critiques : L’exploitation de cette faille via le ver WannaCry a bloqué des hôpitaux du NHS au Royaume-Uni, des usines automobiles (Renault) et des systèmes bancaires.
Dégâts économiques records : L’attaque NotPetya, qui réutilisait cette même vulnérabilité découverte par fuzzing de protocole, a causé plus de 10 milliards de dollars de dommages à l’échelle mondiale (paralysant notamment le géant du transport maritime Maersk et la société Bouygues).

Aujourd’hui, avec l’intégration de l’IA comme catalyseur, ce processus de fuzzing adaptatif permet aux attaquants de générer ces combinaisons de données malveillantes en quelques heures au lieu de plusieurs mois, accélérant comme nous l’avons dit la découverte de failles zero-day dévastatrices.

Comment anticiper et mettre ces techniques à son avantage ?

Bien évidemment, il faut intégrer ou veiller à ce que soient intégrées les logiques de tests de sécurité dans les processus de développement de ses logiciels ou applications de toutes natures. Les pratiques modernes suggèrent de le faire non pas à la fin seulement, mais tout au long du cycle de développement. La sécurité combinée au développement, c’est ce dont nous parlons.

Cependant, le test de logiciel orienté sécurité ne s’improvise pas. Comme toute approche en ingénierie, il faut un minimum de préparation.

Les métriques

Lorsqu’on projette utiliser les techniques de fuzzing, la préparation de fond se fait en gardant en esprit leur probable efficacité sur la base de métriques. Nous pouvons à cet effet citer :

Le nombre de tests par seconde : Plus vous exécutez de cas de tests dans un laps de temps donné, plus vous avez de chances de détecter un plantage ou une erreur. Des tests de fuzzing plus rapides permettent également d’intégrer le fuzzing aux processus de tests automatisés.
Le nombre de cas de tests : on ne cherche pas tout car dans une perspective de sécuritaire, on s’intéresse surtout à ce qui ne marche pas, ou ne marche pas bien. Par conséquent, il faut chercher à restreindre les cas de tests au plus petit ensemble de modifications susceptibles de provoquer un bug ou un plantage.
Couverture du code : est une mesure de la proportion de votre code logiciel exécutée par un fuzzer. Mesurer la couverture de code pour le fuzzing peut s’avérer difficile et peut nécessiter une instrumentation binaire pour suivre quel code est exécuté lors de chaque requête de fuzzing.

Les outils

Lors du choix d’un outil de fuzzing, il est essentiel de prendre en compte les exigences du système cible, la complexité du logiciel et les ressources disponibles. L’outil choisi doit être compatible avec le langage de programmation du système cible, couvrir les protocoles et formats de fichiers pertinents et offrir des mécanismes efficaces de génération et de suivi des cas de test. Le listing qui suit est loin d’être exhaustif.

Outils généralistes

Radamsa : fuzzer open source populaire qui agit comme un générateur de données aléatoires surpuissant en appliquant de multiples mutations pour produire des entrées inattendues capables d’identifier des vulnérabilités de sécurité.
Honggfuzz : fuzzer open source multi-threadé orienté par la couverture de code, reconnu pour son efficacité à exploiter les fonctionnalités matérielles modernes (Intel PT, ARM) afin de détecter rapidement des failles logicielles complexes.

Outils visant les applications web

FFUF (Fuzz Faster U Fool): fuzzer web open source très rapide écrit en Go, principalement utilisé pour découvrir des fichiers, répertoires, sous-domaines et paramètres cachés via l’injection de dictionnaires d’attaques.
Wfuzz : outil de sécurité web flexible écrit en Python, conçu pour automatiser l’injection de dictionnaires d’attaques afin de découvrir des ressources masquées, des failles d’injection et des vulnérabilités dans les applications et API web..
Burp Suite Intruder : module de fuzzing intégré à la suite Burp, permettant de personnaliser et d’automatiser l’envoi de requêtes HTTP modifiées pour tester des paramètres, brute-forcer des identifiants et détecter des vulnérabilités dans les applications web.

Outils appliqués aux API :

Postman : plateforme d’API qui peut être utilisée comme un fuzzer léger en combinant son Runner de collections et l’injection de jeux de données variables pour envoyer en masse des requêtes modifiées et tester la robustesse des points de terminaison web.
Schemathesis : fuzzer d’API moderne qui génère automatiquement des cas de test basés sur des spécifications (comme OpenAPI ou GraphQL) pour vérifier le respect du contrat d’interface et détecter des failles logicielles.
RESTler : premier fuzzer d’API REST basé sur l’état (stateful), développé par Microsoft pour analyser les spécifications OpenAPI et tester automatiquement des séquences de requêtes tout en respectant la logique métier des services web.

Outils appliqués aux protocoles réseaux

Sulley : framework de fuzzing de protocoles réseau écrit en Python, pionnier dans l’analyse avec état (stateful) en combinant la génération de paquets malformés avec le suivi automatisé des processus ciblés pour capturer les plantages.
Boofuzz : successeur moderne du framework Sulley, spécialisé dans le fuzzing de protocoles réseau en Python, intégrant l’instrumentation des cibles, le suivi de l’état des connexions et la gestion automatique du redémarrage après un plantage.
Peach Fuzzer : plateforme de test orientée objets et protocoles qui s’appuie sur des définitions XML (Peach Pits) pour réaliser du fuzzing intelligent avec ou sans état sur des fichiers, des bibliothèques et des services réseau.
Mutiny Fuzzer : outil de fuzzing réseau basé sur la relecture de trafic (fichiers PCAP) qui se charge de muter et rejouer les paquets, le rendant particulièrement efficace pour tester des protocoles propriétaires ou non documentés.

Outils spécifiques pour les formats de fichiers

mangle.c: fuzzer par mutation de fichiers minimaliste écrit en C (notamment popularisé par Ilja van Sprundel), conçu pour altérer aléatoirement un faible pourcentage des octets d’en-tête d’un fichier source afin de tester la résistance des parsers applicatifs.
zzuf : fuzzer transparent par mutation de flux de données qui intercepte les opérations d’entrée/sortie d’un programme pour altérer les octets au vol, idéal pour tester la résistance des applications lisant des fichiers ou du trafic réseau.
AFL (American Fuzzy Lop AFL) : fuzzer guidé par la couverture de code extrêmement populaire qui utilise des algorithmes génétiques et de l’instrumentation binaire pour introduire des mutations intelligentes et découvrir des failles logicielles complexes.

Plateformes de fuzzing continu et distribué : CI/CD intégrant les opérations de sécurité (DevSecOps), orchestration, services

OSS-Fuzz : plateforme de fuzzing continu développée par Google qui intègre des moteurs modernes (comme AFL++, LibFuzzer ou Honggfuzz) sur des infrastructures cloud pour détecter automatiquement des vulnérabilités dans les projets open source majeurs.
CloudFuzz (souvent désigné sous le nom Cloudfuzzer): service cloud clé en main permettant de distribuer, d’automatiser et de passer à l’échelle des campagnes de fuzzing continu sur des infrastructures distantes sans avoir à gérer l’orchestration matérielle sous-jacente.
ClusterFuzzer : infrastructure d’exécution distribuée de fuzzing développée par Google, conçue pour orchestrer à grande échelle la découverte de vulnérabilités, le suivi de la couverture, la réduction des cas de test et la vérification automatique des correctifs.
Fuzzit : plateforme SaaS de fuzzing continu (rachetée par GitLab en 2020) qui permettait d’intégrer des moteurs comme LibFuzzer ou AFL dans les pipelines CI/CD pour automatiser la détection de vulnérabilités dans le code.

Le workflow

Voici un déroulement typique d’un test de fuzzing :

Identification de la cible : Consiste à identifier le système cible qui sera soumis aux tests. Il peut s’agir d’une application logicielle spécifique, d’un protocole réseau ou même d’un périphérique matériel. Cette identification n’est pas simplement nominative mais implique surtout de comprendre les spécifications, les exigences d’entrée et les vulnérabilités potentielles du système cible afin de concevoir et d’exécuter efficacement les tests de fuzzing.
Génération ou mutation de cas de test : Seconde étape qui consiste à générer ou à modifier les cas de test. Si l’une ou l’autre des techniques standards sus-évoquées nous saut aux yeux à ce second pallier, il ne serait pas logique de penser qu’il faudrait s’y limiter. Le but est de concevoir des cas de test visant les différentes fonctionnalités et entrées du système cible. Le choix de la technique de fuzzing dépend des exigences et des objectifs spécifiques de la campagne de fuzzing.
Exécution et monitoring de cas de tests : Consiste à surveiller l’exécution des cas de tests générés ou planifiés durant l’exécution. Le comportement qui en découle est surveillé à l’aide d’outils ou frameworks dédiés au fuzzing afin de détecter toute réponse inattendue ou anormale.
Analyse des résultats et identification des vulnérabilités potentielles : Vient clore la campagne de fuzzing. L’analyse implique l’examen des rapports d’incidents, des journaux, des traces de piles et autres données pertinentes pour déterminer les causes profondes des défaillances observées. Elle requiert à cet effet une expertise en rétro-ingénierie et en détection de vulnérabilités, pour comprendre les causes et implications de ces dernières, qu’il faudrait être capable de décrire, et d’évaluer leur impact potentiel sur la sécurité du système cible. Un rapport conséquent devra être produit question de documenter les résultats.

Les hackers éthiques, également appelés chercheurs en sécurité ou hackers à chapeau blanc, utilisent des techniques de fuzzing pour identifier les vulnérabilités et les signaler aux éditeurs de logiciels ou aux autorités de sécurité. Cependant, le pendant malveillant du côté de la tech, a décidé de s’en servir comme arme de pointe capable de trouver des failles permettant de mener des attaques majeures aux conséquences bien souvent catastrophiques. Il apparaît dès lors que la course à l’adoption d’outils et pratiques de sécurité de pointe, est similaire à une course aux armements. Que pourrait-on faire d’autre afin de parvenir au bas mot, à maintenir un équilibre des forces ? Ce d’autant plus que les réseaux 5G sont déjà là ouvrant l’espace à une surface d’attaque plus étendue, incluant désormais les objets connectés. Le fuzzing permet donc à qui sait s’en saisir, d’être proactif dans ses développements applicatifs. Il permet de prendre le lead dans la découverte et le traitement des vulnérabilités, de détenir le drapeau et laisser les autres courir, loin derrière des intérêts vitaux tant sur le plan personnel, qu’en entreprise ou dans toute autre organisation.

Toute la magie du hacking moderne ne tiendrait-elle pas dans ce nœud ? Le fuzzing…

L’idée derrière le concept