devloop :: blog

Alors que Wapiti a dépassé doucement mais surement la barre des 16200 téléchargements sur SourceForge, les plus observateurs auront remarqué la sortie d'une version 2.0.0 béta avant-hier soir.

La question que vous vous posez certainement c'est comment l'on peut passer d'une version 1.1.7-alpha à une version 2.0.0-béta...
Tout simplement avec beaucoup de changements !! Et il s'en est passé des choses depuis la sortie de la précédente version.

Premièrement, le nombre de développeurs est passé de 1 à 3 grace à l'aide de 2 développeurs espagnols de ICT-Romulus.
Leur souhait était de pouvoir apporter des nouvelles fonctionnalités à Wapiti, notamment pour faciliter son intégration dans un projet de framework J2EE basé sur Maven (si j'ai tout compris lol).
Dans tous les cas ils ont proposé de participer au développement de Wapiti afin que tout les utilisateurs puissent profiter de leurs idées et de leurs modifications Cela est passé par la mise en place d'un espace SVN pour le projet pour faciliter le développement.

Leur objectif principal était de travailler sur le rendu final fournit par Wapiti. Ainsi il est possible d'obtenir un compte rendu des vulnérabilités dans 3 formats différents : XML, HTML et texte simple. Pour cela les options -f (format) et -o (output) ont été rajoutés.
Ils ont aussi réussi à séparer les payloads du code, ce qui rend plus simple leur ajout. Le code a été aussi revu et est plus modulaire.
Des règles de détection pour les failles SQL ont aussi été rajoutées.

De mon côté j'ai pû enfin résoudre le problème des boucles sans fin lors du scan d'urls en ajoutant l'option -n (ou --nice) qui permet de définir un "seuil de tolérance" au niveau des urls du même type.
Ainsi si les pages suivantes ont déjà été scannées :
http://server/p?a=x&b=1&c=x
http://server/p?a=x&b=2&c=x
http://server/p?a=x&b=2&c=y

Avec un seuil de 2, quand l'url "http://server/p?a=x&b=3&c=x" sera trouvée, elle sera exclue car déjà 2 urls du même pattern ont déjà été trouvées (http://server/p?a=x&b=*&c=x).
Même chose avec l'url http://server/p?a=x&b=2&c=z.
Par défaut aucun seuil n'est spécifié (ce qui revient à le fixer à 0). A vous de voir la valeur qui vous semble juste (10 me parait en bon compromis pour faire beaucoup de possibilités sans tourner en boucle).

J'ai aussi réussi à faire fonctionner l'authentification HTTP (option -a) en pompant sur le code de sqlmap. Même si les instructions sont sensiblement différentes par rapport à ce que Wapiti faisait, le principe est le même et je ne saurais pas dire pourquoi ça ne fonctionnait pas auparavant (alors que proxies et cookies fonctionnaient)... un des mystères de Python
Malheureusement, étant donné la façon dont les modules urllib2 fonctionnent, il est préférable de retirer l'authentification sur le serveur et d'utiliser Wapiti simplement. En effet pour chaque url, si l'authentification est présente, Python va émettre deux requêtes : une première sans authentification qui va renvoyer une erreur 401. Et une seconde avec les identifiants pour passer la vérification

Enfin la nouvelle méthode de scan XSS est complètement implémentée et la librairie Beautiful Soup a été mis à jour.

Pour la prochaine version, différents changements sont à faire comme pouvoir gérer les erreurs HTTP 500 (nouveau bug), améliorer la qualité des rapports de scan, limiter le nombre de plantages liés au décodage Unicode et enfin travailler sur la vitesse de scan de Wapiti.
En effet lors de certains tests, on s'apperçoit que Wapiti peut avoir un effet DoS sur le serveur web (voir que les 152 process lancés par Apache pour répondre aux requêtes sont tous occupés c'est pas top...) Il faut donc essayer d'envoyer le plus de requêtes possibles par connexion (ou trouver la juste proportion entre les deux)

Dans tous les cas, je ne peux que vous conseiller de passer à cette nouvelle version qui apporte des fonctionnalités importantes

Télécharger Wapiti-2.0.0-béta.

