Tutoriel sur les tests de fuzz (Fuzzing)

Qu’est-ce que le test Fuzz ?

Tests de fuzzing ou fuzzing Le fuzzing est une technique de test logiciel qui consiste à introduire des données invalides ou aléatoires (appelées fuzz) dans un système afin de détecter les erreurs de codage et les failles de sécurité. Son objectif est d'insérer ces données à l'aide de techniques automatisées ou semi-automatisées et de tester le système pour déceler diverses exceptions, telles que des plantages ou des défaillances du code intégré.

Le fuzz testing a été initialement développé par Barton Miller à l'Université du Wisconsin-Madison, qui a inventé le terme après que des interférences sur une liaison modem aient provoqué le plantage des programmes qu'il utilisait. Ses étudiants ont exécuté les premiers fuzzers en 1989 et ont constaté qu'environ un tiers des utilitaires UNIX qu'ils ciblaient plantaient ou se bloquaient. Le fuzz testing est une méthode de test de robustesse. test logiciel technique, et c'est un type de Test de sécurité.

Le schéma ci-dessous illustre la boucle de fuzzing de base, où les données générées sont envoyées à l'application testée et la réponse est observée.

Pourquoi faire des tests Fuzz ?

Le fuzzing trouve toute sa place dans un plan de test car il explore les entrées pour lesquelles personne n'aurait pensé écrire un cas de test. Les principales raisons pour lesquelles les équipes l'adoptent sont énumérées ci-dessous.

• Les tests de robustesse permettent généralement de détecter les failles et les défauts de sécurité les plus graves, car un plantage constitue une preuve directe d'un chemin d'entrée non géré.
• Le test de fuzzing donne des résultats plus efficaces lorsqu'il est utilisé avec Noir Box Tests, tests bêta et autres méthodes de débogage.
• Le fuzz testing est utilisé pour vérifier la vulnérabilité des logiciels, et c'est une technique de test très rentable car les entrées sont générées plutôt que saisies manuellement.
• Le fuzzing est une technique de test en boîte noire. C'est aussi l'une des méthodes les plus courantes utilisées par les pirates informatiques pour trouver une vulnérabilité dans un système ; l'exécuter en premier lieu permet donc de limiter l'accès d'un attaquant.

Types de tests de fuzzing

Les fuzzers sont généralement classés selon leur niveau de connaissance du programme qu'ils attaquent. Plus le fuzzer en sait, plus il peut pénétrer profondément dans le code.

Type	Ce que le fuzzer sait	Utilisation typique
Flou de boîte noire	Rien concernant le fonctionnement interne ; il ne fait que visualiser les entrées et les sorties.	Un test rapide de fumée est effectué contre un point de terminaison binaire ou actif.
Flou de boîte blanche	Code source complet, souvent combiné à une exécution symbolique pour résoudre les problèmes de branches difficiles d'accès.	Analyse approfondie d'un composant dont le code source est disponible.
Flou de boîte grise	Pas d'analyse du code source, mais un retour d'information en temps réel, par exemple sur les branches de code atteintes par une entrée.	La valeur par défaut pour les moteurs modernes comme AFL++ et libFuzzer.

Une deuxième scission, plus ancienne, sépare flou stupide à partir de flou intelligentUn fuzzer basique inverse les bits sans tenir compte du format d'entrée ; la plupart de ses données sont donc rejetées par le premier analyseur syntaxique rencontré. Un fuzzer intelligent, en revanche, comprend les sommes de contrôle, les champs de longueur et la structure des messages ; ses entrées passent donc la validation et atteignent la logique sous-jacente. Fuzzing guidé par la couverture C'est le raffinement de la boîte grise qui a popularisé le fuzzing : le moteur instrumente le binaire, conserve toute entrée qui atteint une nouvelle branche et modifie les survivants, de sorte que le corpus évolue progressivement vers du code inexploré au lieu de redémarrer à partir d'un bruit aléatoire.

Comment faire des tests de fuzz

Les étapes du test de fuzzing comprennent les étapes de test de base :

Étape 1) Identifiez le système cible — Choisissez le point de terminaison binaire, la bibliothèque, le service ou le protocole qui sera attaqué, et confirmez que vous êtes autorisé à le tester.

Étape 2) Identifier les entrées — lister tous les points d'entrée que la cible lit : fichiers, arguments de ligne de commande, variables d'environnement, paquets réseau, champs de formulaire et charges utiles d'API.

Étape 3) Générer des données fuzzées — produire des entrées malformées en modifiant des échantillons valides, en les générant à partir d'un modèle du format, ou en combinant les deux.

Étape 4) Exécuter le test en utilisant des données floues — exécuter la cible sur les entrées générées, idéalement dans une boucle qui redémarre automatiquement le processus après chaque échec.

Étape 5) Surveiller le comportement du système — Surveillez les plantages, les blocages, les échecs d'assertion, l'utilisation excessive de la mémoire et les rapports du système de nettoyage plutôt que de vous contenter de vérifier la sortie imprimée.

Étape 6) Consigner les défauts — Enregistrez l'entrée exacte qui a déclenché chaque échec, réduisez-la au plus petit cas reproductible et associez-la à la pile. trace joint.

