Fuzzing - méthodes de jeux d'essais et tests d'applications non pas orientés vers les sorties attendues en fonctions des entrées prévues, mais en inondant l'application d'entrées inattendues et aléatoires ainsi que tout ce qui est du genre scanners de failles de sécurité.

cr  01.04.2012      r+  22.10.2024      r-  22.10.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Un programme (une application) est constitué de modules qui vont coopérer. Chaque module/fonction est constitué d'une acceptation de données en entrée, d'un processus de travail sur ces entrées et d'une sortie des résultats du travail.

Lors de l'écriture d'un programme, on définit un cahier des charges, une algorithmique et des jeux d'essais. Les jeux d'essais prévoient (en théorie) tous les cas de figure possibles en entrée et en sortie, ce qui permet de vérifier la cohérence logique et mathématique des 3 composants (entrées – algorithme – sorties).

Un fuzzer (le fuzzing ou fuzz testing) est un autre type de jeux d'essais. Au lieu d'utiliser les entrées dont la structure est prévue, on balance en (presque) vrac tout un tas d'entrées inattendues, invalides et générées de manière aléatoires (l'inverse des jeux d'essais méthodiques). On y ajoute toutes sortes d'entrées que l'on sait provoquer des plantages (par exemple les codes ASCII 00 à 1F). On regarde ce qui se passe et on corrige. On cherche à piéger l‘application. Le fuzzer (le fuzzing ou fuzz testing) peut présenter :

• Des fichiers dont les contenus tentent/tendent des pièges
• Des simulations d'entrées au clavier
• Des simulations de manipulations d'une souris
• Des simulations d'insertions/éjections de périphériques à des moments inattendus
• Des simulations de contraintes matérielles en utilisant une machine virtuelle (taille mémoire, vitesse processeur, tailles des caches, taille de la mémoire virtuelle, espace disque libre, erreurs Ethernet, erreurs Wi-Fi, erreurs Bluetooth, erreurs de géolocalisation, micro, caméra, voix, versions du système d'exploitation, etc.)
• Des corruptions des variables d'environnement
• Etc.

On regarde si les entrées non valides sont bien rejetées ou si elles passent la gestion des entrées et sont prises en traitement. Que se passe-t-il alors ?

En fonction de ce que l'on cherche, on peut donner au fuzzer (le fuzzing ou fuzz testing) les tests/recherches de failles de sécurité utilisés dans les outils comme Metasploit.

Le fuzzing est très simple à mettre en œuvre et utiliser. Il est également peu coûteux.

Certains chercheurs ne publient pas les résultats trouvés lors des fuzzing appliqués sur des systèmes d'exploitation ou de grandes applications, y compris des SCADA, tant les failles de sécurité pouvant être exploitées en zero-day sont nombreuses à être découvertes (Sécurité par l'obscurité).