Suite de ma précédente étude du fonctionnement de Anywhere.FM.

Je me suis lancé aujourd'hui dans la "pratique" en écrivant quelques lignes de code et les résultats sont pour le moins encourageants
Je me suis orienté naturellement vers les modules urllib2 et cookielib de Python que j'avais utilisé pour Wapiti.

Les premières étapes se sont réalisées sans problème (envoies de données par GET ou POST, utilisation d'une "boîte à cookies" )
Pour la seconde étape j'avais le choix entre utiliser les capacitées de PyAMF à effectuer les requêtes mais en devant injecter mes entêtes HTTP ou rester sur l'utilisation du module urllib2 et injecter les données encodées à l'aide de PyAMF.
J'ai finalement opté pour la seconde méthode, même s'il m'a fallu un peu de temps pour comprendre quels arguments passer à quelles fonctions. Pour résumer j'utilise seulement les fonctionnalitées de création d'objet (plus propre) et d'encodeur/décodeur de PyAMF et toute la partie communication est réalisée par urllib2.

J'ai d'abord implémenté les étapes que j'avais observé au complet puis j'ai ensuite commenté certaines étapes dont l'utilité était douteuse.
Au final les réponses aux questions précédentes sont :

• _unique_request_id_ est aléatoire. On peut même le définir nous même au début. Reprendre la même valeur à chaque nouvelle session ne semble pas poser de problème, même sur des intervalles de temps rapprochés. Je n'ai pas vérifié si on pouvait se passer de l'incrémentation d'une requête à une autre
  
• Les fameuses variabes __qca et __qcb définies par le biais du Javascript sur le serveur quantserve semblent totalement superflues. Ne pas les utiliser n'entrave en rien la communication avec Anywhere.FM. De toute évidence elles sont utilisées uniquement à des fins de tracking
  
• tracker_id n'a pas d'utilité, malgré qu'il soit explicitement défini (une requête est générée uniquement à cet effet). Il pourrait s'agir d'une fonctionnalitée que les administrateurs n'ont pas encore pû implémenté mais à venir ?!
  
• Certains arguments passés à get_songs_for_user_playlists restent un mystère, toutefois on n'a pas besoin d'en savoir plus pour accèder à la librairie complète d'un utilisateur
  

Le code que vous pourrez trouver ici : PyAnywhereFM.py et sur pastebin.com n'est pas totalement fonctionnel.
En effet si on parvient bien à ouvrir une session sur le site, à effectuer des requêtes AMF et obtenir les résultats, on ne parvientpas pour le moment à décoder les réponses AMF à cause d'erreurs de décodage UTF-8. A l'heure actuelle je ne saurais pas dire si le problème vient de Anywhere.FM, de PyAMF ou encore de Python...

Il est tout de même possible d'obtenir un jeton valide pour accèder à un titre dont on connait par avance le "master_id" et le "song_ressource_id" (paramêtres qui sont fixes).
Le code tente de se connecter avec les identifiants présents dans la source (à vous d'y insérer les votres) ou fonctionnera avec l'utilisateur par défaut (démo, id = 89 comme vu la dernière fois) si les identifiants sont invalides. Il va ensuite lire un titre dans ma librairie à l'aide de mplayer.

Vous pouvez utiliser un sniffeur comme Wireshark pour comprendre ce qui se passe en fond lors de l'utilisation du script. Il faut noter toutefois que l'utilisateur "demo" a une librairie vide, c'est pour cela qu'il est possible de décommenter une ligne fixant le user_id à 46 (correspondant au compte "Free Music")

L'étape restante consiste donc à extraire les données des réponses AMF obtenues, ce qui ne devrait pas être trop difficile puisque le "master_id" et le "song_ressource_id" sont envoyés comme des chaines de caractères et non comme des entiers.
Tout cela montre qu'il est assez aisé (le code fait 129 lignes une fois les commentaires et les lignes vides retirées) de télécharger de la musique sur Anywhere.FM et malgré qu'il n'y ait pas de système permettant de rechercher un titre en particulier, il serait possible de générer une base de données des titres disponibles en récupérant les profils puis les listes de lecture des utilisateurs du site. Evidemment ça prendrait du temps, mais ce serait toujours plus rapide que de fouiller par le biais de l'interface web du site

Je viens de mettre en ligne une nouvelle version de Wapiti.
Les changements apportés concernent uniquement lswww (la partie chargée de l'exploration des sites Internet).

Les anciennes versions se basaient sur l'extension d'un fichier et ensuite sur son contenu (tel que déclaré par le serveur web) pour déterminer s'il s'agissait d'une page web (donc potentiellement exploitable).
Maintenant lswww compte principalement sur le Content-Type, ce qui fait qu'il peut dorénavant attaquer des scripts avec des extensions plus exotiques.
Exemple avec un site utilisant mod_python :

python lswww.py http://www.csb.sunysb.edu/bsb/
...........................
+ URLs :
http://www.csb.sunysb.edu/bsb/
http://www.csb.sunysb.edu/bsb/formdata.py
http://www.csb.sunysb.edu/bsb/images/X26C.jpg
http://www.csb.sunysb.edu/bsb/images/lnxcluster.jpg
http://www.csb.sunysb.edu/bsb/images/nmr_spect.jpg
http://www.csb.sunysb.edu/bsb/images/rigaku.jpg
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=A
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=B
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=C
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=D
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=E
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=F
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=G
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=H
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=I
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=J
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=K
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=L
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=admission
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=contact
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=courses
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=degreereq
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=facilities
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=faculty
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=facultyres
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=home
http://www.csb.sunysb.edu/bsb/mkpage.py?fref=onapply

+ Forms Info :
From: http://www.csb.sunysb.edu/bsb/mkpage.py?fref=contact
To: http://www.csb.sunysb.edu/bsb/formdata.py
        note : on
        name : on
        email : on

BeautifulSoup a été rajouté au package. lswww s'en sert pour nettoyer les pages web avant de les étudier dans le cas où uTidyLib n'est pas présent sur le système. C'est moins puissant que Tidy mais ça permet au moins de fermer les balises restées ouvertes.
L'objectif de cet ajout est de rendre lswww et Wapiti plus performant "out of the box" (sans installation de modules supplémentaires)

Et dans le cas où ni uTidyLib ni BeautifulSoup ne sont présent, une petite expression régulière pourra prendre le relais

Des modifications ont aussi été faites pour que le logiciel fonctionne si cookielib n'est pas installé. Par contre les options pour les cookies n'auront plus effet.

Télécharger Wapiti 1.1.6

Woohoo !!
Je viens de rendre disponible une nouvelle version de Wapiti, mon scanneur de vulnérabilités pour applications web
Pas de nouveautés dans les techniques d'attaques, les améliorations se sont portées uniquement sur la maniabilité du logiciel.

De nouvelles options ont fait leur apparition, principalement basées sur les demandes d'un utilisateur (même si je n'ai pas pû tout faire).
Parmis les nouvelles options communes à lswww et Wapiti il y a la possibilité de fixer le temps d'attente avant d'abandonner la lecture d'une page. Il suffit de passer le nombre de secondes avec -t (ou --timeout=). Ca peut être très utile pour augmenter le temps d'attente quand on a une mauvaise connexion ("56k old school style" ou utilisation d'un proxy).
Un message est aussi affiché par lswww quand le temps pour accèder à une page a excédé le temps spécifié (par défaut 6 secondes), c'est pratique pour détecter des erreurs dans un code (boucles infinies...)

Une option -v (--verbose) permet de rendre lswww et Wapiti plus ou moins verbeux. Pour Wapiti le niveau de verbosité par défaut est 0, ça correspond au comportement des précédentes versions. Le niveau 1 affiche l'url sur laquelle Wapiti est en train de travailler (celle trouvée lors de l'exploration du site). Le niveau 2 va plus loin en affichant les urls avec les payloads utilisés pour chaque attaque. Ce niveau est particulièrement verbeux, pratique si vous désirez signaler un bug

J'ai revu le code de l'application afin de la rendre plus modulaire. Désormais un jeu de fonctions permet de choisir les options pour l'attaque. On pourra par exemple se restreindre aux envois par GET (ou POST), ne chercher que des vulnérabilités de type XSS (ou autre) ou chercher uniquement les failles les plus sérieuses (inclusion de fichiers, exécution de commandes...)
L'objectif principal est de faire en sorte de faciliter le travail de ceux qui voudrait faire une interface (graphique ou non) pour Wapiti, ou intégrer Wapiti comme module pour leur application.

Pour l'instant les options en ligne de commande de Wapiti ne permettent pas de faire des choix aussi précis. L'option -m (ou --module) permet de choisir un groupement d'options par défaut. Wapiti accepte les possibilités suivantes :
GET_XSS : recherche uniquement les vulnérabilités XSS en n'envoyant les données que par GET
POST_XSS : pareil mais cette fois en utilisant seulement la méthode HTTP POST
GET_ALL : effectue toutes les catégories d'attaque en n'utilisant que la méthode GET

Des bugs ont été corrigés, comme celui dû à un entête Content-Type manquant ou encore l'impossibilité de récupérer un cookie sous Webmin.
J'ai fixé une erreur au niveau de la correction des urls dans lswww (un paramêtre interdit n'était pas détecté s'il était seul) ainsi que la gestion des erreurs 404.

Il me reste encore quelques trucs à faire comme exlure un dossier complet du scan et trouver un système de gestion des paramêtres intelligent (pour éviter que Wapiti tourne indéfiniment)

Je ne pense pas implémenter le support de SOCKS tant qu'aucun module simple à mettre en place ne sera disponible. Utilisez un proxy capable de rediriger les requêtes à la place (Privoxy ou même à coups de socat)
Voilà j'ai fait le tour.

Télécharger Wapiti-1.1.4 sur Sourceforge

Je viens de mettre en ligne une nouvelle version de Wapiti, mon scanneur de vulnérabilités pour applications web.
Cette version 1.1.0 téléchargeable sur SourceForge apporte un bon nombre d'améliorations et marque le passage à urllib2 (le module Python utilisé pour effectuer les requêtes HTTP).

Parmis les nouveautés il y a :

• la détection des redirections HTTP
  
• Le support des proxies HTTP dans Wapiti
  
• Une gestion des cookies plus évoluée et plus simple d'utilisation
  
• Détection des injections LDAP (pour PHP et Java)
  
• Détection des injections de commandes (relatives à PHP, c'est à dire les fonctions eval, system, exec, passtrhu...)
  
• Détection des injections CRLF (injections qui permettent de modifier les entêtes HTTP envoyés par le serveur)
  
• Quelques améliorations au niveau des XSS et des injections SQL
  

Dans l'ancienne version l'option -c permettait de spécifier un identifiant de session à utiliser pour scanner l'application. Ce n'était pas très pratique, de plus certaines applications envoient plusieurs entêtes Set-Cookie ou utilisent un nombre important de paramêtres de session.
Avec cette nouvelle version on n'a plus à se soucier du fonctionnement interne de l'application et à connaître le nom des paramêtres à garder.

Le paramêtre à passer à l'option -c (ou --cookie) est dorénavant le nom d'un fichier texte dans lequel sera enregistré les paramêtres de sessions.
Comme pour les anciennes versions il faut utiliser les utilitaires getcookie.py ou cookie.py pour générer ce fichier cookie. On peut ensuite l'utiliser par wapiti, toujours avec la même option.

L'authentification HTTP (pour passer les htaccess), bien qu'intégrée dans Wapiti, ne fonctionne pas avec Python 2.4. Cela est dû au module HTTPBasicAuthHandler qui est trop buggé dans cette version. Ca marchera peut-être avec Python 2.5 mais je n'ai pas pû tester.

Le code de lswww a bien évidemment évolué lui aussi. L'objectif de cette librairie est de recenser toutes les pages et les formulaires trouvés sur un site donné. Le code devrait intéresser tous les développeurs qui se battent avec urllib2, surtout que tout n'est pas documenté. Vous le trouverez ici : lswww.py

Wapiti a été utilisé par Dokeos, une application web destiné au monde de l'éducation et des formations afin de détecter et corriger des failles XSS.

Je vous invite à tester Wapiti et à faire parler de lui