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.
Aller plus loin
- Détails sur le rootkit (1632 clics)
- Une autre analyse (519 clics)
- Le début du sujet sur le même forum, avec mises à jour d'informations (466 clics)
- Faille dans le noyau Linux inférieur à 3.7.5 (589 clics)
# Magic SysRq
Posté par Spack . Évalué à 4.
Attention à la dernière commande qui implique l'utilisation des Magic System Requests.
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 -=[ silmaril ]=- (site web personnel) . É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 Spack . Évalué à 4.
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 neologix . Évalué à 10.
En même temps, si on ne sait pas lire…
[^] # Re: Magic SysRq
Posté par symoon . Évalué à 10.
En même temps il y a marqué simulate, c'est très trompeur.
[^] # Re: Magic SysRq
Posté par deasy . Évalué à 2.
euh un sync ou deux juste avant et c'est bon non?
# CPanel soupçonné
Posté par Pinaraf . É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 Zenitram (site web personnel) . Évalué à 10. Dernière modification le 23 février 2013 à 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 Pinaraf . Évalué à 10.
Et merde, faut s'attendre à des millions de serveurs corrompus alors…
[^] # Re: CPanel soupçonné
Posté par Zenitram (site web personnel) . É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 wismerhill . É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 Kioob (site web personnel) . É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 ondex2 . É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 Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: CPanel soupçonné
Posté par deasy . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: CPanel soupçonné
Posté par nono14 (site web personnel) . É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 izulium . É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 Amaury . Évalué à 4.
1/
apt-get install fail2ban denyhosts2/ et si possible dans /etc/ssh/sshd.conf
PasswordAuthentication no[^] # Re: CPanel soupçonné
Posté par nono14 (site web personnel) . É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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Et les autres distribs?
Posté par ParaDoxe . É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 Jean-Christophe Berthon (site web personnel) . É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:
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:
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.