Timthumb.php est un script php qui permet de redimensionner des images. Il est utilisé par de nombreux thèmes et plugins sur WordPress (comme par exemple Nivo Slider).

Le 3 Août 2011, une vulnérabilité Zero Day permettant de faire un “remote exploit” a été découvert. La mise à jour du script a suivi une journée plus tard. Malheureusement toutes les thèmes et plugins utilisant ce script n’ont pas suivi le même chemin. Il existe encore aujourd’hui beaucoup de plugins utilisant l’ancienne version de timthumb.php.

C’est en cherchant un exploit pour IIS 6.0 que je me suis rendu compte que Milw0rm a disparu du web depuis plus d’un an. Son auteur, Str0ke, aurait fait ses adieux en Juillet 2009 et aurait laissé mourir le site pour le clôturer définitivement en septembre 2009. Milw0rm était l’une des références en matière de vulnérabilité/exploit.

Mais où j’étais pendant ce temps ?

Parfois on a l’impression d’avoir des absences de quelques minutes, sur ce coup là j’ai eu une absence d’un an … Bon soit, alors voilà le billet que j’aurais pu faire il y a un an …

L’ambiance assez dark en avait fait un emblême dans le domaine, référencé par de nombreux sites, des milliers de personnes se connectés chaque jour pour venir chercher de l’information ou tout simplement publier un nouvel exploit.

milw0rm

La question que tout le monde se pose maintenant, c’est ou peut on trouver l’équivalent de Milw0rm, alors voici une petite liste non-exhaustive des différents sites web publiant des exploits :

– Bugtraq : Une mailing list faisant parti de la suite de news proposé par securityfocus. Parfois des informations pertinentes venant des éditeurs.

Offensive security : Le tout nouveau clone de milw0rm.

Metasploit : Mondialement connu Metasploit a été racheté par Rapid 7 en 2009. Leur outil gratuit permet de lancer des exploits avec une base de plusieurs milliers de payload. Pour rester à la page cela nécessite un svn update régulier.

Packet Storm Security : L’alternative de Milw0rm. Souvent les informations se recoupées d’un site à l’autre.

sebug : Un site chinois qui semble être à la page en terme d’exploit et de vulnérabilité. Parfois google traduction est nécessaire.

Security Reason : Ils sont très actif avec pas mal de vulnérabilités intéressantes.

Full Disclosure : Une très ancienne mailling list, mais comme le dit si bien l’adage : “C’est dans les vieux pots qu’on fait les meilleures soupes .”

Exploit db : La relève semble être assuré.

Comme vous pouvez le voir c’est loin d’être une liste exhaustive mais si vous connaissez d’autre site n’hésitez pas à les poster en commentaire.

J’aimerais beaucoup savoir si d’autre(s) comme moi ont raté l’info ? 😉

Parfois anodine et peu connu des internautes, ces failles permettent bien souvent d’accéder à des données personnels de l’utilisateur dans des scenario aboutis. Pour autant cette vulnérabilité n’est pas récente, c’est là que le paradoxe prends son sens.

Mais qu’est ce que le XSS ?
Le XSS, de l’anglais cross site scripting, consiste à injecter et faire interpréter ou mieux, faire exécuter du code non attendu à un navigateur web. De cette définition, on peut en déduire que l’attaque ne se situe pas du côté du serveur mais plus plutôt du côté client, en d’autres termes une action du client final est nécessaire. Donc nous avons un aspect ingénierie sociale. De plus, ce genre d’attaque ne se limite pas à un langage. Tout langage reconnu par votre navigateur peut être exploité. C’est pourquoi les failles XSS sont souvent basées sur de l’HTML et du Javascript. Pour finir la première partie de sensibilisation, la vulnérabilité XSS figurait à la première place du top ten de l’OWASP en 2007. En 2010 il occupe la seconde place.

Prenons un exemple concret, vous recevez un mail de votre banque qui vous indique que de nouveaux documents sont disponibles à partir de votre compte et ils vous donnent un lien pour accéder aux ressources. En tant qu’utilisateur vous ne fait pas attention à l’url caché derrière le nom du lien et vous cliquez pour accéder à vos documents. A ce moment précis le mal est fait ! Vous ne vous êtes rendu compte de rien du tout mais votre requête à été intercepté par un autre site qui a volé vos identifiant de votre banque. Vous n’avez rien remarqué car vous avez été redirigé. Ce scenario semble sortir tout droit d’un James Bond, malheureusement, il est bien plus probable qu’un des scénarios de James Bond. Bien entendu, il y a quelques conditions. Ce scénario considère que le site de votre banque contient un champ vulnérable aux attaques XSS, que l’attaquant connaisse votre adresse mail, et qu’il ait un serveur distant ou il pourra stocker vos identifiants de connexion. Il est considéré également pour acquis que vos identifiants soit stockés dans un cookie. Vous me direz que cela fait beaucoup de conditions, même si la dernière est peu répandu (surtout pour un site bancaire) les autres conditions sont facilement réalisables.

Voici une schématisation du scénario énoncé.

Alors comment fonctionne concrètement cross site scripting, et bien la syntaxe la plus connue est l’exécution dans un champ non validé du code suivant :

Il a pour but une fois interprété par votre navigateur, d’afficher la pop up suivante :

C’est exemple est souvent utilisé comme PoC (Proof of Concept). Mais il existe beaucoup plus de combinaison possible. Ce billet n’a pas pour vocation de faire une liste exhaustive des éléments à parser dans vos champs. Il existe de très bonnes sources si vous cherchez ce genre d’information, comme par exemple le site ha.ckers.org. Cependant il faut comprendre que ce genre d’attaque est bien plus dangereuse pour l’utilisateur final que pour les serveurs. Grâce à l’utilisation de champ ou de paramètre non validé, il est possible également de ré-écrire une page web (via l’API DOM). Je vous invite à lire l’article de Pierre Gardenat qui a été publié récemment dans le magazine français MISC (édition Mai/Juin 2010). L’article est très bien détaillé. Je me suis permis de reprendre son titre que j’aime beaucoup. J’espère qu’il ne m’en voudra pas.


source
Pierre Gardenat – XSS : de la brise à l’ouragan

La semaine dernière a été riche en événements. Alors que Microsoft sortait sa nouvelle version d’Internet Explorer (version 8), à Vancouver la CanSecWest fêtait sa dixième édition.

Le fil conducteur entre ces deux événements s’appelle Nils, un jeune étudiant Allemand. Il a réussi à mettre à mal la sécurité des trois navigateurs web les plus utilisés (dont Internet Explorer 8), et ceci sur une machine à jour.

SonicWall a bien compris le modèle commercial de la réussite.

Une fois le client démarché, et conquis par la solution, on implémente la solution. Jusque là, tout va bien. Ensuite, SonicWall innove et utilise le vieille adage qui dit:
“On se rend compte de ce que l’on a une fois qu’on l’a perdu”.

C’est comme ça que le service de vérification de licences du constructeur a cessé de fonctionner, entraînant l’invalidation des licences utilisateurs.
Résultat : toutes les fonctionnalités proposés par SonicWall ont été désactivées, genre plus d’antispam, d’antivirus, de listes noires ou de filtrage de contenu. Comme a dit Cédric Blancher:
Un Massive Epic Fail qui devrait nous rappeler quelques fondamentaux….

En effet, s’ils ont bien assimilé le concept commercial, ce n’est pas encore le cas pour leur modèle de sécurité…

Voici le bulletin d’information officiel pour plus d’information.