Infection par rootkit « SSHd Spam » sur des serveurs RHEL/CentOS

Posté par . Édité par Benoît Sibaud, Nils Ratusznik, apkwa, gilles renault et Xavier Teyssier. Modéré par Nÿco. Licence CC by-sa
Tags : aucun
42
23
fév.
2013
Sécurité

Lundi 18 février a été le jour de la découverte de ce rootkit ayant apparemment infecté un certain nombre de serveurs sous RHEL/CentOS. Des rumeurs font également état de serveurs touchés sous Debian.

Afin de vérifier si ce rootkit vous a infecté, cherchez si un fichier libkeyutils.so.1.9 est présent dans votre arborescence.

Une procédure de désinfection (NdM : attention des fichiers libkeyutils.so* peuvent légitimement être présents (1 ou 2) sur votre système, assurez-vous de comprendre ce que vous faites avant de supprimer ou remplacer des bibliothèques dynamiques .so) :

rm /lib64/libkeyutils.so.1.9 /lib64/libkeyutils.so.1
ln -sf /lib64/libkeyutils-1.3.so /lib64/libkeyutils.so.1
sync
echo 'b' > /proc/sysrq-trigger  # simulate a hard powercut to ensure the rootkit cannot reroot if it's memory resident.

Le vecteur de l'attaque n'est pour le moment pas connu, il semblerait que le démon SSHd seul soit suffisant pour se faire infecter, quel que soit son port d'écoute.

