PenTest2.0 : le pourquoi avant le comment !

Il suffit de faire un peu le tour des magasines, listes de diffusion, conférences/symposiums et autres blogs pour se rendre compte que la scène française (de la profession ou pas) est fortement concentrée sur les failles systèmes et tout ce qui tourne autour du Ring 0. Il semble bien que la Patrie des Lumières snobe ouvertement tout ce qui ne fournit pas un accès direct au Saint Graal du siècle dernier, à savoir le compte administrateur/root.
Fort de cette constatation, je ne suis pas étonné que l'OWASP soit si peu représentée dans notre cher pays et que ces membres en soient réduits à prêcher dans le désert numérique...
Lorsque j'ai l'occasion de lire d'anciens rapports d'audit (lors de mon arrivée chez un nouvel employeur ou bien chez des clients qui me les fournissent sous couvert du classique : "Essayez de nous trouver quelque chose de nouveau"), je remarque assez souvent que le Pentester Frenchy, après quelques copies d'écran de pop-up "XSS", concentre tout son talent à décrire le magnifique OpCode qu'il a pu "coller" au service SNMP du serveur Web afin d'obtenir son "Saint Graal". Reste que ce type de technique est improductive, voire contre-productive, dans les Pentests d'architectures Web2.0...
Après cette intro' ayant presque rien à voir avec notre sujet (digne d'un pisseur de copie à la Hackin9), j'en reviens à ce qui nous interesse : les Pentests2.0 et les différentes méthodes d'exploitation des techno' Ajax; Flash, SOAP, REST, XML-RPC et autres utilisations bizaroïdes des feed RSS/Atom...Non, je ne vais pas vous faire ce soir un cours magistral sur ce sujet à l'étendu conséquent, mais simplement discourir sur le fait que ces techno' demandent autre chose qu'un wget -r www.hackme.com | grep "executeQuery"...
Le fait est qu'il est pratiquement impossible de réaliser un Pentest d'appli' Web bâtie sur ces techno à partir de la procédure de crawling habituelle (exploration de l'appli avec son proxy préféré : Burp ou WebScarab, puis analyse de l'arborescence obtenue).
Quelle soit bâtie sur de l'AJAX ou du Flash, une page 2.0 peut être l'unique page de votre belle arborescence apparaissant dans votre proxy, mais pourtant elle sera le support d'une bonne vingtaine d'applications métiers (les appels DOM à ne pas louper) reliées à autant de serveurs d'application et de bases de données, souvent sur des systèmes n'appartenant pas à votre client (du moins à son service).
C'est ce que nos chers architectes nomment les architectures SOA ou les applications mashups (une application d'applications) dans lesquelles une page web lancée dans notre navigateur se transforme en client léger virtuel pour toutes les appli du client et ses partenaires/filiales/clients/fournisseurs.
Si votre système de facturation de Pentest est bâti sur le nombre de pages à traiter, vous allez y être de votre poche... Amis Pentester, ne rigolaient pas avec ce type d'archi', nos copains les développeurs (les petits jeunes qui sortent d'école) en pondent une dizaine chaque mois pour nos chers clients...
Les appli web2.0 s'échangent toutes sortes de formats d'information de manière asynchrone, tels que XML, du JSON (JavaScript Object Notation), du JS-array (une sorte de tableau en JavaScript) et des flux d'informations temps réel en RSS (cotations...) en provenance de différents domaines. Réaliser un diagramme simple de toutes les interactions possibles de cette appli web (la modélisation des menaces comme on aime à appeler le bô schéma visio de nos rapport d'audit) peut prendre des heures, surtout avec l'outillage dont nous disposons actuellement (Firebug...).
La clé du PenTest web2.0 réside en fait dans ces communications Cross-Domain au sein de cette page unique, ouverte à ces sources diverses et plus ou moins sûres. La boite de Pandore des XSS et autres XSRF est ouverte. Il nous reste à pouvoir analyser toutes ces données asynchrones écrites en XML, le langage le moins user-friendly de la planète.
Si cela intéresse mes quatre lecteurs, je vais essayer d'écrire quelques bafouilles la-dessus dans les prochains jours. S'ils s'en foutent, cela me servira de pense-bête, comme le reste...