Exemples de fuzzers

Les fuzzers sont également classés selon la manière dont ils construisent leurs entrées, et les trois approches ci-dessous sont celles que vous rencontrerez le plus souvent.

• Fuzzers basés sur les mutations On modifie des échantillons de données existants pour créer de nouvelles données de test. Cette approche, très simple et directe, consiste à partir d'échantillons valides d'un protocole et à altérer progressivement chaque octet ou fichier.
• Fuzzers basés sur la génération Ils définissent de nouvelles données à partir des données d'entrée du modèle. Ils commencent à générer des données d'entrée à partir de zéro en se basant sur les spécifications.
• Fuzzers basés sur un protocole Le test de robustesse repose sur une connaissance approfondie du format du protocole, laquelle est définie par la spécification. Il consiste à intégrer la spécification dans l'outil, puis à utiliser une technique de génération de tests basée sur un modèle pour parcourir la spécification et introduire des irrégularités dans le contenu, la séquence, etc. des données. On parle alors de test de syntaxe, de test de grammaire ou de test de robustesse. Un fuzzer peut générer des cas de test à partir d'un cas existant ou utiliser des entrées valides ou invalides.

Il existe deux limites au fuzzing basé sur le protocole :

1. Les tests ne peuvent pas avoir lieu tant que la spécification n'est pas mature.
2. De nombreux protocoles utiles sont une extension des protocoles publiés. Si les tests de fuzz sont basés sur des spécifications publiées, Couverture de test pour les nouveaux protocoles sera limitée.

La technique de fuzzing la plus simple consiste à envoyer des entrées aléatoires au logiciel, soit sous forme de paquets de protocole, soit sous forme d'événements. Cette technique est très efficace pour détecter les bogues dans de nombreuses applications et services. D'autres techniques existent et sont très faciles à mettre en œuvre. Il suffit de modifier les entrées existantes, ce qui se fait simplement en inversant les bits d'une entrée.

Types de bugs détectés par Fuzz Testing

Le fuzzing évalue une exécution en fonction du comportement du programme plutôt que d'une valeur attendue ; les défauts qu'il met en évidence se regroupent donc en trois familles.

• Échecs d'assertions et fuites de mémoire : Cette méthodologie est largement utilisée pour les applications de grande envergure où les bogues affectent la sécurité de la mémoire, ce qui constitue une vulnérabilité grave. Buffer Les débordements, les utilisations après libération et les lectures hors limites apparaissent tous ici.
• Entrée invalide : Dans les tests de robustesse (fuzzing), les fuzzers servent à générer des entrées invalides pour tester les routines de gestion des erreurs, ce qui est important pour les logiciels qui ne contrôlent pas leurs entrées. Le fuzzing simple peut être vu comme un moyen d'automatiser… test négatif.
• Bugs de correction : Le fuzzing peut également servir à détecter certains types d'erreurs de « correction », comme une base de données corrompue ou des résultats de recherche inadéquats. Le fuzzing différentiel, qui consiste à soumettre la même entrée à deux implémentations et à comparer les réponses, est la méthode habituelle pour les repérer.

Outils de test de fuzz

Les outils utilisés en sécurité web peuvent être largement utilisés dans les tests de fuzzing, tels que : Burp Suite et Peach Fuzzer. Plusieurs des noms classiques ci-dessous sont désormais archivés ; leur statut actuel est donc indiqué à côté de chaque entrée.

• Fuzzer pêchePeach Fuzzer offre une couverture de sécurité plus robuste qu'un scanner. D'autres outils de test ne peuvent rechercher que les menaces connues, tandis que Peach Fuzzer permet aux utilisateurs de détecter les menaces connues et inconnues. Peach Tech a été racheté par GitLab et la Community Edition v3 n'est plus maintenue ; son successeur maintenu est la version… GitLab Protocol Fuzzer Community Edition.
• Proxy de pointeSPIKE Proxy est un outil professionnel qui recherche les vulnérabilités applicatives dans les applications web. Il couvre les fonctionnalités de base, telles que : SQL Injection et script intersite, sur un système totalement ouvert Python l'infrastructure, et elle était disponible pour Linux et WindowsCe document n'a pas été mis à jour depuis de nombreuses années et est inclus ici à titre de contexte historique.
• WebScarabWebScarab est écrit en Java Il est donc portable sur de nombreuses plateformes. Le framework WebScarab communique via les protocoles HTTP et HTTPS et fonctionne comme un proxy d'interception : il permet à l'opérateur d'examiner et de modifier les requêtes créées par le navigateur avant leur réception par le serveur, et d'examiner et de mettre à jour les réponses générées par le serveur avant leur réception par le navigateur. Toute faille détectée par WebScarab est ajoutée à sa liste de problèmes signalés. Le dépôt a été archivé en avril 2024 et est désormais en lecture seule.
• OWASP WSFuzzerWSFuzzer est un programme sous licence GPL écrit en Python qui ciblait les services web, et dans sa dernière version, était basé sur HTTP. Services SOAP étaient la cible principale. Il était livré avec WebScarab et a été retiré du service en même temps que ce dernier ; OWASP ZAP et son module complémentaire Fuzzer sont les pièces de rechange recommandées.
• Alternatives maintenues : AFL++ et libFuzzer sont les moteurs de couverture standard pour le code natif, OSS-Fuzz les exécutent en continu et gratuitement pour les projets open-source, et boofuzz couvre le fuzzing de protocoles réseau dans PythonUne liste plus complète est rassemblée dans le guide de outils de test de sécurité.

