Tout va bien [STOP] Le stage à la CEIS est bien tripant [STOP] Je suis pris en CDAISI pour l’année prochaine [STOP] Fin du stage le 31 aout [STOP] J’fais pas mal de recherches perso [STOP] Je communiquerai dessus dans quelques temps [STOP] Cherche de la motivation [STOP] Toujours sur Paris [STOP] J’ai encore mon Twitter pour des nouvelles fraîches [STOP]
Nouvelles, nouvelles
juin 28th, 2010Fuzz or not to fuzz ?
mars 24th, 2010Il y a quelques jours, un nouveau fuzzer d’applications web pointait le bout de son nez. Nommé SkipFish, ce dernier s’est annoncé comme une sorte de renouveau parmi les fuzzers d’applications web. Cependant, le buzz dépasse largement la technique et ce dernier possède encore beaucoup de défauts inhérents aux fuzzers. Faisons le tour des particularités des fuzzers et démontrons pourquoi un fuzzer ne remplacera jamais un cerveau bien entraîné à la chasse aux vulnérabilités.
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 =)
Nouveau billet, si ce n’est pas malheureux ! =)
mars 3rd, 2010Non, ce n’est pas que j’avais oublié mon blog, loin de là : ce manque de billets pour une petite période venait de mon DUT, où l’on clôturait notre 3e semestre et commencions le 4e… les deux semestres les plus « violents » de la formation SRC Bordeaux. Bref, je suis bel et bien là, avec pas mal de choses à raconter et à poster.
Premièrement, j’ai un stage ! Il se fera à CEIS sur Paris pendant six mois de mi-avril à fin septembre. En gros, je suis très content d’avoir ce stage, car les missions correspondent à ce que je cherchais dans le domaine de la sécurité des systèmes d’information. Je veux remercier Nicolas Caproni (@cyber_risks) pour m’avoir éclairé sur cette offre – il sera d’ailleurs responsable de moi pendant ce stage où je ne doute pas d’apprendre un paquet de choses tout au long de ce dernier.
De plus, je voulais remercier ceux qui m’ont fait part d’offres de stages même si je les ai toutes déclinées – certaines sont arrivées récemment – car j’avais déjà mon stage à CEIS. Cependant, je vous en suis reconnaissant, cela fait toujours du bien de voir que des personnes s’intéressent à ce que l’on fait. Merci merci merci ! Il ne me manque plus qu’à enlever cette recherche de stage de mon site (grand moment d’émotion en perspective :)
En second point, je suis encore sur cet article (sorte de bilan) lié à un audit sauvage (je sais, c’est mal) que j’ai fait sur des portails web de médias français. Pourquoi ? Eh bien car je dois contacter les administrateurs, webmasters, DSI etc. pour boucher les failles qui sont bien nombreuses (et pour certaines très grosses). Cependant, ne vous attendez pas à un scoop avec les noms des médias, par respect pour leur travail, je ne divulguerait aucun nom, seule la méthodologie sera présentée. Toujours est-il qu’ils sont nombreux, et la plupart d’envergure nationale si ce n’est internationale pour certains.
Récemment, j’ai mis à jour quelques scripts sur Security Bugs Hunter au programme, des vulnérabilités que j’avais trouvées fin 2009, d’autres datant d’hier sur un simple « calendrier » dont Smashing Magazine faisait la PUB hier sur Twitter (beau #FAIL à la vue nombre de followers liés à ce compte). J’en ai encore beaucoup dans ma hotte, cependant, je ne possède pas tellement le temps de faire le tour complet de certains scripts donc je préfère attendre avant de les publier.
Pour finir, je suis en train de bosser sur la certification CISSP non pas pour la passer – si je me souviens bien, il faut avoir un minimum de cinq années d’expérience pro. en SSI et pas mal d’argent pour un indépendant – mais seulement pour apprendre de nouvelles choses dans la domaine de la sécurité. Je lis en ce moment CISSP All in one Exam guide qui possède tout le contenu lié à cette certification avec comme dans chaque livre de geek qui se respecte quelques petites blagues dans certains coins. Reste que ce petit monde de la sécurité évolue si vite que certaines notes sont déjà dépassées… mais bon, l’extrême majorité de la méthodologie, des descriptions et des sujets traités sont bons à prendre (et très bien traités !). Bref, un bouquin à avoir chez soi qui sera très bien entre Security Power Tools et Network securty hacks. L’édition poche n’existe pas, malheureusement.
Promis, je publie l’article dans quelques jours.
Micro blog : felixaime.tumblr.com
janvier 20th, 2010En attendant un prochain article qui risque d’arriver bientôt sur un retour d’expérience d’audit « sauvage » qui se conclue actuellement par une intense phase de mailling, je tenais à vous présenter mon micro blog se situant à l’adresse : felixaime.tumblr.com.
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…
Un sploit en remote pour MySQL 5 ?!
janvier 8th, 2010
Le 4 janvier surgissait sur l’internet une vidéo montrant un exploit tournant avec le framework CANVAS d’Immunity permettant l’ouverture d’un shell en remote sur MySQL 5.x selon la description de l’exploit montrée pendant cette vidéo.
Outre le fait que ce dernier est un 0day, cet exploit risque de faire très mal tant pour l’image de la firme MySQL que pour les millions de serveurs faisant tourner ce service ouvertement sur l’internet sans aucune protection particulière dans les restrictions d’accès ou le cloisonnement du processus.
Bref, qu’en est-il vraiment ? A mon avis, je pense de plus en plus à une vraie vidéo, mais je doute de plus en plus d’un vrai exploit. Quelques les éléments ci-dessous me sifflent dans l’oreille :
- Le site internet est très -trop – basique, le blog aussi pour tout vous avouer. Cependant, un whois sur ce dernier montre que le nom de domaine n’est pas récent comme on pourrait le penser. Mais un internet archive ne trouve rien.
- La société qui possède 5000 résultats de recherches sur Google prétend sur le forum d’Immunity vendre un de ses packs d’exploits 250$, cela fait très – trop – peu pour des possibles 0 Days, surtout de cette envergue. Elle a semble-il découverte la vulnérabilité en Aout, pourquoi pendant tout ce temps, elle n’a (semble-t-il – là encore) prévenu MySQL de cette brèche ?
- Nous connaissions déjà certaines possibilités de mise en place de portes dérobées sur des serveurs MySQL telles que le tool Raptor qui permettait d’ouvrir un shell sur un MySQL disposé sur Windows – ou par l’intermédiaire d’SQL injections sur un serveur web, encore fallait-il que le serveur MySQL tourne sur ce précédent serveur et que les droits UNIX soient bafoués pour que cela marche. Cependant, avec cette vidéo, on peut penser que l’exploit ne requiert pas d’authentification sur le serveur visé ou même un support/module de MySQL installé. D’ailleurs, j’aime le « Note – the exploit has been edited to be less verbose. » #WTF.
- Vous avez entendu parler un week of data base bugs prochainement ? Perso NaN. Dans les commentaires du blog ils prétendent démontrer la vulnérabilité durant cette semaine… j’aimerai bien savoir si quelqu’un à des infos, bizarrement, Google n’en a pas non plus. Normal, ce sont « eux » qui « les » organisent (sachant qu’il y a qu’un russe dernière cette société)…
Bref, je reste très septique sur cette vulnérabilité et je pense que – si elle existe – elle n’est pas effective sur une installation par défaut de MySQL. Entre 0 et 10 sur le point de la crédibilité, je mettrai 3, pas plus. Cependant, si elle existe bien et qu’elle est possible sur une installation par défaut – il y en a qui voient la vierge partout depuis que des vulnz en remote ont été découvertes sur OBSD ; il faudra faire quelques mises à jour ou appliquer quelques sécurités supplémentaires telles que :
- La définition des droits d’accès à MySQL afin que seuls certains hosts puissent s’y connecter (ce qui d’ailleurs devrait être toujours fait). Non seulement au point de vue de l’authentification de certains l’ensemble des utilisateurs dans la configuration des users de MySQL que de l’accès au serveur devant être régit par un FW.
- Chrooter de processus afin qu’une possible ouverture de shell ne puisse pas aboutir à de plus amples dégâts tels que de rooting de la Box ou la découverte de la topologie du réseau (de la DMZ) distant(e).
- Et enfin, le changement du port par défaut de MySQL (3306) afin d’éviter les bots et diverses attaques automatisées sur des comptes si ce serveur est accessible à partir de l’Internet. Cependant, cette protection ne sert à rien si le pirate a déjà sous son emprise le client se connectant sur le serveur. #FAIL
Bref, l’attente est la conclusion de cet article. Dans quelques jours nous serons fixés sur cette affaire même si à mon avis, nous aurons déjà oublié cet épisode dont la véritable finalité était de vendre quelques packs d’exploits exploitant des vulnérabilités se revendiquant critiques alors qu’il n’en est rien.
NB : Après la re-visualisation de la vidéo, je me suis aperçu d’un « req #1, req #2″ pendant l’exécution de l’exploit. Cela laisserait donc suggérer qu’il faut être authentifié auprès du serveur MySQL afin d’ouvrir un shell sur la BOX.
