cisco-talos/mutiny-fuzzerFuzzer de protocole réseau qui rejoue le trafic PCAP via un moteur de mutation (Radamsa) pour découvrir rapidement des vulnérabilités sur des hôtes cibles grâce à des processeurs de messages et des moniteurs personnalisables.
Article de blog ici :
Liens vers cette démonstration vidéo YouTube :
Pour plus de fonctionnalités destinées aux campagnes de fuzzing / retours / harnais :
Le Framework de Fuzzing Mutiny est un fuzzer réseau qui fonctionne en rejouant des PCAP via un fuzzer mutationnel. L'objectif est de commencer le fuzzing réseau le plus rapidement possible, au détriment de la rigueur.
Le flux de travail général pour Mutiny consiste à prélever un échantillon de trafic légitime, comme une requête de navigateur, et à le fournir à un script de préparation pour générer un fichier .fuzzer. Ensuite, Mutiny peut être exécuté avec ce fichier .fuzzer pour générer du trafic vers un hôte cible, en mutant les paquets que l'utilisateur souhaite.
Il existe des extensions qui permettent de modifier le comportement de Mutiny, notamment la modification des messages en fonction des entrées/sorties, la modification de la façon dont Mutiny répond aux erreurs réseau, et la surveillance de la cible dans un thread séparé.
Mutiny utilise Radamsa pour effectuer les mutations.
Le Proxy Decept est un proxy réseau multi-usage qui peut transférer le trafic d'une connexion socket TCP/UDP/domaine en clair ou TLS vers une connexion socket TCP/UDP/domaine en clair ou TLS, entre autres fonctionnalités. C'est un bon compagnon pour Mutiny, car il peut à la fois générer des fichiers .fuzzer directement, particulièrement utile pour le fuzzing de connexions TLS, et permettre à Mutiny de communiquer avec des hôtes TLS.
sample_apps donne une idée de base de certaines choses qui peuvent être faites avec le fuzzer, avec quelques applications/clients différents pour tester.
Écrit par James Spadaro ([email protected]) et Lilith Wyatt ([email protected])
Assurez-vous que python et scapy sont installés.
Décompressez Radamsa et exécutez make (Vous n'avez pas besoin de faire make install, sauf si vous voulez
dans /usr/bin - il utilisera le Radamsa local). Mettez à jour mutiny.py avec le chemin vers
Radamsa si vous l'avez changé.
Sauvegardez le pcap dans un dossier. Exécutez mutiny_prep.py sur <XYZ>.pcap (vous pouvez également
passer le répertoire d'un processeur personnalisé le cas échéant, plus bas). Répondez aux
questions, obtenez un fichier <XYZ>.fuzzer dans le même dossier que le pcap.
Exécutez mutiny.py <XYZ>.fuzzer <targetIP>. Cela commencera le fuzzing. Les journaux seront
enregistrés dans le même dossier, sous le répertoire
<XYZ>_logs/<time_of_session>/<seed_number>
Les fichiers .fuzzer sont lisibles et commentés. Ils permettent de modifier diverses options par fichier fuzzer, y compris quel message ou quelles parties du message sont fuzzées.
Dans un fichier .fuzzer se trouvent le contenu des messages. Ce sont simplement des lignes qui commencent par 'inbound' ou 'outbound', indiquant la direction du message. Ils sont au format chaîne Python, avec '\xYY' utilisé pour les caractères non imprimables. Ils sont générés automatiquement par 'mutiny_prep.py' et Decept, mais doivent parfois être modifiés manuellement.
Si un message contient le mot-clé 'fuzz' après 'outbound', cela indique qu'il doit être fuzzé via Radamsa. Un message donné peut avoir des continuations de ligne, en mettant simplement plus de données de message entre guillemets sur une nouvelle ligne. Dans ce cas, cette deuxième ligne sera fusionnée avec la première.
Alternativement, le mot-clé 'sub' peut être utilisé pour indiquer un sous-composant. Cela permet de spécifier un composant séparé du message, afin de fuzzer uniquement certaines parties et pour plus de commodité dans un Processeur de Message.
Voici un exemple arbitraire de données de message :
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
Cela amènera Mutiny à transmettre say hi and fuzz this but not this(0xdeadbeef). 0xdeadbeef sera transmis comme 4 octets hexadécimaux. and fuzz this sera passé à Radamsa pour le fuzzing, mais say hi et but not this(0xdeadbeef) seront laissés intacts.
Mutiny attendra une réponse du serveur après avoir transmis le seul message
ci-dessus, en raison de la ligne 'inbound'. La réponse attendue du serveur est
this is the server's expected response. Mutiny ne fera pas grand-chose avec ces
données, à part vérifier si ce que le serveur a réellement envoyé correspond à cette chaîne.
Si un crash se produit, Mutiny enregistrera à la fois la sortie attendue du serveur et
ce que le serveur a réellement répondu.
mutiny_classes/ contient les classes de base pour le Processeur de Message, le Moniteur et le Processeur d'Exception. N'importe lequel de ces fichiers peut être copié dans le même dossier que le fichier .fuzzer (par défaut) ou dans un sous-dossier séparé spécifié comme 'processor_dir' dans le fichier .fuzzer.
Ces trois classes permettent de stocker les réponses du serveur et de modifier les messages sortants, de surveiller la cible sur un thread séparé, et de modifier la façon dont Mutiny gère les exceptions.
Le Processeur de Message définit différents rappels qui sont appelés pendant une exécution de fuzzing. Dans ces rappels, tout code Python peut être exécuté. Anedoctement, ils sont principalement utilisés de trois manières.
Le plus courant est lorsque le serveur envoie des jetons qui doivent être ajoutés aux futurs
messages sortants. Par exemple, si le premier message de Mutiny se connecte,
et que le serveur répond avec un ID de session, le rappel postReceiveProcess() peut être utilisé
pour stocker cet ID de session. Ensuite, dans preSendProcess(), les données sortantes peuvent être
corrigées avec cet ID de session. Un exemple de ceci se trouve dans
sample_apps/session_server.
Une autre utilisation courante d'un Processeur de Message est de limiter ou de modifier un message fuzzé. Par exemple, si le serveur abandonne toujours les messages de plus de 1000 octets, il peut ne pas valoir la peine d'envoyer de grands messages. preSendProcess() peut être utilisé pour raccourcir les messages après le fuzzing mais avant leur envoi, ou pour lever une exception.
Lever une exception amène la dernière façon courante d'utiliser les Processeurs de Message.
Dans un rappel, toutes les exceptions personnalisées définies dans
mutiny_classes/mutiny_exceptions.py peuvent être levées. Il y a plusieurs
exceptions, toutes commentées, qui entraîneront divers comportements de Mutiny. Celles-ci
impliquent généralement la journalisation, les tentatives ou l'abandon de l'exécution en cours.
Le Moniteur a une fonction monitorTarget() qui est exécutée sur un thread séparé du
fuzzer principal Mutiny. Le but est de permettre l'implémentation d'un processus de longue durée
qui peut surveiller un hôte d'une certaine manière. Cela peut être tout ce qui
peut être fait en Python, comme communiquer avec un démon de surveillance sur la cible,
lire un long fichier, ou même simplement pinguer l'hôte de manière répétée, selon
les exigences de la session de fuzzing.
Si le Moniteur détecte un crash, il peut appeler signalMain() à tout moment. Cela
signalera au thread principal Mutiny qu'un crash s'est produit, et il enregistrera le
crash. Cette fonction doit généralement fonctionner dans une boucle infinie, car son retour
entraînera la fin du thread, et il ne sera pas redémarré.
Le Processeur d'Exception détermine ce que Mutiny doit faire avec une exception donnée
pendant une session de fuzzing. Dans le sens le plus général, la fonction
processException() traduira les exceptions Python et du système d'exploitation en actions de
gestion des erreurs de Mutiny du mieux possible.
Par exemple, si Mutiny reçoit 'Connexion refusée', la réponse par défaut est de
supposer que le serveur cible est mort de manière irrécupérable, donc Mutiny enregistrera
l'exécution précédente et s'arrêtera. C'est vrai dans la plupart des cas, mais ce comportement peut
être changé en celui de n'importe laquelle des exceptions de
mutiny_classes/mutiny_exceptions.py selon les besoins, permettant d'adapter la détection des pannes
et la correction des erreurs.