Ratproxy un parser de vulnérabilités passif pour les Web Services

N'étant pas un furieux de la prog' (chacun son boulot), j'avoue avoir passé pas mal de temps à tester des scanners passifs de vuln' web à base des différents parser www dispo' ; que cela soit les vieux parser Perl, le bizaroïde hpricot (en Ruby) ou un bricolage de Python (ça c'est pour le troll). Bref, un passe-temps beaucoup plus sympa que la rédaction de propales.

Après avoir pratiquer, puis écarter le célèbre nikto, w3af avec son code source super bien documenté et l'étonnant sts-scanner, en raison de leur trop grande agressivité, j'ai finalement jeté mon dévolu sur l'outil Ratproxy de Michal Zalewski qui semble de loin le plus prometteur.

Le fait est qu'il devient de plus en plus difficile de dénicher des Pentests d'appli Web qui soient sur plate-forme de test ou de pré-prod'. De toute manière, lorsque l'on insiste un peu trop lourdement pour disposer d' un environnement hors prod', on s'en tire souvent avec une base boguée datant de 2 ans et des versions d'appli du type 0.1.0.27 qui semblent sorties tout droit d'un mauvais trip de pisseur de code stagiaire.

De toute façon, on a l'air crétin au kick-off en face du gros malin de développeur en chef qui n'arrête pas de vous contrer en affirmant que la nouvelle version n'est plus vulnérable... A moins d'avoir deux jours complets à passer sur l'appli (cela arrive encore) ou bien être assez cinglé pour utiliser un Canvas ou un Core Impact sur de la prod' (même en passant toutes mes nuits sur les sources, je n'aurais pas d'avantage confiance en leurs rootkit-maison) on est parfois tenté d'utiliser un scanner de vuln' Web pour ne pas rater son RER (Ivry la bataille, ça fait loin de la Défense...).

Mais voila, en prod, l'utilisation d'un de ces scanners est un véritable suicide. Sans compter les dénis de service sur les répartiteurs de charge poussifs, un tel outil génère toujours un nombre incalculable de XSS qui sont autant de nano-bombes à fragmentation vertes fluo portant votre dédicace... D'où ma recherche d'une solution pouvant soit être utilisée en proxy passif lors de l'exploration de l'appli' avec détection à la volée des vuln' ou soit pouvant être utilisée à partir des logs d'un Burp Proxy, de WebScarab (ou même de Paros).

Sts-scanner avait l'air bien partie sur le papier, sachant qu'il prend les logs de Burp. Burp reste aujourd'hui mon outil préféré, bien qu'il soit beaucoup moins stable sous linux que sous Windows (si vous avez une astuce pour agrandir la RAM allouée à un processus java sous Linux je suis preneur). Cependant, j'ai vite déchanté lorsque je me suis aperçu que les logs de Burp lui permettaient uniquement de traduire le javascript et le java pour passer les mécanismes d'authentification (hpricot ne comprend ni le javascript, ni le java, et pour ce qui est des technos Web2.0...) et qu'il était finalement un pur scanner actif avec tout l'arsenal d'XSS qui va bien...

Ratproxy semble l'outil que j'attendais depuis longtemps, il parle le JSON (avec un peu de bol on doit pouvoir également lancer les premiers tests sur les identifiants UDDI et DISCO) et surtout son option -d permet de choisir finement les domaines à tester (ce qui est souvent indispensables avec les appli' métier de nos chères fusions/acquisition/filiales-à-15%_du_capital...)

N'ayant pas sous la main d'appli Web Services permettant de tester pleinement Ratproxy, je vous promets de vous faire une retour d'expérience plus complet dans les prochaines semaines (peut être la semaine prochaine si le client est au rendez-vous)...

BLOG 3.0

"La chair est triste et j'ai lu tous les livres !"

J'avais le choix entre faire mourir ce blog (Erase.Submit !) ou le convertir à des domaines qui me motivent d'avantage.

Le vieil homme est mort et le NewBorn 3.0 apparaît à la lumière !!

Les prochains billets (il y en aura c'est promis) porteront donc sur les techniques Pentest qui exploitent les failles et défauts de logique des Web Services et peut être sur les audits de conf' à la sauce 27005 (il faut bien nourrir sa famille).

C'est tout pour ce soir...