14% des sites de e-commerce français sont vulnérables au vers 'Slapper'

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
17
sept.
2002
Sécurité
Une étude réalisée du 14 au 16 septembre 2002 sur l'ensemble du domaine ".fr", a établi que, sur un échantillon représentatif de 134.149 sites Web, 13.9% des serveurs Web Sécurisés sont vulnérables à la faille de sécurité "OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow" découverte le 30 juillet 2002.

Celle-ci est particulièrement sérieuse, car elle est actuellement exploitée par le vers Linux.Slapper.Worm.

14000 machines ont déjà été confirmées comme étant infectées.

NdM: laurentn rajoute :
« La faille se situe dans le module OpenSSL d'Apache qui permet les transactions cryptées sur le Web. Le ver reconnaît ses proies en envoyant une requête GET sur le port 80 du serveur pour reconnaître le système Apache. Une fois Apache trouvé, le ver va essayer de se connecter au port 443 du serveur, pour lui envoyer son code. Ce dernier est ensuite compilé avec GCC et les binaires sont exécutés. Le fichier est alors placé dans "/tmp". »

Aller plus loin

  • # Question

    Posté par  . Évalué à 10.

    Quelles sont les versions d'OpenSSL concernées ? StrongHoldNet recommande de mettre à jour vers la 0.9.6g. D'un autre côté la dernière alerte de sécurité mentionnée sur http://www.openssl.org/news/ parle d'une vulnérabilité sur une version "antérieure à la 0.9.6e". Ce ver est-il "simplement" une exploitation de la faille susdite (et patchée depuis longtemps par les admins responsables ;-)) ?

    • [^] # Re: Question

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

      D'après http://www.cert.org/advisories/CA-2002-27.html , toutes les versions d'OpenSSL antérieures à la 0.9.6e sont concernées. Ca rejoint donc ce qui est dit sur www.openssl.org.

      • [^] # Re: Question ceux avec chroot ou iptables non affectés

        Posté par  . Évalué à 10.

        Il s'agit en effet d'un bug Openssl corrigé il y a deja plusieurs mois par les mises-à-jour des distribs.
        Et après lecture du rapport de symantec,
        http://securityresponse.symantec.com/avcenter/venc/data/linux.slapp(...)
        je crois utile d'ajouter que le worm est inefficace contre ceux qui utilisent apache avec chroot (le worm n'a alors plus accès à gcc) ou avec de simples chmod pour interdire l'accès par l'utilisateur "apache" aux répertoires et fichiers du système non utilisés par apache.
        Enfin, une utilisation stricte de iptable -m owner empeche le worm d'ouvrir d'autres ports TCP et UDP, le rendant incapable d'infecter d'autres systèmes et de recevoir des commandes à distance.

        Pour les paranos on peut par exemple conseiller:
        http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-serv(...)
        ajoutons à ce qui est écrit dans le lien ci-dessus que makejail est dans debian unstable et peut sans probleme s'utiliser avec woody 3.0 (stable).

      • [^] # les versions inférieures MAIS patchés par les distribs ne sont pas affectées !

        Posté par  . Évalué à 6.

        Voici un petit rappel nécessaire à chaque fois qu'un tel probleme se médiatise (enseigner c'est répéter :) )

        De nombreuses distribs, pour des raisons de stabilité, ne mettent pas à jour un paquet concerné par un bug grave ou une faille de sécurité vers la version supérieure publiée par l'auteur original du programme.
        Elles préfèrent patcher leur version stable actuelle (c'est un "bugfix backport" dans leur jargon).

        Ainsi le paquet stable actuel 0.9.6c-2.woody.1 issu de security.debian.org n'est pas affecté (on peut voir qu'il a été patché plusieurs fois comme en témoigne le -2) et ce le 30 juillet 2002:
        http://www.debian.org/security/2002/dsa-136(...)

    • [^] # Re: Question

      Posté par  . Évalué à 10.

      C est bien toutes les versions en dessous de la 0.9.6e. Un article de TheRegister dessus : http://www.theregister.co.uk/content/55/27134.html

  • # Ou sont les admins?

    Posté par  . Évalué à 10.

    Je ne comprends pas que tous ces sites qui sont tout de meme assez sensible ne possedent pas d'administrateurs systemes ou alors c est a se demander ce que ces derniers font. Ca fait 2 mois que cette faille est connue et à fait la une de tous les sites traitant de securite. On constatait la meme chose pour RedCode, Nimda, ...

    • [^] # Re: Ou sont les admins?

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

      Cela ne m'étonne qu'à moitié et ils y a des tas de raisons pour lesquelles on trouve des serveurs infectables/infectés... - L'admin est parti (voir s'est fait viré pour cause de coût trop élevé) et un faisant fonction (pas au courant) gère au jour le jour - Les machines perso branchées sur le cable, l'ADSL et dans les chambres d'étudiants. Le problème est que toutes les distributions sur CDs sont vulnérables... combien de personnes (amateurs) vont mettre à jour leur installation ? - Les mauvais administrateurs (je sais c'est pas bien de taper sur les collègues mais j'en ai croisés certains qui meriterait des baffes et font honte à cette/ma profession). - Les apaches embarqués dans des "boites noires" et dont la boîte n'a pas souscrit/revouvelé le contrat de maintenance. -... Et c'est exact c'est la même chose que Code-Red ou Nimda (dont d'ailleurs je continue à recevoir des 'probes' plusieurs fois par jour).

      • [^] # Re: Ou sont les admins?

        Posté par  . Évalué à 4.

        « - Les machines perso branchées sur le cable, l'ADSL et dans les chambres d'étudiants. Le problème est que toutes les distributions sur CDs sont vulnérables... combien de personnes (amateurs) vont mettre à jour leur installation ? »

        Selon ce qui est dit par d'autres plus, toutes les distributions ont proposés des correctifs il y'a plusieurs mois.

        Quoi qu'il en soit, le test est censé avoir été fait sur « un échantillon représentatif de 134.149 sites Web », donc probablement pas sur des adresses IP appartenant à tel ou tel ISP.

        • [^] # Re: Ou sont les admins?

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

          Selon ce qui est dit par d'autres plus, toutes les distributions ont proposés des correctifs il y'a plusieurs mois.

          Je ne dis pas le contraire mais ces corrections sont a telecharger! Pas sur les CDs d'installation... (sauf peut-etre quelques beta tres recentes et autres).

          un échantillon représentatif de 134.149 sites Web

          Ok mais je parie que beaucoup d'associations et de sites "amateurs" tournent chez des particuliers.

    • [^] # Re: Ou sont les admins?

      Posté par  . Évalué à 10.

      La réponse à ta remarque est là : http://www.kitetoa.com Il y a une rubrique "le monde fou des admins" qui montrent comment nos banques, nos supermarchés, nos grandes entreprises gardent bien nos données personnelles dans leurs bases de données (genre, passoire à trous).

    • [^] # Re: Ou sont les admins?

      Posté par  . Évalué à 10.

      les 3/4 se sont fait mettre en place leur architecture par une SSII et s'il n'y a pas d'infogérance (ou s'il y en a une mais que le loulou n'est pas compétent...), ben la faille elle reste là où elle est. Il y a actuellement 95% des SSII qui ne prennent pas la peine d'assurer le support lors de la decouverte de tels problèmes. Je dirais que le pire reste l'installation de système tout pourrave par des incompétents soi disant linuxien (depuis 2 semaines). Derniereement, j'ai vu named, lpd, ssh, telnet tourner sur un serveur Web (accessoirement, yavait apache)... F*ck les oportunistes incompétents qui rendent un linux aussi sécurisé qu'un NT sans SP.

      • [^] # Re: Ou sont les admins?

        Posté par  . Évalué à 10.

        F*ck les oportunistes incompétents qui rendent un linux aussi sécurisé qu'un NT sans SP. c'est peut être aussi exactement le même problème pour les deux OS. pas d'admin compétents, pas de patchs, linux ou nt n'ont rien à voir dans l'affaire. Restons humble, linux a sans doute plein de qualités au niveau de la sécurité (et tout d'abord son modèle frustre de gestion de la sécurité, et la correction de son implantation, mais quand il y a un trou, il y a un trou. C'est tout. Et puis toutes ces news sur les vers, les machins, les bidules, il y en a ras le bol. C'est dans le B.A-BA de la sécurité que de se mettre à jour. Vous allez me dire comme dans kitetoa (respect (c:) qu'à la différence ces gens là stockent des données personnelles et bien oui : les admins incompétents c'est finalement la cerise sur le gâteau après le personnel politique sensibles aux "pressions" des industriels (vous comprenez mettre des bouseux ca me permet de réduire mes couts et puis la sécurité j'y comprend rien) et la justice à 2 vitesses (re cf. kitetoa). Mais ce gout amer dans la bouche ce sont les deux couches d'en dessous qui le donnent, la cerise de toute façon elle a toutes les chances d'être virée vu la météo de l'emploi.

        • [^] # Re: Que sont les admins?

          Posté par  . Évalué à 9.

          mais quand il y a un trou, il y a un trou. C'est tout

          D'où un admin est en fait un bouche-trou ;-)


          J'ai compris, -1

        • [^] # Re: Ou sont les admins?

          Posté par  . Évalué à 3.

          C'est pourtant pas mon genre de relever les fôtes, mais quand le mot est souligné...
          On dit pas "frustre" (linux n'a rien d'un gros frustré... quoique, avec les geeks...) mais "fruste" (sens ici: qui manque de finesse).

          (Cependant le TLFi ( http://atilf.inalf.fr/tlfv3.htm(...) ) me dit que "Rem. On rencontre ds la lang. parlée la forme frustre due à un croisement sémantique et phonétique avec rustre.")

          Erreur suffisamment répandue pour que je me permette de la signaler, mais néanmoins HS donc [-1]

          • [^] # Re: Ou sont les admins?

            Posté par  . Évalué à -3.

            Dans le n° 386 du buleltin "défense du français", il est écrit : "Fruste se disait d'ailleurs frustre au XVe siècle."
            je suis d'une mauvaise fois épouvantable moi ?
            bon allez je le copierai 100 fois
            -> 1

        • [^] # Re: Ou sont les admins?

          Posté par  . Évalué à -1.

          « c'est peut être aussi exactement le même problème pour les deux OS »

          Tout les logiciels peuvent être potentiellement victimes de failles, de défauts.

          Mais le problème de la sécurité n'est pas le même. Il y'a beaucoup de differences, dans la mesure ou toute une catégorie de trous sur les SE microsoft semblent être des fonctionnalités.

          Aussi, mettre à jour une machine microsoft n'a rien à voir avec la mise-à-jour d'une machine sous gnu/linux, ni financièrement, ni en terme de temps, ni en terme de simplicité.

          Le problème n'est donc *pas* le même.

          • [^] # Re: Ou sont les admins?

            Posté par  . Évalué à 0.

            Mettre à jour une machine linux, disons debian c'est apt-get dist-upgrade. urpmi je_sais_pas_quoi pour RedHat, ect...
            Mettre à jour une machine windows, c'est www.windowsupdate.com et 4 clicks d'affilée (+ 1 reboot).
            Quelle est la différence financiére, en temps, ou en simplicité ?

    • [^] # Re: Ou sont les admins?

      Posté par  . Évalué à 5.

      Il faut croire que les admins en question ont été viré pur incompétence :

      • ils n'ont pas patché

      • ils font tourner Apache en root

      • /tmp n'est pas monté en noexec



      Bref, ils l'ont bien mérité.

  • # sémantique...

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

    Par rapport au titre de la news. Juste pour dire que vers!=ver. Un ver, c'est mou, flasque, et ça explose les serveurs NT. Un vers, c'est poétique... [-1] car hors-sujet

  • # Et si on vire gcc ?

    Posté par  . Évalué à 10.

    Est-ce que ne pas installer Gcc pourrait suffire à se protéger du vers ?

    Après tout, sur un serveur web, on n'a pas besoin d'un compilateur.

    BeOS le faisait il y a 20 ans !

    • [^] # Re: Et si on vire gcc ?

      Posté par  . Évalué à 4.

      bof, c'est bien pratique sur un serveur gcc quand même, pour compiler la dernière version du soft...
      le cross-compiling c'est plus galère que des mise à jour régulières, et le type qui ne fait pas de mises à jour, il ne va pas penser à virer gcc généralement.

      Sinon, à tirtre informatif, la version OpenBSD de l'exploit (et surement du vers, du coup, pas bien dur quand on a les sources des 2) est sortie et se ballade à qui mieux mieux sur la toile....

      En tout cas le type qui a écrit ce vers est sacrément doué^Wvicelard :/

      • [^] # Re: Et si on vire gcc ?

        Posté par  . Évalué à 7.

        bof, c'est bien pratique sur un serveur gcc quand même, pour compiler la dernière version du soft...
        <ironie>
        Ah parce que toi tu installes la dernière version d'une application sur un serveur "sensible" ? Et bien évidemment tu la compiles. Bien sur... D'ailleur mon admin système est en train de recompiler le dernière noyau Linux avec gcc 3.1 puis après il attaque la dernière version d'Apache et de KDE sur le serveur web de ma boîte.

        Par contre il n'a pas trop le temps de corriger les trous de sécurité.
        </ironie>
        Soyons sérieux ! Je ne suis pas admin. système. Mais il ne me viendrait pas à l'esprit de courrir le risque de mettre le bordel sur ma machine en "recompilant la dernière version d'un soft". Je récupère la paquetage et j'installe si c'est nécessaire et ce ne sera surement pas la dernière version.

      • [^] # Re: Et si on vire gcc ?

        Posté par  . Évalué à 3.

        Toujours est-il qu'un serveur public ne devrait pas tourner apache avec l'utilisateur root, ça tombe sous le sens.

        Et c'est par défaut sur pas mal de distrib

        RedHat :

        [root@valkyrie root]# ps aux
        USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
        root 1 0.2 2.7 1304 380 ? S 10:30 0:05 init
        root 2 0.0 0.0 0 0 ? SW 10:30 0:00 [keventd]
        root 3 0.0 0.0 0 0 ? SW 10:30 0:00 [kapmd]
        root 4 0.0 0.0 0 0 ? RWN 10:30 0:00 [ksoftirqd_CPU0]
        root 5 0.2 0.0 0 0 ? SW 10:30 0:05 [kswapd]
        root 6 0.0 0.0 0 0 ? SW 10:30 0:00 [bdflush]
        root 7 0.0 0.0 0 0 ? SW 10:30 0:00 [kupdated]
        root 8 0.0 0.0 0 0 ? SW 10:30 0:00 [mdrecoveryd]
        root 12 0.0 0.0 0 0 ? SW 10:30 0:00 [kjournald]
        root 118 0.0 0.0 0 0 ? SW 10:30 0:00 [kjournald]
        root 395 0.0 0.0 0 0 ? SW 10:31 0:00 [eth0]
        root 397 0.0 2.4 1308 328 ? S 10:31 0:00 /sbin/dhcpcd -n e
        [...]
        apache 935 0.0 8.5 77148 1164 ? S 10:33 0:00 /usr/sbin/httpd -
        daemon 954 0.0 2.7 1344 372 ? S 10:33 0:00 /usr/sbin/atd
        root 961 0.0 2.3 1280 320 tty1 S 10:33 0:00 /sbin/mingetty tt
        root 962 0.0 2.3 1280 320 tty2 S 10:33 0:00 /sbin/mingetty tt
        apache 1489 0.0 8.5 77148 1164 ? S 10:39 0:00 /usr/sbin/httpd -
        apache 1708 0.0 8.5 77148 1168 ? S 10:39 0:00 /usr/sbin/httpd -
        apache 1721 0.0 10.0 77148 1372 ? S 10:39 0:00 /usr/sbin/httpd -
        root 2170 4.0 11.6 3344 1580 ? S 11:11 0:00 /usr/sbin/sshd
        root 2171 6.4 9.6 2456 1316 pts/0 S 11:12 0:00 -bash
        root 2214 0.0 5.0 2532 684 pts/0 R 11:12 0:00 ps aux


        Debian :

        [~]# ps aux
        USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
        root 1 0.0 0.0 1260 384 ? S Jun27 1:50 init [2]
        root 2 0.0 0.0 0 0 ? SW Jun27 0:23 [keventd]
        root 3 0.0 0.0 0 0 ? SWN Jun27 0:00 [ksoftirqd_CPU0]
        root 4 0.0 0.0 0 0 ? SWN Jun27 0:00 [ksoftirqd_CPU1]
        root 5 0.1 0.0 0 0 ? SW Jun27 214:19 [kswapd]
        root 6 0.0 0.0 0 0 ? SW Jun27 0:00 [bdflush]
        root 7 0.0 0.0 0 0 ? SW Jun27 24:30 [kupdated]
        root 8 0.0 0.0 0 0 ? SW< Jun27 0:00 [mdrecoveryd]
        root 9 0.0 0.0 0 0 ? SW Jun27 39:57 [kjournald]
        root 78 0.0 0.0 0 0 ? SW Jun27 14:32 [kjournald]
        [...]
        root 26515 0.1 0.1 3040 1972 ? S 05:07 0:00 /usr/bin/perl /su
        www-data 26542 0.1 0.3 7780 4084 ? S 05:07 0:00 /usr/sbin/apache-
        www-data 27340 0.2 0.3 7416 3792 ? S 05:08 0:00 /usr/sbin/apache-
        www-data 29489 0.2 0.3 7244 3252 ? S 05:12 0:00 /usr/sbin/apache-
        www-data 29517 0.4 0.3 7372 3656 ? S 05:13 0:00 /usr/sbin/apache-
        www-data 29519 0.0 0.1 6784 1920 ? S 05:13 0:00 /usr/sbin/apache-
        www-data 29521 0.0 0.1 6784 1920 ? S 05:13 0:00 /usr/sbin/apache-
        www-data 29522 0.0 0.1 6784 1920 ? S 05:13 0:00 /usr/sbin/apache-
        [...]


        Bref....

      • [^] # Re: Et si on vire gcc ?

        Posté par  . Évalué à 2.

        bof, c'est bien pratique sur un serveur gcc quand même, pour compiler la dernière version du soft...

        Sur un serveur "sérieux", on ne met que le strict minimum. C'est comme ça qu'on fait pour les banques par exemple. Il y a donc toujours au moins 2 machines, celle sur laquelle tournent les applicatifs, et celle de développement.
        C'est le cas avec un serveur que j'administre. Pour mettre à jour, je compile "chez moi" et je télécharge les binaires ensuite. En plus ça permet de tester, et ça n'est guère contraignant.

  • # Programme de test

    Posté par  . Évalué à 5.

    Ici:

    http://cert.uni-stuttgart.de/advisories/openssl-sslv2-master/openss(...)

    A compiler avec :

    gcc -o sslv2 openssl-sslv2-master.c -lcrypto

    Et pour tester :

    $./sslv2 127.0.0.1
    127.0.0.1 443 PATCHED: fully patched (0.9.6g)


    Alain

Suivre le flux des commentaires

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