Dec 30 2008

Collision MD5 sur la signature de certificat SSL

Tag: Failles de sécuritéNicolas @ 6:30 pm

Deux chercheurs viennent de mettre en évidence une faille de sécurité permettant de générer un autorité de certication SSL valide.

Ils ont pour cela utilisé 200 PS3 en réseau pour trouver une collision dans l’algorithme MD5 utilisés pour la signature de certificat.

Concrètement, cela permet de générer des certificats SSL valide pour n’importe quel site Web. Si un attaquant à accès aux flux réseau entre le navigateur Web et le serveur, il pourra usurper l’identité du serveur Web distant.

Il est toutefois important de noter que cela nécessite une puissance de calcul important, et que les détails techniques permettant la reproduction n’ont pas été révélés.

D’autres scénarios d’exploitation plus critique sont envisageables, comme la signature d’applet Java permettant d’exécuter du code coté client.

Il n’existe pas de correctifs pour cette vulnérabilité actuellement.

Un workaround possible serait d’enlever les certificats racines utilisant des signatures MD5, cela aurait comme effet secondaire de casser la chaine de certification SSL.

Lien vers le PPT de la présentation:

http://www.phreedom.org/research/rogue-ca/md5-collisions-1.0.ppt

Site de démonstration (volontairement généré avec un certificat expiré):

https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/



Sep 19 2008

Faille : Execution de code dans PhpMyAdmin

Tag: Failles de sécuritéNicolas @ 3:17 am

Une jolie faille vient de sortir.

Il s’agit d’éxécution de code (PHP) pour un  utilisateur authentifié.

L’advisory (présent ici) nous indique le vecteur d’attaque suivant:
server_databases.php?pos=0&dbstats=0&sort_by="]) OR exec('cp $(pwd)"/config.inc.php" config.txt'); //&sort_order=desc&token=[valid token].

En allant voir dans les sources les modifs effectués (visible ici si vous êtes curieux), on peut y voir les changements suivants:

$sort_function = '
return ' . ($sort_order == 'ASC' ? 1 : -1) . ' * ' . $sorter . '($a["' . $sort_by . '"], $b["' . $sort_by . '"]);
';
usort($databases, create_function('$a, $b', $sort_function));

On voit que la chaine “sort_function” est construite par concaténation de chaine, et ceux avec une entrée utilisateur (le paramètre $sort_by).

La fonction usort est ensuite utilisé pour créer trier le tableau $database. Elle prend en deuxième argument une fonction de comparaison.

Elle est créer à la volée par la fonction “create_function”, elle même utilisant une chaine contaténée utilisant une entrée utilisateur non filtrée depuis une entrée utilisateur …

