Journal Cisco voit rouge.

Posté par  (site web personnel) .
Étiquettes : aucune
0
28
juil.
2005
Un expert indépendant en sécurité nommé Michael Lynn, a fait hier une présentation au BlackHat de Las Vegas (malgré la demande de Cisco d'y renoncer), sur les failles de IOS et la façon de compromettre un routeur de la marque en y exécutant n'importe quel code.

Cisco qui avait tout fait pour éviter que cette présentation n'ait lieu, a maintenant décidé d'engager des poursuites contre lui. [1]

De précédentes informations [2] faisaient état du danger potentiel de voir un jour des vers sur les routeurs de la marque. Il semble pourtant qu'en quelques jours la menace se soit soudainement précisée pour que Michael Lynn décide de tout dévoiler publiquement à 2 heures seulement de sa présentation, et ce malgré les menaces à peine voilées de son ancien employeur [3] et de Cisco.

D'après les dires de Michael Lynn, n'importe quel buffer overflow trouvé dans IOS pourrait permettre l'exécution de code et par conséquent infecter de nombreux routeurs s'ils ne sont pas correctement patchés.

Heureusement les script-kiddies semblent exclus d'office, d'autant que la présentation faite n'a pas été mise en ligne sur le site de Blackhat. [4]
Il est néanmoins recommandé aux admins réseaux de garder un oeil attentif sur leurs routeurs.


[1] http://www.securityfocus.com/news/11259(...)
[2] http://www.itworldcanada.com/a/ComputerWorld/6c12c0c8-c6e9-42ef-827(...)
[3] http://www.iss.net/(...)
[4] http://www.blackhat.com/html/bh-media-archives/bh-multi-media-archi(...)

  • # Bugs == IP

    Posté par  (site web personnel) . Évalué à 9.

    J'adore voire mettre IP à toutes les sauces.

    All our bugs belong to us.

    En gros, nos bugs nous apparettiennent vous n'avez pas à en partager l'existence. Terrifiant.

    "La première sécurité est la liberté"

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Bugs == IP

        Posté par  . Évalué à 10.

        Les "terroristes" ont bon dos... Quand une attaque aura lieu sur les matériels des noeuds du Net, toutes la presse nous rabattera les oreilles sur les pirates, et non sur les sociétés qui produisent des équipements défectueux...

      • [^] # Re: Bugs == IP

        Posté par  . Évalué à 3.

        Attention, il s'agissait d'une autre histoire !

        cf. http://linuxfr.org/2005/07/14/19309.html(...)

        Cisco les multiplie ces derniers temps ...

    • [^] # Re: Bugs == IP

      Posté par  (site web personnel) . Évalué à 6.

      > All our bugs belong to us.

      All our bugs are belong to us ! Take off every ZIG ! (Zero Immunity Gateway, manifestement)

      • [^] # Se battre contre les boites noires ( le droit au bug )

        Posté par  (site web personnel) . Évalué à 5.

        Personnellement j'estime qu'un linux bien géré ( et avec un gernel grsec/pax ;) fera toujours mieux qu'une boite noire qui vous expose aux failles, aux mensonges et aux backdoors du fabricant qui ne vous donne pas le code ( et le droit au bug ) du produit que vous achetez.

        "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

        • [^] # Re: Se battre contre les boites noires ( le droit au bug )

          Posté par  (site web personnel) . Évalué à 2.

          Les équipements foundry networks sont bien meilleurs au niveau de la sécuritée, parfois plus instables que leur concurent direct mais il y a eu peu de failles reportés à ce jour.
          Je travail régulièrement avec ce genre de routeurs / switch (layer 2-3) et j'y met bien plus de confiance que dans du cisco ou un pc faisant office de routeur :)

          Après chacun ses goûts ;o)

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 8.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Se battre contre les boites noires ( le droit au bug )

              Posté par  (site web personnel) . Évalué à 3.

              C'est exactement ca ( la backdoor de nombreux produits CISCO avec un default user/password non documenté m'a fait quitter a jamais l'envie d'utiliser une boite noire ).

              Un linux fait aussi bien, et ne me ment pas, il me laisse voir toutes les logs, et je peux meme lire le code de postfix, iptables ou autre ;)

              La confiance ca se gagne.

              Pour un logiciel, la confiance ne peut se gagner qu'en offrant son code source aux utilisateurs ( et en leur laissant le droit de compiler ce code eux meme ), sans cela la confiance n'est qu'illusion publicitaire.

              "You have enemies? Good. That means you've stood up for something in your life." Winston Churchill

              • [^] # Re: Se battre contre les boites noires ( le droit au bug )

                Posté par  . Évalué à 1.

                D'un autre côté, qui a vérifié ligne par ligne que le code SELinux n'avait pas de backdoor ? Ou que tout est bien loggé ?

                Pour moi la première faille d'un système informatique est la confiance de l'homme dans la machine, logiciel inclu.

                La différence entre un logiciel opensource et un logiciel closedsource, c'est que la lecture du premier est plus aisée que la lecture du second. Mais cela n'implique pas que la tâche soit à échelle humaine.

                Le tout est de savoir trouver la limite entre paranoïa, laxisme et ignorance.

          • [^] # Re: Se battre contre les boites noires ( le droit au bug )

            Posté par  (site web personnel) . Évalué à 9.

            L.a question est aussi de savoir le niveau de confiance que tu peux mettre dans un équipement quand la réaction première du fabricant est de faire taire toutes annonces de failles.

            "La première sécurité est la liberté"

          • [^] # Re: Se battre contre les boites noires ( le droit au bug )

            Posté par  . Évalué à 1.

            Comment as-tu évalué leur niveau de sécurité ?
            Depuis quand le nombre de failles reportées est-il représensatif du niveau de sécurité d'un équipement ?

  • # DMCA, EUCD, toussa...

    Posté par  . Évalué à 9.

    au BlackHat de Las Vegas

    Il faut être un peu fou pour continuer à organiser des conférences sur la sécurité aux Etats Unis d'USA avec le DMCA et tout et tout. Je croyais que toutes les manifestations de ce genre avaient été déplacées dans d'autres pays plus civilisés...

    • [^] # Re: DMCA, EUCD, toussa...

      Posté par  (site web personnel) . Évalué à 7.

      Las Vegas est une des villes les moins chères des US. Comme tout tourne autour des casinos, les chambres d'hotels et les restaurants sont beaucoup moins chers qu'ailleurs. Par conséquent il est assez facile d'organiser des rencontres là-bas. Je me trompe peut-être mais j'imagine que c'est là raison pour laquelle Las Vegas a été choisie.

      Maintenant, Michael Lynn a précisé en plaisantant qu'il serait peut-être à Guantanamo la semaine prochaine. En tous cas il est sévèrement burné le gars.

    • [^] # Re: DMCA, EUCD, toussa...

      Posté par  . Évalué à 4.

      ya What The Hack et la conf XFocus. Mais Las Vegas est devenu une institution avec le Black Hat et le Defcon. Et puis ya plein d'autres confs sécurité aux US.

  • # il a marabouté cisco

    Posté par  . Évalué à -6.

    Michael Lynn ous protège des envoûtements ennemis, traite l'impuissance sexuelle, chance aux jeux, etc ... . non ça ne vaut pas le coût de vous décourager, car il n'y a pas de problème sans solution, prenez contact avec Michael.
    Retour de l'être aimé dans la même semaine.
    La malchance vous poursuit, votre problème est grave, désespérés un coup de téléphone suffit pour le résoudre.
    conclusion:
    Regardez bien ce qu'il a en main, c'est une preuve fatale.
    cisco sont assez stupides

  • # Compléments et correction

    Posté par  . Évalué à 10.

    Michael Lynn n'est pas un expert indépendant, mais un ex-chercheur en sécurité chez ISS (il a démissionné suite/pendant cette affaire blackhat).

    La présentation parlait essentiellement de heap corruption et de comment manipuler et exploiter le heap. Il semblerait qu'il ait étudié l'implémentation d'IOS lors d'un audit de code source demandé par Cisco à ISS (ce qui implique un NDA).

    Il est important de noter que Michael Lynn n'a pas fourni de 0day, d'exploit ou même de shellcode (d'après des gens ayant assisté à la conférence, je n'y étais pas personnellement présent). Les fruits de recherches sur l'exploitation de vuln IOS étaient déjà dispo.

    Les DoS IOS publiées cette année seraient potentiellement exploitables en utilisant les techniques présentées par Lynn.

    Un admin réseau doit toujours garder un oeil attentif sur ses routeurs (c'est quand même le point d'entrée souvent ou bien un point important d'interconnexion).

    Il y a des alternatives à Cisco comme Juniper qui marchent très bien (faut arrêter de s'obséder avec Cisco).

    • [^] # Re: Compléments et correction

      Posté par  (site web personnel) . Évalué à 3.

      Il y a aussi Quagga (aka zebra) sur un bon vieux bsd, (donc avec une couche réseau 'qui marche') ce le fait. Ca marche aussi sous linux hein ... mais moins bien.

      Non ca n'est pas un troll, juste un retour d'expérience. Linux ayant tendance à causer l'arp de manière exotique, sans compter la table de routage que le noyau plombe régulièrement ...

      http://www.fr.quagga.net/(...)

      • [^] # Re: Compléments et correction

        Posté par  . Évalué à 2.

        Pour Quagga je suis d'accord avec toi et suis un des premiers à recommander du libre quand il est utilisable et efficace. Mais lorsque tu prends du Cisco c'est en général que tu dois pouvoir tenir une charge importante (donc tu ne te limites pas aux besoins fonctionnels). La partie hardware est essentielle dans ce type d'équipement pour avoir le traitement le plus rapide possible et répondre aux besoins de performances.

        Peux-tu détailler (liens, références, ...) "Linux ayant tendance à causer l'arp de manière exotique" et "la table de routage que le noyau plombe régulièrement", ça m'interresse.

        grsecurity/PaX n'existe pas sous *BSD :p

        • [^] # Re: Compléments et correction

          Posté par  (site web personnel) . Évalué à 5.

          - Linux répond en arp sur toutes les interfaces, au lieu de ne répondre que sur l'interface concernée par l'adresse ip. C'est un vieux troll, débat par excellence dans l'équipe de couche ip du noyau linux, mais il reste (à mon avis) que la mauvaise solution a été retenue ...

          - Chez Gitoyen, opérateur alternatif monté il y a 4 ans, on a eu des routeurs linux + zebra qui avaient des tables de routage qui se mettaient à ne plus router certains paquets alors que la table (ip route list) nous affichait bien les routes correspondantes, et inversement (des routes ayant été enlevées par zebra ou par ip route del, mais que le linux routait toujours) !

          Depuis on a mis certains routeurs sous bsd pour ceux de bordure au moins (bgp) avec quagga, et on a gardé linux pour ceux ayant des routes plus exotiques mais moins nombreuses dans le routage interne ibgp/ospf/vrrp.

          Sinon, pour ce qui est de tenir la charge, un linux sait très bien se débrouiller avec des centaines de milliers de paquets ip par seconde tant que tu as les cartes réseaux, cartes mères, cpu et ram adhoc. Et cela reste bien moins cher que du cisco à performance équivalente bien sur !

          Sinon, il reste le monde des switchs dans lequel on a pour l'instant trouvé aucune alternative libre crédible...

          • [^] # Re: Compléments et correction

            Posté par  (site web personnel) . Évalué à 1.

            > Chez Gitoyen, opérateur alternatif monté il y a 4 ans, on a eu des routeurs linux + zebra [...]

            Ah c'était donc ça les pb de DNS chez Gandi? ;)

          • [^] # Re: Compléments et correction

            Posté par  . Évalué à 1.

            Ok, merci pour ta réponse, c'est toujours interressant d'avoir des retours d'expérience.

            Pour les réponses ARP je vais vérifier, ça me semble inutile (limite idiot) de répondre sur toutes les interfaces (je vais chercher des discussions dans le ml kernel, mais si tu as déjà des références sous la main je suis preneur).

            J'ai tout à fait conscience qu'un linux sait traiter un trafic important et que la limite avant d'être soft se produit souvent côté hard. Il existe beaucoup de preuves concrètes avec l'utilisation de plate-forme linux chez des gros opérateurs ou bien dans des appliances. Je citerais l'exemple d'Arkoon (http://open-source.arkoon.net)(...) côté firewall. Par contre pour ce qui est des routeurs c'est plus rare (il y a souvent une raison juridique à cela je pense, c'est à dire une grosse sur qui tapper en cas de problème et puis le discours marketing aussi).

            Disons qu'il faut un couple hard/os qui offre les performances requises et la c'est beaucoup plus dur avec un noyau linux vanilla. Pour le routage et la commutation je pense que des processeurs spécifiques sont utiles (contrairement aux firewall ou ca reste quand même très marketing/hype). Donc dans ce cas il faut du hard et du dev dédié (ça n'empêche pas de le faire en libre mais c'est plus fastidieux que du générique).

            Ce qui me fait plaisir avec les travaux sur l'exploitation de vulns dans IOS c'est qu'on sort du modèle appliance == secure, car un des arguments contre l'utilisation d'os libre pour des routeurs ou des firewall est d'avoir une plate-forme difficile à compromettre.

            • [^] # Re: Compléments et correction

              Posté par  (site web personnel) . Évalué à 7.

              > Pour les réponses ARP je vais vérifier, ça me semble inutile (limite idiot) de répondre sur toutes les interfaces

              C'(est effectivement le comportement par défaut de Linux, mais ça se configure dans /proc avec :

              echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter

              Voir /usr/src/linux/Documentation/networking/ip-sysctl.txt

        • [^] # Re: Compléments et correction

          Posté par  (site web personnel) . Évalué à 3.

          > grsecurity/PaX n'existe pas sous *BSD :p
          D'après la description de PaX qui est faite sur Wikipédia, ces fonctionalités sont implémentées dans OpenBSD. Pour grsecurity, je ne sais pas si tout y est mais il y a des chances que l'essentiel soit implémenté aussi.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: Compléments et correction

          Posté par  (site web personnel) . Évalué à 3.

          > grsecurity/PaX n'existe pas sous *BSD :p

          Oh le beau Troll!

          Allez je saute dessus: c'est vrai, mais ce qu'il y a dans OpenBSD est mieux :o)

        • [^] # Re: Compléments et correction

          Posté par  . Évalué à 2.

          Mais lorsque tu prends du Cisco c'est en général que tu dois pouvoir tenir une charge importante

          Oui et non, Cisco vend de plus en plus de petits matériels (routeurs SOHO, passerelles adsl, petits firewalls, petites passerelles ipsec, access points ...).
          Dans ces condition le logiciel libre excelle par sa souplesse et peu aisément remplacer Cisco.

          grsecurity/PaX n'existe pas sous *BSD :p

          C'est un troll ou quoi ?
          OpenBSD possède les mêmes protections mémoires que fournis PaX (et d'autres aussi), et de plus, est compilé avec un gcc+propolice (aka spp, "smashing stack protection"). Parfois j'aimerai que les linuxiens regardent un peu ce qui se fait autour d'eux ... (bon, les windowsiens encore plus, hein ;).

          Et puisqu'on parle de remplacer cisco, OpenBSD intègre maintenant par default des serveur isakmp, bgp et ospf très sécurisés (developpés par les mêmes gars qui ont fait le firewall pf).

          • [^] # Re: Compléments et correction

            Posté par  . Évalué à 1.

            Je suis d'accord qu'en dehors des besoins de très forte charge on peut utiliser du libre et je l'encourage.

            Jette un coup d'oeil à cette présentation : http://www.grsecurity.net/PaX-presentation.ppt(...)

            Et puis au code aussi ;).

            Il y a une différence entre ce qui est annoncé et ce qui est réellement implémenté. paxtest est un outil sympa pour voir rapidement qu'elles sont les protections implémenté (dans ces types de technos i.e. pax/W^X/execShield), il a été porté sur openbsd. Pour la compilation avec l'option ssp tu la retrouves aussi chez gentoo-hardened par exemple.

            Quelles sont les implémentations de rbac sous openbsd (j'avoue ne pas avoir touché un openbsd depuis un moment) ?

    • [^] # Re: Compléments et correction

      Posté par  . Évalué à 3.

      Pour l'audit des sources d'IOS, j'émets davantage de réserve (vu que j'ai lu un démenti d'un membre d'ISS). Par contre, Michael Lynn avait l'air tenu par un NDA entre ISS et Cisco.

      Aujoud'hui Lynn s'est vu interdir de reparler et retrailler sur l'exploitation d'IOS.

      Pour bien suivre cette affaire :
      http://blogs.washingtonpost.com/securityfix/(...)

  • # Slides

    Posté par  (site web personnel) . Évalué à 5.

    Pour ceux que ca intéresse, le lien vers les slides qu'il a présenté.

    http://www.boingboing.net/2005/07/29/michael_lynns_contro.html(...)

Suivre le flux des commentaires

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