Faille DNS : on a sauvé l'Internet !

[Setsuna]

Révélée depuis quelques heures, une faille qui touche la conception même du protocole DNS (Domain Name System) aurait pu causer d’importants dommages et mettre en péril la stabilité de l’Internet tout entier. Rien que ça.

Des DNS empoisonnés

Dan Kaminsky, responsable des tests d’intrusion chez IOActive, est tombé sur cette faille il y a 6 mois, presque par hasard. Elle permettrait de modifier les données du cache du serveur (ou « cache poisoning ») et donc de rediriger les internautes vers une toute autre destination que celle voulue et ce bien entendu sans que l’internaute ne se rende compte de rien. Les risques pour les sites sensibles, tels les sites bancaires, sont donc bien réels.

Si la dangerosité de la faille est exceptionnelle, la réaction des différents acteurs du marché l’est tout autant. En effet, de grandes entreprises comme Microsoft, Cisco, Red Hat ou encore Sun Microsystems, discrètement averties par Dan Kaminsky, ont simultanément publié un patch pour régler ce problème sur leurs plateformes respectives. Il n’y aurait toutefois aucune raison de paniquer, aucun exploit n’étant à l’heure actuelle disponible. Les détails concernant cette faille ne devraient être révélées par Dan Kaminski lui-même qu’à l’occasion de la prochaine conférence Black Hat, le 6 août. Reste à espérer que d’ici là, les serveurs DNS de votre FAI ou de votre entreprise seront mis à jour.

Source: http://www.presence-pc.com/actualite/Fa ... net-30355/

[Nounours]

Les failles ont déjà étaient corrigés. Les annonces officiel ne sont connu que lorsque les failles sont corrigés donc pas de panique. Les DNS des grandes sociétés ou FAI sont déjà a jour!

Un truc qui peut aussi nous faire mal, j'ai lu dans un article du magazine MISC http://www.miscmag.com/fr/ que les fichiers PDF peuvent etre chargé de code malicieux. Le format pdf et le format le plus utilisé au monde par internet car trés sécurisé mais depuis quelques temps ont a trouvé des failles qui permettaient d'ajouter du code a un fichier PDF.

A première les anti-virus (aprés mise a jour) seront capable d'identifier ces codes. Espérons que les mise a jour vont arrivé rapidement car sinon ca va faire mal.

[Captain BiDiBu]

Dans le cadre de mon travail où il m'arrive de faire de la veille technologique, j'ai fait ce matin une alerte à nos clients, je la fais suivre, ca montrera à certains que je bosse parfois...

Nous vous informons de la diffusion par le CERT, le 08/07/08 d'une alerte sur une vulnérabilité de type "DNS cache poisoning".

Concrètement une vulnérabilité de ce type permet de faire soit du déni de service soit du phishing en redirigeant les flux d'un site vers un site malicieux apparemment semblable en tout point.

Il y a donc un intérêt financier évident à effectuer ce type d'attaque.

Un nouveau type d'exploit, non publié actuellement, permet de fortement simplifier ce type d'attaque. Celui-ci sera probablement rendu public à l'occasion de la conférence DEFCON qui a lieu du 8 au 10 aout 2008.
Cependant, il n'est pas exclu que l'exploit ne puisse être reconstitué avant cette date sur la base de la vulnérabilité.

Afin de se protéger de ce type d'attaque, l'état de l'art jusqu'à présent consistait à randomiser le TXID (transaction id) des requêtes DNS. Les nouvelles recommandations à compter de ce jour sont de randomiser de plus le port source des requêtes DNS.

Pour cela, il faut à la fois que les briques logicielles effectuant les requêtes DNS randomisent le port source mais aussi que les équipements effectuant de la translation d'adresse en sortie ne dérandomisent pas les flux (car la translation d'adresse affecte l'allocation de port source).

Cette vulnérabilité peut être testée très simplement à partir d'un navigateur web en cliquant sur "check my dns" sur le site http://www.doxpara.com/ . Il s'agit du site de la personne ayant remonté le problème.

Voici ce que recommande le CERT comme solutions :

================


Apply a patch from your vendor

Patches have been released by a number of vendors to implement source port randomization in the nameserver. This change significantly reduces the practicality of cache poisoning attacks. Please see the Systems Affected section of Vulnerability Note VU#800113 for additional details for specific vendors.

As mentioned above, stub resolvers are also vulnerable to these attacks. Stub resolvers that will issue queries in response to attacker behavior, and may receive packets from an attacker, should be patched. System administrators should be alert for patches to client operating systems that implement port randomization in the stub resolver.


Workarounds

*Restrict access*
Administrators, particularly those who are unable to apply a patch, can limit exposure to this vulnerability by restricting sources that can ask for recursion. Note that restricting access will still allow attackers with access to authorized hosts to exploit this vulnerability.

*Filter traffic at network perimeters*
Because the ability to spoof IP addresses is necessary to conduct these attacks, administrators should take care to filter spoofed addresses at the network perimeter. IETF Request for Comments (RFC) documents RFC 2827, RFC3704 and RFC 3013 describe best current practices (BCPs) for implementing this defense. It is important to understand your network's configuration and service requirements before deciding what changes are appropriate.

*Run a local DNS cache*
In lieu of strong port randomization characteristics in a stub resolver, administrators can protect their systems by using local caching full-service resolvers, both on the client systems and on servers that are topologically close on the network to the client systems. This should be done in conjunction with the network segmentation and filtering strategies mentioned above.

*Disable recursion*
Disable recursion on any nameserver responding to DNS requests made by untrusted systems.

*Implement source port randomization*
Vendors that implement DNS software are encouraged to review IETF Internet Draft, "Measures for making DNS more resilient against forged answers <http://tools.ietf.org/html/draft-ietf-d ... resilience>," for additional information about implementing mitigations in their products. This document is a work in progress and may change prior to its publication as an RFC, if it is approved.


================

Pour plus d'informations sur cette vulnérabilité, veuillez consulter directement l'alerte sur le site du CERT sur le lien ci-dessous :

http://www.us-cert.gov/cas/techalerts/TA08-190B.html