CentOS

Posté par RbN le 23 février 2013 à 09:17. Édité par Benoît Sibaud, Nils Ratusznik, apkwa, gilles renault et Xavier Teyssier. Modéré par Nÿco. Licence CC By‑SA.

Étiquettes : aucune

fév.

2013

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 le 23 février 2013 à 10:16. É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 -=[ silmaril ]=- (site web personnel) le 23 février 2013 à 11:12. É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 le 23 février 2013 à 14:35. É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 neologix le 23 février 2013 à 14:59. É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 symoon le 23 février 2013 à 16:33. Évalué à 10.
        
        En même temps il y a marqué simulate, c'est très trompeur.
- [^] # Re: Magic SysRq
  
  Posté par deasy le 23 février 2013 à 15:54. Évalué à 2.
  
  euh un sync ou deux juste avant et c'est bon non?
# CPanel soupçonné

Posté par Pinaraf le 23 février 2013 à 13:00. É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) le 23 février 2013 à 13:29. É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 le 23 février 2013 à 13:43. Évalué à 10.
    
    Et merde, faut s'attendre à des millions de serveurs corrompus alors…
    - [^] # Re: CPanel soupçonné
      
      Posté par Zenitram (site web personnel) le 23 février 2013 à 13:51. É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 le 23 février 2013 à 13:58. É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) le 23 février 2013 à 14:15. É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 le 23 février 2013 à 14:36. É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 le 23 février 2013 à 15:45. Évalué à 10.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: CPanel soupçonné
        
        Posté par deasy le 23 février 2013 à 15:58. É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 le 23 février 2013 à 22:25. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: CPanel soupçonné
        
        Posté par nono14 (site web personnel) le 24 février 2013 à 12:47. Évalué à 4.
        
        Un choix à faire: les compétences ou la rémunération.
        
        Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
        
        [^] # Re: CPanel soupçonné
        
        Posté par izulium le 25 février 2013 à 16:55. É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 le 25 février 2013 à 19:45. É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 nono14 (site web personnel) le 25 février 2013 à 19:53. É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 - Ouvert à de nouvelles opportunités
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 23 février 2013 à 22:30. Évalué à 2.
        
        Ce commentaire a été supprimé par l’équipe de modération.
# Et les autres distribs?

Posté par ParaDoxe le 24 février 2013 à 03:23. É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) le 28 février 2013 à 11:03. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.