De w3af (mon préféré…) à Skipfish en passant par Wapiti, le petit français : les fuzzers deviennent de plus en plus évolués pour déceler une très large variété de vulnérabilités ou d’information disclosures. Cependant, les applications web sont, comme toutes applications, systémiques. De ce fait, dans une grande majorité des cas, des conditions doivent souvent être remplies afin d’accéder à certaines vulnérabilités. Ces conditions (authentifications, patterns à respecter etc.), souvent additionnelles entre elles sont très largement omises par les fuzzers, ne lisant pas, sauf dans le cadre de certains PoCs, les informations contenues dans la page (tels que les names/types des champs inputs pouvant donner pas mal d’information sur la nature des données attendues en POST/GET). Ceci aboutissant le plus généralement à de faux négatifs et donc au passage à la trappe d’un très grand nombre de vulnérabilités potentielles.

Le nombre de requêtes vers une application ciblée durant une phrase de fuzzing est aussi à ne pas négliger. Ainsi, elles se comptent en dizaines de milliers, voir, centaines de milliers pour le petit dernier Skipfish laissant une trace plus que repérable dans les logs pouvant par la suite être interprétée par un IDS/IPS.

En parlant de dispositifs ajoutés un serveur web lambda nous pouvons de plus mentionner les WAF. Ces derniers ne permettront pas de déceler une vulnérabilité même si elle est présente dernière le reverse proxy et exploitable (par exemple en utilisant des attaques du type HPP, HPF ou même plus inhérentes aux services SGBD ; voir cette très bonne présentation pour plus de détails). Ce, pour la simple et bonne raison que les fuzzers sont développés pour déceler les vulnérabilités et non bypasser certaines protections tierces protégeant l’accès à ces vulnérabilités.

Bref, les tests d’intrusions sur les applications web en front-end avec un simple navigateur et quelques plugins ont encore de beaux jours devant eux, rien ne remplacera l’expérience de l’auditeur dans son travail tant dans l’analyse du code que dans une attaque en font-end. Cependant, fuzzer une application peut s’avérer utile en appoint, notamment en local.

Pour information, j’ai passé sur w3af et sur Skipfish le script php calendar avant de réaliser cet article. Voici ce qu’ils ont découverts :

[-] Skipfish :

Il a simplement découvert l’injection SQL et une XSS dans le formulaire d’authentification de la zone d’admin (et le dossier de la zone d’admin). Aucune SQL injection dans l’index de l’application ni même l’include locale présente aussi dans l’index de l’application.

[-] w3af :

Il découvre le full path disclosure lorsque la valeur de la variable lang passée en GET n’est pas celle attendue. Il découvre aussi la LFI et une XSS (que je n’avais pas vu, présente grâce à l’erreur de retour en cas de non inclusion du fichier) mais aucune SQL injection dans l’index là aussi. Il ne découvre pas la zone d’administration, donc pas d’SQL injection ou de XSS dans le formulaire d’authentification de cette dernière.

Je ferai peut-être, un audit plus complet, avec de vraies statistiques pour comparer les fuzzers avec un audit fait à la main.

PS : Merci à @wadael pour me pousser à faire des articles =)

Ce dernier me sert afin de relayer des articles, papiers, images, citations que je trouve intéressants dans le domaine de la Sécurité des Systèmes d’Information. J’essaye d’y publier quelques liens par jour suivant le temps que j’ai. De plus, il y figurera certaines anecdotes que je rencontre de temps à autres… Cette image par exemple…

Ce script s’appelle Security Bugs Hunter et permet donc l’indexation de vulnérabilités suivant des scripts, avec la possibilité d’enregistrer le code vulnérable, le Proof of Concept de la vulnérabilité, des combos de vulnérabilités etc. Il possède par ailleurs un système de membres ayant plusieurs permissions, permettant ainsi au super administrateur de les régler suivant la confiance qu’il possède envers les abonnés.

Bref, le script aujourd’hui est beau certes, mais très pauvre en fonctionnalités (au pire, c’était juste pour me faire la main sur jQuery pour passer ensuite à autre chose…). Bref, je pense rajouter différentes petites choses telles que la possibilité d’Uploader l’application à auditer (et d’indexer ensuite par versions), de rechercher dans son code des vulnérabilités potentielles à grand coup de Regex (ce qui va ralentir un max.) et différentes choses.

Si vous voulez voir ce que cela donne, c’est par ici. Je mettrai le code source à télécharger dans quelques jours, histoire de bien le commenter et de l’alléger avec un peu de docs. (en y allant, vous gagnerez des 0dayz sur un script =)