Journal Abscence de communication autour du risque potentiel de corruption de cache DNS

Posté par .
Tags : aucun
0
31
juil.
2008
Cher journal,
Je suis étonné que personne n'est encore parlé sur LFR de la faille qui a été mis en évidence sur l'empoisonnement de cache DNS.

Alors pour ceux qui ne sont pas au courant petit rappel des faits:
- La version romanesque de LCI (09 juillet):
http://tf1.lci.fr/infos/high-tech/0,,3905327,00-internet-ech(...)

- Avis du certa Français mais c'est vrai pour les autres (08 juillet):
http://www.certa.ssi.gouv.fr/site/ [...] I-353.html

Avis du cert américain (09 juillet)
http://www.kb.cert.org/vuls/id/800113

Le blog du type qui a découvert la faille, il attendait de donner les détailles le 9 aout
http://www.doxpara.com/

mais des fuites, on ammenait à un exploit qui est diffusé sur Internet et réalisé par le framework de test (Metasploit)
http://www.zdnet.fr/actualites/inf [...] 458,00.htm

avec le code d'exploit (propre au framework):
http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Très bon article didactique du Certa sur le "Bon usage des DNS":
http://www.certa.ssi.gouv.fr/site/CERTA-2008-INF-002/CERTA-2(...)

Une news de securityfocus relatant des serveurs qui n'ont pas été mise à jour donc les utilisateurs sont impactés.
http://www.securityfocus.com/news/11529?ref=rss

Mais le point qui m'étonne le plus dans cet histoire et qu'il n'y a pas de communication officiel pour informer les risques possible.

Personnellement, j'essaie d'informer les utilisateurs de mon réseau avec un texte qui j'espère être didactique et clair ... sans trop de fautes d'orthographes:

Je vous déconseille l'accès aux sites de banque en ligne ou d'opérer des achats sur Internet à partir des postes partagés entre plusieurs utilisateurs.
Ce type d'opération doit être opérée à partir de poste qui ne sont dédiés uniquement à çà. Les antivirus et les mesures de sécurités mise en oeuvre ne suffisent pas à vous protéger d'activités mafieuses.
Je vous recommande d'adopter ce principe à votre domicile. L'accès au site sensible ne doit s'opérer que d'un poste dédié uniquement à çà.

Enfin un dernier point important à toujours contrôler quand vous consulter votre site de banque en ligne:

- Il faut que vous ayez le petit cadena fermé en bas de l'écran.

- Au moment de la connexion au site, on ne doit pas vous demander d'accepter un certificat émanant d'une autorité inconnu. Le contraire pourrait indiquer que le site de votre banque a été corrompu ou que votre communication a été detournée vers un serveur pirate.