:(

Le code ainsi créer va donc être éxécuter à chaque comparaison lors du tri.

Morale de l’histoire:

1/ Ne faites pas confiance aux entrées utilisateur

2/ N’utiliser pas de fonction permettant de créer du code à la volée

3/ Patchez !!!!


Sep 15 2008

Antisocial Networks: Comment transformer un réseau social en botnet.

Tag: Failles de sécurité, rechercheArrouan @ 11:11 pm

L’Institut de Recherche en Informatique faisant parti de la fondation de recherche grécques FORTH ainsi que l’institut de recherche sur l’informatique et la communication de Singapoure ont publié un article très intéressant où ils tentent de prouver les nouveaux risques et malwares que pourraient se créer dans les réseaux sociaux.

Les auteurs de l’étude définissent un Antisocial Networks comment étant un système distribué se basant sur les réseaux sociaux et pouvant être exploité par des attquants et diriger pour coordonner des attaques réseaux. Mais ils ne se limitent pas à discuter de ce qu’est un tel type de réseau, ils ont implémenté dans la réalité de tels attaques et montrent comme ces plateformes sociales peuvent être utiliser pour lancer des attaques. Ils se sont limités à Facebook pour développer leur concept d’attaques mais cela peut être étendu à l’ensemble des réseaux sociaux disposant d’une possibilité d’extensions par des tiers personnes.

Mais pourquoi les réseaux sociaux ? Tout simplement parce que de plus en plus de personnes sont inscrites sur ces réseaux, ce qui représentent une base de donnée énorme. De plus, ces réseaux sont découpés en groupe de centre d’intérêt ce qui permet de simplement localisé des cibles. Et finalement, par défaut, les utilisateurs ont tendance à faire confiance à leurs réseaux sociaux ainsi que les applications qui s’y trouvent. L’ensemble de ces raisons montrent la capacité de nouvelles attaques qui peuvent avoir lieu sur de tels sites.

Ce principe d’utilisation du web et des utilisateurs pour lancer des attaques n’est pas nouveau, Puppetnets, proposé en 2006, est également une attaque utilisant les mêmes principes. L’idée est de créer une page avec des milliers de liens pointant vers le serveur cible. Quand un utilisateur va charger cette page, son navigateur va télécharger des milliers de liens et provoquer une sur-charge sur le serveur cible. De plus, si cette page devient virable (un “Slashdot effect” par exemple), le serveur cible va se retrouver sous un DDoS. Bref, une technique simple et efficace pour lancer un DDOS a très faible cout. En ajoutant un peu de Javascript, pour des chargements multiples des liens, la méthode devient encore plus efficace.

Bien que les auteurs aient faire leur expérimentation sur le vrai réseau Facebook, ils n’ont pas développé des fonctions trop invasive (par exemple, l’obligation d’inviter 20 amis a essayé l’application avant de pouvoir l’installer, ce qui semble une méthode classique pour augmenter la popularité d’une nouvelle application) pour éviter de perturber le fonctionnement de Facebook pour les utilisateurs légitimes. Le principe de leur application était d’afficher une nouvelle image tous les jours en provenance du site du National Geographic. Mais également, quatres frames caché qui chargeaient pour 600Kb depuis le serveur de la cible à chaque fois qu’un utilisateur utilisait l’application. Bien sur dans le cadre de leur étude, le serveur était hébergé dans le lab et isolé du reste du réseau.

Bien que la méthode utilisé était relativement simple et pas trop invasive et avec une publicité limitée (i.e. uniquement quelques personnes de la communauté de la sécurité), l’application est rapidement arrivée à plusieurs centaines d’utilisateurs (plus de 1 000 utilisateurs avaient installé l’application en quelques jours) provoquant des pics d’utilisations de bande passante sur le serveur cible allant de 2Mb à 6Mb (entre 100 et 350 requêtes HTTP par second). Ils ont également analyser la provenance des requêtes (i.e. où se trouvent géographiquement l’utilisateur facebook) et on peut voir une répartition mondiale assez propre (ce qui risque de poser des problèmes pour la mise en place de contre mesures).

Ensuite, les auteurs ont voulu évaluer la puissance d’attaque d’une telle application dans la réalité et avec l’ensemble des facteurs qu’ils n’avaient pas voulu utiliser pour éviter de perturber le fonctionnement de Facebook et des utilisateurs. Par exemple, pour des applications ayant 1 millions d’utilisateurs ou plus, il faut s’attendre à des DDoS constants de 23Mbit/s soit 248Gb par jour. Ici, il ne faut pas voir uniquement la quantité de donnée mais le nombre de requêtes HTTP que va devoir résoudre le serveur cible et c’est cela qui risque d’être le point faible (et également celui de rupture).

Maintenant que le risque est prouvé (et pas uniquement limiter à des attaques de type DDoS, ces applications/malware facebook pourrait aussi être utiliser pour scanner des ordinateurs, propager des malwares, etc), les auteurs proposent plusieurs méthodes pour mettre en place des contre-mesures vis-à-vis de telles attaques. Leur première proposition pour se prémunir contre de tels attaques est tout simplement refusé tout traffic entrant ayant comme champ de référée du paquet HTTP facebook.com. Mais cela est relativement simplement contournable. L’une des autres méthodes est “tout simplement” que les créateurs de réseaux sociaux écrivent des API pour les applications qui soient propres et sécurisées et qu’ils vérifient la qualité et le risque des applications qu’ils hébergent.

Pour conclure, il est clair que ce type d’attaque pourrait arriver et que coupler avec une campagne virale, elle pourrait faire beaucoup de mal. Il est également possible d’imaginer une telle attaque ayant pour but de créer une sorte de botnet reposant sur des applications facebooks. Mais je ne trouve pas plus convaincant que ça ce type d’attaque pour des attaques massives car clairement pas assez puissants et temporaires (cela ne marche que le temps que l’utilisateur est sur la page de l’application) mais elle pourrait très bien servir pour de la distribution de malware et/ou de la vol de donnée personnel. Un vecteur d’attaque qu’il faudra surveiller vu l’importance que prennent les réseaux sociaux aussi bien dans la vie privée que dans l’entreprise.


Aug 28 2008

Attaquer l’hyperviseur Xen: Pénêtrer un système en restant invisible.

Tag: Failles de sécurité, conferenceArrouan @ 10:18 pm

Ce speach fait à la Black Hat USA 2008 par Rafal Wojtczuk (Invisible Things Lab) a pour but de présenter deux attaques sur l’hyperviseur Xen: une dans le code de Xen et une autre dans un domaine caché. La motivation de l’auteur est de dire que dans quelques années tout le monde aura un hyperviseur par défaut sur son ordinateur. Il n’a pas faux car, par exemple, Dell commence à fournir par défaut sur ses serveurs VMWare dans une ROM donc je peux imaginer dans quelques années que dans une puce, un hyperviseur soit disponible par défaut (il faut bien les utiliser tous ces coeurs). De plus, si il est possible d’attaquer ces hyperviseurs alors on se retrouve avec le même cas de figure qu’avec le virus Bluepill.

La première méthode d’attaque est de modifier depuis le système contenant l’hyperviseur (le Linux “maitre”) la mémoire contenant les informations à propos de Xen. Normalement un tel accés est protégé, mais en utilisant une technique similaire à celle présenté à SSTIC et permettant d’éxecuter du code via un iPod, l’auteur propose ici de s’attaquer au DMA et au carte réseau pour récupérer des valeurs en mémoire. La deuxième méthode utilise la possibilité de créer des domaines (et donc des machines virtuelles) qui peuvent espionner les autres et donc modifier leur données mémoires en temps réels.

Ces deux méthodes sont bien décrites et semblent tout à fait réalisable mais Xen n’est que peu utiliser actuellement. Des attaques de ce type sur VMWare seraient intéressante à voir également mais il n’empêche que les méthodes proposées ici utilisent  des concepts généric de la virtualisation est pourrai être utiliser sur d’autres hyperviseur.


Aug 23 2008

Faille OpenSSH chez RedHat …

Tag: Failles de sécuritéGarnett @ 10:22 pm

Après la faille OpenSSL chez Debian, la faille OpenSSH chez RedHat.
Un message sur la liste d’annonce CentOS relate une intrusion sur les serveurs RedHat. Cette intrusion a conduit au remplacement du paquet OpenSSH. Aucun détail sur la manière dont les pirates ont pénétrés les serveurs RedHat ni sur les “features” de leur openSSH modifié. Le communiqué sur le site de RedHat est extrêmement laconique.

Le RHN c’est cher mais c’est sécurisé : c’est en HTTPS.


Jul 24 2008

Exploit DNS in the wild !

Tag: Failles de sécuritéNicolas @ 2:33 pm

Vous avez sans doute entendu parler de la fameuse DNS, qui fait trembler tout l’Internet
depuis quelques jours.



Aprés le leak des détails de la vulnérabilité, HD Moore, le fondateur de metasploit, vient de mettre en ligne le tout premier exploit de la vulnérabilité.
(on remarque la réactivité de HD Moore, qui était déjà le premier à publier l’exploit Debian OpenSSL )


D’après ce post sur le blog zero day de ZDNet, l’attaque prend une minute ou deux pour empoisonner le cache d’un serveur DNS.

Comme le dis Dan Kaminsky sur son blog :

Patch. Today. Now.



PS: Mon tout premier post sur le blog :)




EDIT :

Un nouvel exploit à été publié, il permet de spoofer non plus un nom de machine, mais le serveur DNS en charge d’un domaine !

Bravo à Sid pour avoir trouvé la solution:
http://sid.rstack.org/blog/index.php/287-dns-encore-peut-etre-une-solution