kazet/wpgarlicUn fuzzer de plugin WordPress de preuve de concept
Un fuzzer de plugins WordPress preuve de concept qui a conduit à la découverte de plus de 300 vulnérabilités dans des plugins WordPress installés sur près de 30 millions de sites.
La technique utilisée est décrite dans https://kazet.cc/2022/02/03/fuzzing-wordpress-plugins.html
Si vous souhaitez poursuivre la recherche, commencez par les plugins moins populaires – si un plugin a atteint au moins 10 000 installations actives entre octobre 2021 et janvier 2024, j'ai très probablement examiné les rapports du fuzzer (et la plupart des efforts ont été concentrés sur les plugins ayant au moins 20 000 installations actives). Comme le fuzzer fonctionne avec beaucoup d'aléatoire, certaines vulnérabilités dans ces plugins restent non découvertes – mais moins nombreuses.
Les rapports du fuzzer contiennent beaucoup de faux positifs – la plupart n'indiquent pas une vulnérabilité. Après avoir vu un rapport, analysez d'abord si le comportement que vous observez est effectivement une vulnérabilité ou un faux positif. Ne spammez pas WPScan/les fournisseurs avec des rapports bruts du fuzzer – fournissez plutôt une preuve de concept (PoC) à la place.
Pour des raisons évidentes, les exemples ne contiendront que des vulnérabilités déjà corrigées.
Supposons que vous fuzziez responsive-vector-maps dans la version 6.4.0 :
./bin/fuzz_object plugin responsive-vector-maps --version 6.4.0
(pour fuzzer la dernière version, omettez simplement –version).
Une fois le fuzzing terminé (ce qui prendrait 10 à 30 minutes pour ce plugin), vous pouvez appeler :
./bin/print_findings data/object_fuzz_results/
Vous verrez, entre autres :
.
Cela signifie que le fuzzer a détecté l'exécution de fopen() sur une charge utile connue. La plupart des charges utiles contiennent le mot GARLIC pour faciliter la détection automatique dans la sortie. Vous pouvez les voir ou les configurer dans docker_image/magic_payloads.php.
Ensuite, vous pouvez parcourir le code source et constater que le point de terminaison wp_ajax_rvm_import_markers utilise le contenu du fichier pour générer la sortie, vous permettant ainsi de lire des fichiers arbitraires sur le serveur : CVE-2021-24947.
Ce que vous voyez en blanc est un crash considéré comme intéressant (vous pouvez les modifier ou en ajouter de nouveaux dans crash_detectors.py). Le vert est le contexte. En bleu, vous voyez le nom du fichier de rapport (avec le nom du plugin), la popularité du plugin et le nom du point de terminaison (ici : le nom de l'action ajax). Les données en jaune indiquent quelles charges utiles ont été injectées dans quelles variables.
Supposons que vous fuzziez page-builder-add dans la version 1.4.9.4 :
./bin/fuzz_object plugin page-builder-add --version 1.4.9.4
Après avoir affiché les résultats, vous verrez une charge utile connue renvoyée :
.
Vous pouvez alors tester manuellement si cet endroit (rappelez-vous : en bleu vous avez le nom du point de terminaison, ici : le nom de la page de menu) est vulnérable aux XSS. Dans ce cas, il l'est : CVE-2021-25067.
./bin/fuzz_object plugin duplicate-page-or-post --version 1.4.6
Après avoir affiché les résultats, vous verrez update_option être appelé :
.
L'analyse du code du point de terminaison vous indiquera que cela conduit effectivement à une vulnérabilité XSS stockée : CVE-2021-25075.
Malheureusement, pour la plupart des plugins, le fuzzer ne trouve aucun crash intéressant, et pour le reste, la plupart des rapports sont des faux positifs. Par exemple, si vous voyez :
Call: wp_mail arguments={'to': '[email protected]', 'subject': '[Plugin contact] - http://GARLICGARLICGARLIC.example.com'}
Cela peut signifier que wp_mail est effectivement appelé, mais vous ne contrôlez pas le destinataire ni la majeure partie du sujet. Si vous voulez en être sûr, regardez le code source du plugin.
__GARLIC_ACCESSED__ _FILES[files] __ENDGARLIC__ – cela signifie qu'un accès
à un fichier téléchargé a été détecté. Aucune vérification supplémentaire n'est effectuée pour l'instant – pour vérifier s'il s'agit d'une vulnérabilité, regardez le code.$_GET['page'] si vous voulez qu'une page de menu particulière soit affichée.La première exécution du fuzzing ou des tests peut prendre environ une heure, car nous devons construire l'image Docker avec PHP et WordPress instrumentés.
./bin/fuzz_object plugin PLUGIN_SLUG
./bin/fuzz_object theme THEME_SLUG
Vous pouvez également installer un plugin à partir d'un fichier zip local :
./bin/fuzz_object plugin PLUGIN_FILE_NAME.zip
Pour afficher ce que le fuzzer a trouvé, utilisez :
./bin/print_findings data/object_fuzz_results/
Pour exécuter les tests, utilisez :
./bin/test
Attention : les tests sont longs (plus d'une heure) et comme ils vérifient si le fuzzer trouverait des vulnérabilités, ils échouent avec une certaine probabilité.
wpgarlic utilise pre-commit pour exécuter les linters et formater le code.
pre-commit est exécuté en CI pour vérifier que le code est correctement formaté.
Pour l'exécuter localement, utilisez :
pre-commit run --all-files
Pour configurer pre-commit afin qu'il s'exécute avant chaque commit, utilisez :
pre-commit install
Vous pouvez démarrer un environnement de test avec un seul plugin installé en utilisant :
./bin/manual_testing PLUGIN_SLUG|PLUGIN_PATH.zip [version]
Vous pouvez installer un plugin via son slug ou à partir d'un fichier zip local.
Il écoutera sur http://127.0.0.1:8001/
Il y aura deux utilisateurs de test dans la base de données :
Cet outil est une preuve de concept – cette section contient des endroits où il peut être amélioré pour trouver plus de vulnérabilités.