Un billet de mauvaise humeur, pour chasser les miasmes :
J'ai rien à écrire d'interressant. Ou bien est-ce la flème ? Toujours est-il que ma verve s'épuise peu à peu entre les copier-coller des rapports d'audit et autres propales. Il faut vraiment ramer pour alimenter son boulot de pentester. Ce boulot est synonyme de missions courtes de moins de 20 jours. Quand j'en aurais marre, je deviendrais Consultant Orga' qui passe l'hiver au chaud avec une mission de plus de 100 jours. Une bonne politique de sécurité Coorporate. Voila ce qu'il me faut pour reprendre pied !
Si j'avais le courage, je vous parlerais de la faille de conception trouvée aujourd'hui : la bonne vieille faille qu'aucun scan de vuln' web, même un à 4000$, n'aurait pu trouvé. Mais bon, cela serait trop compliqué de décrire un script d'authentification, à la sauce Ajax, scotché sur une vieille base Domino aux ACL super-aiguisées. De toute manière, je ne sais même pas si je retrouverai un jour le même type de faille chez un autre client...
Bon, je soigne ma mauvaise grippe ce weekend et je me remotive. Promis !
vendredi, octobre 31, 2008
samedi, août 30, 2008
Fukuyama n'a jamais été un homme révolté
Bien qu'il soit sympa de vérifier chaque jour combien le petit père Francis s'est lamentablement planté en jouant les prophètes, je vous rassure, je ne vais pas tenter de vous démontrer ici en quoi l'éternel retour hégélien peut s'appliquer au Pentest web2.0 !
Quant à la notion de révolte, il faut simplement faire un diff entre l'œuvre de Camus (le révolté) et celle de Sartre (le révolutionnaire) pour comprendre l'allusion, mais je ne vais pas faire ici l'étalage de mes lettres (d'autres Pentesteurs se complaisent à le faire quotidiennement !) '];alert('Troll');//.
Les frameworks de Pentest ont révolutionné notre métier en nous délestant, entre autres, de l'énorme travail de veille-techno/adaptation-opcodes-frenchies que tout pentesteur digne de ce nom doit fournir. Bien qu'ayant trouvé un employeur qui reconnaisse enfin cette tâche en tant que "travail à part entière" (vive le code de pointage "Formation_Perso" !), je peux vous avouer, qu'en ce moment, je me fie énormément aux mises à jour de Metasploit pour tout ce qui touche au domaine Client-Serveur, afin de mieux me concentrer sur les appli' Web et en particulier le Web2.0. (Chacun son domaine de prédilection)
Les frameworks de Pentest pour appli Web sont apparemment à la mode parmis mes confrères. Pourtant, je suis resté fidèle à l'Open Source (ou est-ce ma parano/prudence habituelle ?) en m'appuyant sur le trio Burp/Wapiti/w3af plutôt que sur un framework comme Accunetix, Appscan ou Web Inspect.(oui, je sais, Burp n'est pas vraiment de l'Open Source...)
En fait, les frameworks propriétaires actuels sont très décevants lorsqu'il s'agit de réaliser un pentest d'une appli sous Ajax. Les meilleurs d'entre eux arrivent péniblement à passer en revue ("parser" dans le jargon) les objets Thick Clients (Applets Java, Controles ActiveX, ObjectsFlash...) et restent sans voix face à un appel XHR.
En raison de l'extrême transparence des techno Ajax (tout passe en clair), je ne pense pas qu'un parseur web2.0 très poussé soit actuellement indispensable. En effet, la reconnaissance d'une appli sous Ajax est tout à fait réalisable aujourd'hui à l'aide d'un furieux mélange d'interruptions sous Firebug et de scripts Greasemonkey et Chikenfoot. Avec la pratique, on arrive en quelques minutes à obtenir la liste de toutes les requêtes XHR et à extraire les fonctions intéressantes correspondantes.
En parlant de scripts Greasemonkey, je vous déconseille vivement le script WebPageFingerprint d'Aung Khant qui n'est rien d'autre qu'un cheval de Troie sur pattes ! Celui-ci rapatrie toutes les failles potentielles directement au site de yehg. L'étude de ce script est cependant très enrichissante, bien que les fonctions d'analyse restent inaccessibles sur le site de son auteur. ;-)
Pour revenir à l'idée d'un parser Ajax, un tel outil va devenir indispensable lorsque les techno' Ajax vont gagner en maturité et commencer à chiffrer/masquer toutes les XHR. En fait, un petit nombre de développeurs web2.0 semblent avoir déjà entammer ce travail d'obfuscation à l'aide des différents outils d'anonymisation de variables à leur disposition (à moins que je soit tombé sur des développeurs off-shore indiens qui protègent leur gagne-pain ??)
En dépit de l'apparente complexité d'Ajax, un tel parser n'est pas monstrueux à coder. Pour démarrer, on peut se baser sur le parser rudimentaire proposé par Sheeraj Shah : scanajax.rb et l'enrichir peu à peu au fil de ces découvertes. A savoir que cet outil ne fonctionne correctement qu'une fois toutes ces dépendances respectées : gem install rest-open-uri openuri-memcached urirequire jrexml rexml-expansion-fix
Cependant, dès que l'on rencontre des techniques d'obfuscation, il faut se raccrocher aux interruptions de Firebug et à une analyse approfondie sous WebDevelopper pour s'y retrouver. Je doute que les parser d'Acunetix ou de Web Inspect aient un quelconque avenir en la matière. Bref, il nous faut construire l'ollydbg du JavaScript/XHR.
CQFD pour la digression hégélienne...
samedi, juillet 12, 2008
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...
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...
mercredi, juillet 02, 2008
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)...
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)...
Inscription à :
Articles (Atom)
Articles