Meilleures pratiques en matière de tests de fuzz

Un outil de fuzzing pointé vers une cible et laissé sans surveillance ne trouve généralement pas grand-chose. Les pratiques décrites ci-dessous distinguent une campagne qui génère des défauts avérés d'une campagne qui ne fait que consommer inutilement des ressources CPU.

• Commencez par un bon corpus de départ. Collectez des données d'entrée réelles et valides que l'application accepte déjà. Modifier un fichier authentique permet d'accéder au code d'analyse beaucoup plus rapidement que de modifier des octets aléatoires.
• Concevez un harnais petit et rapide. Le point d'entrée doit effectuer une seule opération par exécution, éviter les appels réseau et les écritures sur disque, et retourner rapidement, car le débit est mesuré en exécutions par seconde.
• Mettez en marche les distributeurs de gel hydroalcoolique. La corruption silencieuse de la mémoire ne provoque souvent pas de plantage. AddressSanitizer et UndefinedBehaviorSanitizer la transforment en une panne immédiate et diagnostiquable.
• Courir longtemps et sans interruption. Une exécution d'une ou deux heures permet de détecter les bugs superficiels ; les bugs profonds nécessitent généralement de nombreuses heures, c'est pourquoi le fuzzing doit être intégré à une tâche CI nocturne plutôt qu'à une session manuelle.
• Minimisez et dédupliquez chaque incident. Réduisez l'entrée défaillante à sa plus petite taille et regroupez les plantages par pile. trace, sinon un seul bug se traduit par des centaines de tickets.
• Constituez un corpus de régression. Ajoutez chaque entrée reproductible à un ensemble permanent exécuté à chaque compilation, afin qu'un défaut corrigé ne puisse pas réapparaître discrètement.
• Cibler la cible légalement. Tester la robustesse d'un service tiers en production sans autorisation écrite est indiscernable d'une attaque.

Avantages des tests Fuzz

Utilisée avec des attentes réalistes, la technique du fuzzing apporte une valeur ajoutée que d'autres techniques peinent à égaler.

• Les tests de fuzzing améliorent les tests de sécurité logicielle.
• Les bugs découverts lors du fuzzing sont parfois graves et sont souvent les mêmes que ceux utilisés par les attaquants, notamment les plantages, les fuites de mémoire et les exceptions non gérées.
• Si certains bugs ne sont pas détectés par les testeurs en raison de contraintes de temps et de ressources, ces bugs sont également découverts lors des tests de fuzzing.
• Les données d'entrée sont générées par une machine, ce qui permet à la couverture de s'étendre continuellement pendant la nuit sans effort manuel supplémentaire.

Inconvénients des tests Fuzz

Les mêmes propriétés qui rendent le fuzzing peu coûteux limitent aussi ce qu'il peut prouver.

• Les tests de robustesse à eux seuls ne peuvent pas fournir une image complète d'une menace de sécurité globale ou d'un ensemble de bogues.
• Les tests de fuzzing sont moins efficaces pour lutter contre les menaces de sécurité qui ne provoquent pas de plantages de programmes, comme certains virus, vers et chevaux de Troie.
• Les tests de fuzzing ne peuvent détecter que les défauts ou menaces relativement simples, et ils ne permettent pas de raisonner sur la logique métier.
• Pour fonctionner efficacement, il nécessite un temps machine important.
• Définir une condition limite avec des entrées aléatoires est très problématique, même si les testeurs résolvent désormais une grande partie de ce problème grâce à des algorithmes déterministes pilotés par les entrées de l'utilisateur.

Tests de fuzzing vs tests d'intrusion

Ces deux activités visent à détecter les failles de sécurité, mais elles répondent à des questions différentes et sont rarement interchangeables.

Critères	Test de Fuzz	Tests de pénétration
Guidé par	Un moteur automatisé générant des entrées malformées	Un testeur compétent raisonnant sur le système
Cherche des	Plantages, blocages et défauts de sécurité de la mémoire	Failles exploitables, notamment les failles logiques et de configuration
Profondeur	Couverture d'entrée très large, raisonnement superficiel	Couverture ciblée, raisonnement approfondi
Sortie	Reproduction des entrées et de la pile traces	Un rapport de conclusions comprenant les vecteurs d'exploitation et les niveaux de risque
Meilleur moment	En continu, dans le pipeline de construction	Périodiquement, contre un candidat à la libération

En pratique, les deux se nourrissent mutuellement : le fuzzing élimine les plantages bon marché et automatisables afin que le temps limité d’un testeur soit consacré aux défauts que seul un humain peut repérer.

FAQ