Backdoors chez monkey.org (dsniff et fragroute)

Posté par  . Modéré par Benoît Sibaud.
Étiquettes : aucune
0
31
mai
2002
Sécurité
Sur le même principe qu'irssi, les sources de dsniff (des utilitaires pour sniffer un réseau) et fragroute (l'outil qui a fait grand bruit récemment, capable, dans certains cas, de bluffer snort) ont été modifiés.
Le serveur de monkey.org, qui héberge l'auteur de ces deux logiciels, a été visité, via, semble-t-il, un trou dans epic4-pre2.511 qui a permis un accès au compte root.
Les fichiers incriminés ont été modifié le 17/05 et restaurés le 24/05.
Voici les sommes de contrôle MD5 des sources valides :

MD5 (dsniff-2.3.tar.gz) = 183e336a45e38013f3af840bddec44b4
MD5 (fragroute-1.2.tar.gz) = 7e4de763fae35a50e871bdcd1ac8e23a
MD5 (fragrouter-1.6.tar.gz) = 73fdc73f8da0b41b995420ded00533cc

L'étendue des dégats semble « limitée » :

"of the 1951 hosts that successfully downloaded one of the backdoored
tarballs, 992 of them were Windows machines and 193 were automated
ports downloads for the *BSD dsniff or fragrouter ports, leaving 746
Linux (and a few Solaris and MacOS) hosts potentially vulnerable, and
20 FreeBSD and OpenBSD hosts."

En espérant que çà ne devienne pas une mode...

Note du modérateur : je rajoute l'enfilade de Bugtraq pour confirmation

Aller plus loin

  • # epic

    Posté par  . Évalué à 10.

    Epic .. d'après mon apt, epic est un client irc ..

    Pour devenir root avec un trou comme ca, il faut, ou exploiter deux bugs a la suite, soit que epic tourne en root ..

    Mais alors .. ils n'ont pas pigé que L'IRC EN ROOT, C'EST MAL ?

    Mes deux cents.

    • [^] # Re: epic

      Posté par  . Évalué à 10.

      espionner la frappe sur un shell user où est exécutée la commande su, ça doit marcher non ?

    • [^] # Re: epic

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

      C'est mieux de lire l'enfilade Bugtraq (c'est pas pour rien que je l'ai rajoutée)
      http://online.securityfocus.com/archive/1/274927/2002-05-28/2002-06(...)

      « monkey.org was compromised on May 14th, via an epic4-pre2.511 client-side hole which produced a shell to one of the local admin's accounts. this was later used to reattach to one of his screen sessions, which apparently had a root window open (su very bad!). »
      Donc faille dans le client IRC pour obtenir un accès à un shell d'un utilisateur local, qui lui avait un accès root (je suis pas sûr de comprendre s'il avait une fenêtre root quelque part, ou un session du programme screen avec un shell root dedans)

      • [^] # Re: epic

        Posté par  . Évalué à 10.

        L'idée c'est qu'en ayant accès à un shell avec les crédits d'un admin local, il a été possible de lire le socket de screen possédé par cet utilisateur et donc de pirater une session screen dans laquelle un shell en root était ouvert.

        Ouala, ouala.
        su c'est Mal®, utilisez sudo !

        • [^] # Re: epic

          Posté par  . Évalué à 10.

          sudo -s a le meme effet, mais c'est vrai que sudo c'est mieux(tm).. Deja faut pas taper le pass root a gogo ..

          Enfin bon, cemme je l'ai compris la .. l'admin a laissé use session root loggée ds un screen .. et ca c'est mal(tm) .. on laisse jamais de session root loggée ..

          Ciao!

  • # A propos de l'habitude.

    Posté par  . Évalué à 10.

    Ca fait 2 exploits sans trop de traces dans les évènements récents...

    Serions nous en train de voire éclore une "nouvelle voie" vers le compte root ?

    Ca arrive parfois, mais là tout de suite 2 d'un coup à la une de linuxfr, ca me fait froid dans le dos.

    Finalement, j'avais dans l'idée de me refaire un script iptables from scratch, ce WE, avec une refouillée de snort. Allez, je m'y mets...

  • # Choix des langages...

    Posté par  . Évalué à -3.

    epic4 est un programme écrit en langage C. Or, comme chacun le sait, il est très facile d'écrire des applications non-sécures en C, et à moins qu'epic4 ait besoin d'un maximum de vitesse, je ne voit pas pourquoi il est écrit en C. Il y a belle lurette que je dit que la plupart des application dans le user-land devraient autant que possible être écrites dans des langages sécure, de haut-niveau (tel que Python, O'Caml, Ada, etc.). Comme ces langages sont plus sécuritaires, peut-être qu'il y aurait moins de trous de sécurité que des pirates malicieux peuvent exploiter. C'est mon 2¢ canadien.

  • # Coincidence

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

    Quelle concidence, m'intéressant à la sécurité, je me suis dis, c'est bizzare que personne modifie des sources des projets hébérgé sur des serveur web. Je pensé surtout au systeme debian avec son systeme de paquet. Pour peux que qqn modifie un binaire de paquetage. et quasiment tout le monde chope un backdoor.

    • [^] # Re: Coincidence

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

      Sauf que le fichier dsc qui contient les sommes MD5 est signé par GPG.

      -----BEGIN PGP SIGNED MESSAGE-----

      Format: 1.0
      Source: net-tools
      Version: 1.60-1
      Binary: net-tools
      Maintainer: Bernd Eckenfels <ecki@debian.org>
      Architecture: any
      Standards-Version: 3.1.1
      Build-Depends: debhelper, gettext
      Files:
      ecaf37acb5b5daff4bdda77785fd916d 265441 net-tools_1.60.orig.tar.gz
      7e2ebe2f9412d1d3e3340d3bcb4d36f1 3245 net-tools_1.60-1.diff.gz

      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.0.4 (GNU/Linux)
      Comment: For info see http://www.gnupg.org(...)

      iQB1AwUBOto/0/ktgj2/6tLNAQEdwAMAmyPsCfm3K/KZXYaVXFVdxY4K/XuYQHF/
      MAw59ozfU7CQvGLY2t5w63plkHoIcCHtYPkBrgVta1SX1hCtFR+nIRW/Gjx0PE2P
      UayO27JZ38szlD80gEd9zUZ2xWl5nJCL
      =AqFr
      -----END PGP SIGNATURE-----

      D'un autre côté, le contrôle complet des signatures n'a pas encore utilisé en standard par Debian (ne sera pas par défaut dans la Woody, mais dans la prochaine version).

Suivre le flux des commentaires

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