Le but de ce rootkit est de réaliser de l'envoi de spam, et il est supposément développé par le Russian Business Network.

  • # Magic SysRq

    Posté par . Évalué à 4.

    Attention à la dernière commande qui implique l'utilisation des Magic System Requests.

    echo 'b' > /proc/sysrq-trigger
    
    

    Je n'ai pas de système avec cette fonctionnalité désactivée (à la compilation) mais il se pourrait bien que la simulation soit bien réelle et entraine un redémarrage brutal de la machine. Il s'agit d'un redémarrage très brutal, il est donc préférable de redémarrer correctement la machine en lieux et en place de cette commande.

    • [^] # Re: Magic SysRq

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

      je crois que tu n'a pas bien compris l'objectif de la "simulation" justement, le but est d'empecher
      toute nouvelle modification du système par un processus résident et donc d'effectuer un arret brutal
      du système comme le ferais une coupure de courant ("hard powercut").

      après la modification de libkeyutil ne peut être qu'une conséquence de l'intrusion, donc nettoyer cette lib ne va pas empecher une prochaine intrusion sur le vecteur d'origine.

      • [^] # Re: Magic SysRq

        Posté par . Évalué à 4.

        Effectuer un arret brutal du système comme le ferais une coupure de courant ("hard powercut").

        Il est bien là le problème. La dépêche n'insiste pas vraiment sur le fait que cette commande va arrêter brutalement le serveur. Du coup on a un système totalement planté mais au moins, on est débarrassé du rootkit.

        • [^] # Re: Magic SysRq

          Posté par . Évalué à 10.

          simulate a hard powercut to ensure the rootkit cannot reroot if it's memory resident.

          En même temps, si on ne sait pas lire…

          • [^] # Re: Magic SysRq

            Posté par . Évalué à 10.

            En même temps il y a marqué simulate, c'est très trompeur.

    • [^] # Re: Magic SysRq

      Posté par . Évalué à 2.

      euh un sync ou deux juste avant et c'est bon non?

  • # CPanel soupçonné

    Posté par . Évalué à 10.

    Hello

    Il semblerait que cela soit à cause de cpanel. La majorité des cas que l'on ait vu se sont produits après avoir contacté le support de CPanel. Il faut en les contactant donner le mot de passe root de la machine, et ils ont eu une faille de sécurité chez eux et les accès aux machines des clients se sont retrouvés dans la nature…

    • [^] # Re: CPanel soupçonné

      Posté par (page perso) . Évalué à 10. Dernière modification le 23/02/13 à 13:32.

      cPanel a l'air d'admettre que c'est chez eux: cPanel, Inc. has discovered that one of the servers we utilize in the technical support department has been compromised..

      Maintenant : qui donne sérieusement un mot de passe root non temporaire à une personne externe (intervention ponctuelle)??? Ca va permettre de voir qui est sérieux dans l'admin ;-).

      • [^] # Re: CPanel soupçonné

        Posté par . Évalué à 10.

        Et merde, faut s'attendre à des millions de serveurs corrompus alors…

        • [^] # Re: CPanel soupçonné

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

          Rassurez-moi, je n'ai pas le seul admin au monde qui râle quand je demande un mot de passe déjà pour un compte non root plutôt que d'utiliser une clé SSH, en plus d'interdire le moindre accès root avec mot de passe sauf période exceptionnelle avec méga-argument qu'on ne peut pas faire autrement? J'ai la perle rare?

          • [^] # Re: CPanel soupçonné

            Posté par . Évalué à 8.

            Non non, les admin sérieux, ça existe.

            Et puis il y a ceux qui font semblant mais en fait ne comprennent rien, j'ai eu le cas où, pour me donner accès à un serveur on m'a envoyé par mail la clé privée ssh dont la version publique avait été placée pour le compte root :-O

          • [^] # Re: CPanel soupçonné

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

            Je pense que la plupart des admins procéderaient ainsi oui, mais il n'empêche que les «cochoncetés» type CPanel ou Plesk sont vachement répandues, justement là où il n'y a pas d'admin…

            alf.life

          • [^] # Re: CPanel soupçonné

            Posté par . Évalué à 10.

            J'ai essayé aussi, mais beaucoup ne comprennent même pas de quoi je leur parle.

            Et puis, les habitudes ont la vie dure. Il n'y a pas longtemps j'ai donnée l'accès root à un prestataire du client en installant une clé SSH. Jusque là tout va bien. Deux mois après, parce qu'il faisait des tests d'authentification LDAP, le prestataire met un mot de passe au compte root. En moins de 24h le mot de passe a été brute-forcé. J'imagine même pas la tronche du mot de passe (root/root ?).

            Autre exemple qui illustre la même problématique. Un client décide d'installer PostgreSQL sur son serveur. Il trouve un tuto sur Internet et le suit à la lettre. Dans le tuto, il fallait créer un compte utilisateur postgres avec un mot de passe. Dans le tuto, le MdP était postgres. Ai je besoin de dire ce qui s'est passé…

            Bref, il y a malheureusement beaucoup de personnes dont ce n'est pas le métier qui administrent des serveurs…

            • [^] # Commentaire supprimé

              Posté par . Évalué à 10.

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

              • [^] # Re: CPanel soupçonné

                Posté par . Évalué à 1.

                anéfé les offres font peur…on doit être un monstre de l'IT et tout maitriser pour postuler…heureusement pas toutes…

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 3.

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

                  • [^] # Re: CPanel soupçonné

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

                    Un choix à faire: les compétences ou la rémunération.

                    Système - Réseau - Sécurité Open Source

                    • [^] # Re: CPanel soupçonné

                      Posté par . Évalué à 0.

                      Les deux, monsieur, c'est la crise:
                      - Des compétences et connaissances pour un emploi (généralement) sous taillé et sous payé.

            • [^] # Re: CPanel soupçonné

              Posté par . Évalué à 4.

              En moins de 24h le mot de passe a été brute-forcé.

              1/ apt-get install fail2ban denyhosts

              2/ et si possible dans /etc/ssh/sshd.conf
              PasswordAuthentication no

              • [^] # Re: CPanel soupçonné

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

                +1, cependant avec un mot de passe aussi trivial ça tient pas longtemps…

                Autoriser l'accès sur une machine de test avec une ip publique c'est trés moyen…

                Système - Réseau - Sécurité Open Source

          • [^] # Commentaire supprimé

            Posté par . Évalué à 2.

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

  • # Et les autres distribs?

    Posté par . Évalué à 4.

    Les autres distributions sont-elles touchée ?

    J'ai une Fedora qui tourne comme serveur et qui possède naturellement cette librairie en provenance du paquet keyutils-libs.

  • # Une méthode pour vérifier l'intégrité de keyutils-libs

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

    Je ne sais pas à quel point ce rootkit compromet le système, mais il est toujours intéressant de voir si l'intégrité de keyutils-libs est vérifiable ou non, sans toutefois prendre un résultat positif pour argent comptant !

    La commande suivante sous toute distribution basées sur RPM devrait marcher: rpm -V -v

    Exemple avec la famille RHEL/CentOS/Fedora:

    /bin/rpm -V -v keyutils-libs
    
    

    Il est recommandé dans de telles circonstances de s'assurer que l'on utilise le binaire 'rpm' attendu en précisant son chemin complet. Si vous deviez utiliser 'sudo' cela donnerait:

    /usr/bin/sudo /bin/rpm -V -v keyutils-libs
    
    

    Le résultat devrait être quelque chose dans le genre:
    ……… /lib64/libkeyutils.so.1
    ……… /lib64/libkeyutils.so.1.3
    ……… /usr/share/doc/keyutils-libs-1.4
    ……… d /usr/share/doc/keyutils-libs-1.4/LICENCE.LGPL

    Ce qui veut dire que tout va bien. Pour plus d'information il y a le man ou cette page-ci : RPM as an IDS

    Important : si le rootkit est suffisamment malin pour modifier votre base RPM local proprement, la commande peut vous indiquer que tout va bien quand c'est faux. Le résultat est à prendre avec circonspection et recul.

Suivre le flux des commentaires

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