Hello Fox,
cela fait très longtemps que je n’ai pas publié un article sur ce blog, et c’est bien dommage. Je viens de terminer le restore de 6 sites web que j’héberge sur ma dedibox à cause de ma fainéantise.
Pourtant tout le monde le sait qu’un système à jour a moins de chance de se faire poutrer … Pour le coup j’ai rattrapé le temps perdu, et je voulais partager mon expérience avec vous si jamais vous auriez laissé à l’abandon votre WP.
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.
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 :
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.
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.