Kaizer Onion | Think thoroughly about » Exploit http://www.kaizeronion.com Think thoroughly about by Franck Wurtz Sun, 08 Jan 2012 08:16:23 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 La vulnérabilité Timthumb.php http://www.kaizeronion.com/security/exploit-security/timthumb-php-vulnerabilite-2458/#utm_source=rss&utm_medium=rss&utm_campaign=timthumb-php-vulnerabilite http://www.kaizeronion.com/security/exploit-security/timthumb-php-vulnerabilite-2458/#comments Sat, 24 Dec 2011 10:48:43 +0000 Franck http://www.kaizeronion.com/?p=2458 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.

Cette version permet d’insérer des images à partir d’une liste de site web d’autorisée. Si vous n’en avez pas l’utilité, il est fortement recommandé de vider la liste :

$allowedSites = array (
'flickr.com',
'picasa.com',
'blogger.com',
'wordpress.com',
'img.youtube.com',
'upload.wikimedia.org',
);

Le bout de code vulnérable se situe à la ligne 641 de Timthumb.php:

$isAllowedSite = false;
foreach ($allowedSites as $site) {
if (strpos (strtolower ($url_info['host']), $site) !== false) {
$isAllowedSite = true;
}
}

La fonction strpos() va retourner une valeur positive si il trouve n’importe ou dans la chaîne de caractère $site un site autorisé. En l’occurence la valeur ‘flickr.com.kaizeronion.com’ sera acceptée.

Exploitation de la vulnérabilité

À la place d’uploader une image sur le serveur, l’attaquant pourra mettre en place un fichier .php contenant du code malicieux.

La miniaturisation du va échouer, mais le fichier sera copié dans le repertoire ./cache/ utilisant le même nom d’envoi. À partir de ce moment la personne malveillante peut accéder au fichier distant et le serveur va exécuter le code malveillant.

Cette vulnérabilité est vraiment dangereuse et encore d’actualité depuis 4 mois maintenant. Vérifiez vos WordPress.

À bon entendeur, Salut !

Voici la version corrigée du script Timthumb.php

]]> http://www.kaizeronion.com/security/exploit-security/timthumb-php-vulnerabilite-2458/feed/ 0 Mais où est passé Milw0rm ? http://www.kaizeronion.com/security/mais-ou-est-passe-milw0rm-1654/#utm_source=rss&utm_medium=rss&utm_campaign=mais-ou-est-passe-milw0rm http://www.kaizeronion.com/security/mais-ou-est-passe-milw0rm-1654/#comments Fri, 12 Nov 2010 10:19:20 +0000 Franck http://www.kaizeronion.com/?p=1654 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 ? ;)

]]> http://www.kaizeronion.com/security/mais-ou-est-passe-milw0rm-1654/feed/ 0 Les failles XSS de la brise à l’Ouragan http://www.kaizeronion.com/security/les-failles-xss-de-la-brise-a-louragan-673/#utm_source=rss&utm_medium=rss&utm_campaign=les-failles-xss-de-la-brise-a-louragan http://www.kaizeronion.com/security/les-failles-xss-de-la-brise-a-louragan-673/#comments Fri, 02 Jul 2010 23:00:26 +0000 Franck http://www.kaizeronion.com/?p=673 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 :

<script>alert('Hello World')</script>

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

]]> http://www.kaizeronion.com/security/les-failles-xss-de-la-brise-a-louragan-673/feed/ 0 Fire at the QA department http://www.kaizeronion.com/security/fire-at-the-qa-department-312/#utm_source=rss&utm_medium=rss&utm_campaign=fire-at-the-qa-department http://www.kaizeronion.com/security/fire-at-the-qa-department-312/#comments Thu, 26 Mar 2009 13:04:51 +0000 Franck http://www.kaizeronion.com/?p=312 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.

“A toute chose, malheur est bon” dit l’adage. C’est ce que les personnes de Microsoft ont dû se dire lorsque Nils a fait son show. A peine sorti, une faille critique permettant de prendre le contrôle à distance de la machine est trouvée sur leur bébé. Point positif, cet événement aura été révélateur de talent.

Suite à son interview avec Ryan Naraine, Nils a déclaré qu’il voulait voir les failles de sécurité résolues. C’est pourquoi les détails techniques de la vulnérabilité ne seront pas communiqués jusqu’à ce qu’un correctif soit prêt.

On imagine la déception du département QA (quality assurance) qui a dû passer quelques mois à tester le soft. Il est difficile de rendre coupable telle ou telle équipe surtout lorsqu’on voit les délais imposés pour tester le produit dans les différents environnements ainsi que les tests de coexistence. Les tests de sécurité sont souvent la 5ème roue du carrosse. Dans un but d’amélioration de processus, j’imagine que chez Microsoft, les responsables du projet vont faire leur enquête pour trouver pourquoi une telle faille est passée à travers les mailles du filet.

Un jour après avoir publié l’interview de Nils, Ryan Naraine écrit un nouvel article dont l’intitulé est “No more free bugs”. Cet article est intéressant car il soulève un problème critique au sein des entreprises qui dévéloppent des logiciels : La chasse aux Bugs.

Dans la “chaîne alimentaire” d’un logiciel, nous rencontrons trois étapes majeures :

softwareworkflow

Une fois que le produit est testable (tests unitaires effectués suivant les requis de la fonctionnalité et validés par le développement), l’équipe de développement (souvent découpé en plusieurs petites équipes) délivre le produit à l’équipe de test (elle aussi découpé en plusieurs équipes). Ces dernières vont travailler main dans la main.