Merci de me donner votre avis sur ce texte d'information.
  • # WOW!

    Posté par . Évalué à 9.

    • [^] # Re: WOW!

      Posté par . Évalué à 2.

    • [^] # Re: WOW!

      Posté par . Évalué à -1.

      Si j'avais souhaité annoncer une nouvelle , j'aurai proposé une dépeche :)

      Enfin , les quelques recherches google sur Linuxfr.org ne m'avais rien donné.
      http://www.google.fr/search?hl=fr&sa=X&oi=spell&(...)


      Et ce qui m'intéresse et plutôt de comment bien informé les utilisateurs des risques.
      • [^] # La forme et le fond...

        Posté par (page perso) . Évalué à 2.

        Ton document est très bien documenté, c'est dommage qu'il y ait autant de fautes. On est tenté de stopper la lecture :-(

        Je te conseille Antidote, de Druide, qui trouve la quasi totalité des fautes. C'est payant, ça tourne sous Linux (entre autres), tu achètes une licence pour 3 postes à 100 Euros, et c'est un excellent outil.
        J'en ai installé un sous XP et deux sous Linux.

        En plus il te fera remarquer que dans une phrase du type: "en tant qu'enseignant, j'ai enseigné..." serait mieux rédigée en remplaçant l'un des 2 mots (enseignant ou enseigné), et plein d'autres choses.

        Antidote sait trouver et propose de corriger l'erreur dans cette phrase:
        "Contenu de ces dernières informations, je change de décision..."

        Mode pinailleur:
        s/çà/ça
        s/Ce type d'opération doit être opérée /Ce type d'opération doit être opéré
        s/Les antivirus et les mesures de sécurités mise en oeuvre /Les antivirus et les mesures de sécurités mises en oeuvre
        s/quand vous consulter /quand vous consultez
        s/cadena/cadenas
        s/d'une autorité inconnu/d'une autorité inconnue

        Merci pour ton journal

        My father was a Brexit negotiator and his father before him

      • [^] # Re: WOW!

        Posté par . Évalué à 6.

        Et ce qui m'intéresse et plutôt de comment bien informé les utilisateurs des risques.

        Tu plaisantes ? C'est passé jusque sur les sites de tf1, LCI et Le Figaro. On en a parlé partout. Il y a eu une release massive de patchs par tellement de constructeurs que ça m'a même permis d'en découvrir de nouveau. C'est la vulnérabilité la plus overhypé que j'ai jamais vu. Elle est nominée au pwnie awards dans la catégorie most overhyped, cf. http://pwnie-awards.org/2008/awards.html#overhypedbug .

        On en a TROP parlé.
        • [^] # Re: WOW!

          Posté par . Évalué à 2.

          Faut dire aussi que je ne lie pas beaucoup les journaux grand public en ce moment :o).
          Je l'avais appris par les bulletins de sécurités du Certa.

          Je trouve par exemple l'article sur LCI assez mal foutu.

          Il présente le problème comme réglé alors qu'il ne l'était que partiellement au moment de la publication des patchs, il fallait encore que les admins appliquent ces patchs ce qui n'est pas gagné en période de vacances.

          Je connais pas beaucoup de personne qui lance la mise à jour dans leur cron.
          • [^] # Re: WOW!

            Posté par . Évalué à 8.

            Faut dire aussi que je ne lie pas beaucoup les journaux grand public en ce moment :o).

            Oué, moi non plus, je les dépose en vrac sur le perron des gens. En plus, ça économise de la ficelle.
          • [^] # Re: WOW!

            Posté par . Évalué à 3.

            Il présente le problème comme réglé alors qu'il ne l'était que partiellement au moment de la publication des patchs, il fallait encore que les admins appliquent ces patchs ce qui n'est pas gagné en période de vacances.

            Euh en général, une société ne laisse pas partir tous ses admins en même temps. Et si elle n'en a qu'un, il se tient en général au courant même en vacances car c'est une esclave.
            • [^] # Re: WOW!

              Posté par . Évalué à 1.

              C'est ma vie :,-( que tu décris là.
          • [^] # Re: WOW!

            Posté par . Évalué à 1.

            J'ai cité les media grand public pour montrer jusqu'où c'était monté mais cela va sans dire que ça a été largement commenté ailleurs également, en particulier dans le milieu de la sécurité. Il faut lire les blogs de matasano, Cédric Blancher ou Dino Dai Zovi. C'est d'ailleurs sur le blog de Matasano qu'on a eu droit à la fuite initiale sur les détails de la faille suite à une longue discussion sur la mailing-list Dailydave où Halvar Fluke avait trouvé les grandes lignes de la faille. Derrière Cédric Blancher a fait un travail assez remarquable de vérification. Et enfin, le résultat c'est que tous ces détails ont été utilisé pour créer les deux modules Metasploit qui permettent d'exploiter facilement la faille.

            Et effectivement comme ça a été dit, on a maintenant le droit à Dan Kaminsky qui s'amuse à scanner le monde entier pour vérifier si les DNS sont vulnérables (ou pour faire des jolis graphs à sa présentation Blackhat).

            Et puis entre nous vu la faille et vu la correction, il fallait vraiment 6 mois à tous les constructeurs pour préparer la sortie des patchs ? Et puis franchement, quel admin sérieux patch sans avoir les détails, ne serait-ce que pour en estimer la sévérité ou déterminer si son architecture est vraiment vulnérable ?

            Enfin bref, cet insupportable bordel aura moins servi à inciter l'ICANN à proposer DNSSEC sur les serveurs racines sous peu (ou en tous cas ça y ressemble, cf. http://www.icann.org/en/committees/security/sac030.htm ).
  • # tu n'en as pas assez avec ton syslog ?

    Posté par (page perso) . Évalué à 4.

    Jul 31 11:12:09 hst1 named[17959]: client 149.20.56.10#10053: query (cache) 'not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com/ANY/IN' denied
    Jul 31 11:16:34 hst1 named[17959]: client 149.20.56.10#10053: query (cache) 'not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com/ANY/IN' denied
    Jul 31 11:51:17 hst1 named[17959]: client 149.20.56.10#10053: query (cache) 'not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com/ANY/IN' denied
    Jul 31 11:55:44 hst1 named[17959]: client 149.20.56.10#10053: query (cache) 'not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com/ANY/IN' denied

    certaines heures, j'en ai plus d'une dizaine ...

    J'en ai ras le cul de Dan Kaminsky et de sa faille qu'il aille flooder d'autres machines ... ce n'est pas ce qui manque sur le net pourtant.

    Si tu trouves qu'il faut faire une dépeche ici, vas y ... mais je voterais très certainement contre car je sature de recevoir son flood toutes les heures en alerte.
    • [^] # Re: tu n'en as pas assez avec ton syslog ?

      Posté par . Évalué à 1.

      Tu as d'autre query( cache ) denied provenant d'une autre source que "not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com".

      Sinon çà ne serait pas plutôt tes utilisateurs de ton dns qui demande un test sur le site doxpara.com

      Tu as pensé à mettre en place une petite regle iptable pour filtrer ce qui vient "not-an-attack.dan-kaminsky.browse-deluvian.doxpara.com"
      • [^] # Re: tu n'en as pas assez avec ton syslog ?

        Posté par (page perso) . Évalué à 2.

        Les utilisateurs ont un bind local avec dedans :
        options { listen-on port 53 { 127.0.0.1; }; };
        Ca permet de filtrer pas mal ainsi :)

        Le serveur dont je parle, annonce quelques zones, donc je dois le laisser quand meme un peu accessible ...
  • # Darn fool proof

    Posté par . Évalué à -2.

    Un gogol qui fait de la banque en ligne sans comprendre les limites bien connues du protocole DNS ne mérite que ce qui lui arrive. Désolé mais à un moment il faut arrêter de poser des postulats contradictoires entre eux pour inventer des "problèmes de sécu".

    Le "petit cadenas"...... par exemple.....
    • [^] # Re: Darn fool proof

      Posté par . Évalué à 2.

      Un banquier de la société général m'a sortie pendant mes vacances.

      "Ordre de la direction , je ne peux pas vous sortir un état de vos comptes mais par contre vous pouvez toujours aller dans un cyber café pour consulter vos comptes"

      Je pense les principes de sécurités élémentaires ,il ne faut pas hésiter les rappeler et effectivement ne pas se contenter du petit cadenas.
  • # Quel est le rapport entre ton avertissement et la faille ?

    Posté par (page perso) . Évalué à 5.

    Je vous déconseille l'accès aux sites de banque en ligne ou d'opérer des achats sur Internet à partir des postes partagés entre plusieurs utilisateurs. [...]

    Quand on a pas les droits root il y a toujours des risques de key logger. C'est vrai. C'est un conseil général.

    Par contre, je vois pas le rapport avec la faille en question.
    1) Si le DNS est corrompu, le certificat SSL ne sera pas signé.
    2) Même sur un ordinateur dédié le DNS peut être corrumpu.
    • [^] # Re: Quel est le rapport entre ton avertissement et la faille ?

      Posté par . Évalué à 1.

      >Par contre, je vois pas le rapport avec la faille en question.
      C'est exacte.

      En fait, j'ai publié ce texte sur l'intranet de ma clinique.

      Mon objectif n'est pas juste de les informer sur la faille DNS mais de les avertir sur les possibilités de détournement de leur communication.

      Le début du texte concerne les postes qui sont utilisés par des services (donc on peut dire presque en libre service). Je voie régulièrement des accès à des sites de banques en lignes ou à paypal.

      Enfin, je tenais rappeler surtout les principes de sécurités élémentaires vérifier le cadenas mais aussi la validité du certificat.

      Les attaques du types "Man In The Middle" ne sont pas uniquement réalisé via un dns cache poisonning.

      Sinon concernant les keylogger, tu n'as pas besoins d'être ROOT sur un Windows pour récupérer les frappe clavier un compte utilisateur simple suffit.

      Sous Linux en passant par X Windows , je sais que tu es obligé d'être Root.
      Mais je pense qu'il faudrait étudier la question en prenant en compte tout ce qui se rajoute sur X Windows genre le Windows Manager ou les Tookit si il n'y a pas possibilité de détourner la frappe clavier via quelques préferences bien placé.

      D'ailleurs en plus des keyloggers, il faut à mon avis envisager des programmes qui ferait des captures d'écrans par exemple sur un clique de souris.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.