La chasse aux bugs est ouverte.

Il est utopique de penser qu’une application est délivrée sans bug. L’objectif est d’avoir un produit le plus stable  possible. La majorité des tests est fait en suivant des procédures types (suivant le standard international Common Criteria), ce qui rend assez stérile le fait de trouver de nouvelles failles surtout lorsqu’il y a de nouvelles fonctionnalités, car les cas de tests n’ont pas encore été tournés. Sachant que l’ordre des tests ne peut pas être inter changé dans le processus et que le temps est incompressible, vous comprenez maintenant pourquoi il existe un commerce underground d’achat de bugs. Il faut savoir que plus le defect est trouvé tôt, moins il coûte.

Les personnes comme Nils sont très utiles car elles ramènent du sang neuf dans le processus. Les départements de tests/QA sont comme des régulateurs que l’on ajuste en fonction des données en entrée. On interagit sur le PID en espérant obtenir la meilleure régulation, mais tant que la valeur d’entrée change, il est difficile de trouver le bon coefficient. Ce qui m’amène à dire que les départements de tests ont encore de beaux jours devant eux.

]]> http://www.kaizeronion.com/security/fire-at-the-qa-department-312/feed/ 0 SonicWall fidèlise ses clients http://www.kaizeronion.com/security/sonicwall-fidelise-ses-clients-9/#utm_source=rss&utm_medium=rss&utm_campaign=sonicwall-fidelise-ses-clients http://www.kaizeronion.com/security/sonicwall-fidelise-ses-clients-9/#comments Thu, 04 Dec 2008 12:12:42 +0000 Franck http://blog.f-wurtz.com/?p=9 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.

]]> http://www.kaizeronion.com/security/sonicwall-fidelise-ses-clients-9/feed/ 0 RFID ou Read Further Into Devices http://www.kaizeronion.com/security/rfid-ou-read-further-into-devices-15/#utm_source=rss&utm_medium=rss&utm_campaign=rfid-ou-read-further-into-devices http://www.kaizeronion.com/security/rfid-ou-read-further-into-devices-15/#comments Thu, 06 Nov 2008 00:11:28 +0000 Franck http://blog.f-wurtz.com/?p=15 Il y a quelques semaines se déroulait la grande messe de la sécurité à Luxembourg : le hack.lu.

Les talks se sont enchaînés sur 3 jours.
Comme dans toute conférence, il y a à boire et à manger du bon et du mauvais, mais le cru de cette année fut relativement bon. Nous avons pu assister à des tracks de qualité.
En autre le talk de Saumil Shah sur l’exploitation de faille dans les navigateurs web. Il comparait la structure système du navigateur web à un système d’exploitation, d’ailleurs c’était assez drôle car il disait que la sécurité des navigateurs web est équivalente à la sécurité des OS en 1990.

Adam Laurie était aussi présent. Je l’avais déjà vu à la Defcon 16 pendant la présentation de Zac Franken.
Ceci dit, Adam nous a parlé de RFID et plus précisément des puces RFID utilisé dans le passeport biométrique. On a pu voir à quel point cette technologie est sécurisée.
Alors qu’est ce qu’il nous faut?

Tout d’abord, du temps … ;)
Ensuite un lecteur RFID comme par exemple le Omnikey
Cardman 5321.

Pour ma part, j’ai testé avec Ubuntu 8.04. Les linux headers sont nécessaires pour la compilation de certains modules.

Installer le driver Omnikey.

Je vous conseille de suivre le tuto de Philippe qui explique comment installer le driver Omnikey.

Ensuite installer les composants PC/SC pyscard et PCSC-Lite nécessaires au lecteur RFID.

Une fois le lecteur installé vous pouvez le tester avec la commande :

# pcsc_scan
PC/SC device scanner
V 1.4.11 (c) 2001-2007, Ludovic Rousseau
Compiled with PC/SC lite version: 1.4.4
Scanning present readers
0: OMNIKEY CardMan 5×21 00 00
1: OMNIKEY CardMan 5×21 00 01

Wed Nov 5 23:48:32 2008
Reader 0: OMNIKEY CardMan 5×21 00 00
Card state: Card removed,

Wed Nov 5 23:48:32 2008
Reader 1: OMNIKEY CardMan 5×21 00 01
Card state: Card removed,

Installer le module pycrypt qui permet de lire le certificat inclut sur la puce RFID.
Le module Imaging est nécessaire pour afficher le résultat du dump de votre passeport. Fait attention a bien spécifier la variable d’environnement :

# export LD_LIBRARY_PATH=chemin de la librairie

Le numéro de votre passport est composé d’information connu:

[NuméroDePasseport][TrigrammeNationatlité][DateAnniversaire][Sexe][DateExpiration]

Utiliser ce numéro afin de lire le contenu de votre passeport :

# ./mrpkey.py Numéro MRZ

En image le résultat:

Bien entendu, nous pouvons très facilement modifier ces informations et les réinjecter dans une autre puce RFID.

Pour les personnes qui auraient peur de se faire lire leur passeport dans le métro, vous pouvez toujours opter pour un portefeuille DIFRwear. Visiblement il bloque les ondes RFID.

Sources
http://freeworld.thc.org/thc-epassport/
http://rfidiot.org/

]]> http://www.kaizeronion.com/security/rfid-ou-read-further-into-devices-15/feed/ 1