Collègues, ceux qui utilisent Exim version 4.87 à 4.91 sur leurs serveurs de messagerie doivent mettre à jour d'urgence vers la version 4.92, après avoir stoppé Exim afin d'éviter une intrusion via CVE-2019-10149.
Potentiellement plusieurs millions de serveurs dans le monde sont vulnérables, cette vulnérabilité est classée comme critique (score de base CVSS 3.0 = 9.8/10). Les attaquants peuvent exécuter des commandes arbitraires sur votre serveur, souvent avec des privilèges root.
Veuillez vous assurer que vous utilisez la version corrigée (4.92) ou déjà patchée.
Sinon, patchez l'existant, cf. le fil .
Mise à jour pour centos 6: cf. — pour centos 7, cela fonctionne aussi, si cela n'a pas encore été effectué directement depuis epel.
UPD : Ubuntu est affecté 18.04 et 18.10, la mise à jour a été publiée pour eux. Les versions 16.04 et 19.04 ne sont pas touchées, à moins que des versions personnalisées n'aient été installées. Plus de détails .
Le problème décrit là-bas est actuellement exploité activement (par un bot, il faut le supposer), j'ai remarqué une infection sur certains de mes serveurs (fonctionnant avec 4.91).
Continuer à lire n'est pertinent que pour ceux qui ont déjà été touchés - soit il faut tout migrer vers un VPS propre avec un logiciel frais, soit chercher une solution. On essaie ? Écrivez si quelqu'un peut résoudre ce malware.
Si vous êtes utilisateur d'Exim et que vous lisez ceci sans avoir mis à jour (sans vous être assuré de la présence de 4.92 ou d'une version patchée), veuillez vous arrêter et allez mettre à jour.
Pour ceux qui ont déjà été affectés - continuons...
Mise à jour : et donne un bon conseil :
Il peut y avoir une multitude de malwares. En lançant un remède inapproprié et en nettoyant la file d'attente, l'utilisateur ne guérira pas et ne saura probablement même pas de quoi il doit se soigner.
L'infection se manifeste comme suit : [kthrotlds] utilise le processeur ; sur un VDS faible à 100 %, sur des serveurs moins puissants mais clairement détectables.
Après l'infection, le malware supprime les entrées dans cron, ne laissant que lui-même se lancer toutes les 4 minutes, tout en rendant le fichier de crontab immuable. Crontab -e ne peut pas sauvegarder les modifications, renvoie une erreur.
L'immutabilité peut être levée comme suit, après quoi vous supprimez la ligne de commande (1.5ko) :
chattr -i /var/spool/cron/root
crontab -e Ensuite, dans l'éditeur crontab (vim), supprimez la ligne et sauvegardez :dd
:wq
Cependant, l'un des processus actifs réécrit à nouveau, j'enquête.
Cependant, il y a de nombreux wget (ou curl) actifs vers des adresses du script d'installation (voir ci-dessous), je les termine pour l'instant, mais ils redémarrent :
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Arrêt en cours..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
Le script d'installation du cheval de Troie a été trouvé ici (centos) : /usr/local/bin/nptd… je ne le publie pas par mesure de sécurité, mais si quelqu'un est infecté et comprend les scripts shell, merci d'examiner cela de plus près.
Je vais ajouter des informations au fur et à mesure.
Mise à jour 1 : Suppression des fichiers (après un chattr -i préalable) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root n'a pas aidé, tout comme l'arrêt du service - j'ai dû supprimer le crontab complètement (renommer le fichier binaire).
Mise à jour 2 : L'installateur du cheval de Troie se trouvait parfois aussi ailleurs, une recherche par taille a été utile :
find / -size 19825c
Mise à jour 3 : Attention ! En plus de désactiver selinux, le cheval de Troie ajoute sa clé SSH dans ${sshdir}/authorized_keys ! Et active les champs suivants dans /etc/ssh/sshd_config, s'ils n'ont pas encore été définis comme OUI :
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
Mise à jour 4 : En résumé, à ce stade : désactivez exim, cron (avec les utilisateurs root), supprimez d'urgence la clé du cheval de Troie de ssh et modifiez la configuration sshd, redémarrez sshd ! Et tant que c'est pas sûr que cela aide, sans cela c'est vraiment problématique.
J'ai mis en avant des informations importantes des commentaires sur les patchs/mises à jour au début de la note, afin que les lecteurs commencent par cela.
Mise à jour 5 : que le malware a changé les mots de passe dans WordPress.
Mise à jour 6 : , testons ! Après un redémarrage ou la désactivation du traitement, cela semble tomber, mais pour l'instant c'est mieux que rien.
Si quelqu'un réalise (ou trouve) une solution stable, merci de le faire savoir, cela aidera beaucoup de gens.
Mise à jour 7 : écrit :
Si ce n'est pas déjà dit, le virus se réveille grâce à un e-mail non envoyé dans exim, lors de la tentative d'envoi d'un e-mail, il se restaure, regardez dans /var/spool/exim4
Pour nettoyer toute la file d'attente exim, vous pouvez faire ainsi :
exipick -i | xargs exim -Mrm
Vérification du nombre d'enregistrements dans la file d'attente :
exim -bpc
Mise à jour 8 : Encore : FirstVDS a proposé sa propre version du script pour le traitement, commençons les tests !
Mise à jour 9 : Il semble que sur, merci pour le script !
N'oubliez pas que le serveur a déjà été compromis et que les attaquants ont pu insérer d'autres types de malveillance (non indiqués dans le dropper).
Il est donc préférable de migrer vers un serveur fraîchement installé (vds), ou au moins de continuer à suivre le sujet — si quelque chose de nouveau apparaît, écrivez dans les commentaires ici, car il est évident que tout le monde ne va pas migrer vers une installation neuve…
MISE À JOUR 10 : Merci encore : il rappelle que les infections ne touchent pas seulement les serveurs, mais aussi par exemple Raspberry Pi, et toutes sortes de machines virtuelles… Donc, après avoir sauvé les serveurs, n'oubliez pas de sauver vos décodeurs, robots, etc.
MISE À JOUR 11 : De une remarque importante pour ceux qui "soignent manuellement" :
(après avoir appliqué l'une ou l'autre méthode de lutte contre ce malware)
il est impératif de redémarrer — le malware réside quelque part dans les processus ouverts et, par conséquent, dans la mémoire, et il se réécrit toutes les 30 secondes dans cron
MISE À JOUR 12 : chez lui dans la file exim un autre (?) malware et recommande d'abord d'étudier précisément son problème avant de commencer le traitement.
MISE À JOUR 13 : de migrer rapidement vers un système propre et de transférer les fichiers très prudemment, car le malware est déjà accessible au public et peut être utilisé par d'autres d'une manière moins évidente et plus dangereuse.
MISE À JOUR 14 : se rassurant en disant que les gens intelligents ne lancent pas en tant que root — un autre :
Même si cela ne fonctionne pas sous root, il y a une intrusion… J'ai un OrangePi qui tourne sous debian jessie MISE À JOUR : stretch, exim lancé par Debian-exim et il y a quand même eu une intrusion, cron et d'autres choses ont été effacées.
MISE À JOUR 15 : lors de la migration d'un serveur comprometté vers un serveur propre, n'oubliez pas l'hygiène, :
Lors du transfert de données, faites attention non seulement aux fichiers exécutables ou de configuration, mais aussi à tout ce qui peut contenir des commandes malveillantes (par exemple, dans MySQL cela peut être CREATE TRIGGER ou CREATE EVENT). De plus, n'oubliez pas les fichiers .html, .js, .php, .py et autres fichiers publics (idéalement, ces fichiers, ainsi que d'autres données, devraient être restaurés à partir d'un stockage local ou d'un autre stockage de confiance).
MISE À JOUR 16 : et : dans le système, une version d'exim était installée sur les ports, tandis qu'en réalité une autre était exécutée.
Donc, tout le monde après la mise à jour, il vaut la peine de s'assurer que vous utilisez bien la nouvelle version !
exim --versionNous avons résolu collectivement leur situation.
Un ancien paquet da_exim (ancienne version, sans vulnérabilité) était utilisé sur le serveur avec DirectAdmin.
Avec le gestionnaire de paquets custombuild de DirectAdmin, une version plus récente d'exim, déjà vulnérable, a en fait été installée.
Dans cette situation particulière, une mise à jour via custombuild a également aidé.
N'oubliez pas de créer des sauvegardes avant de tels expérimentations, et assurez-vous que tous les processus exim de l'ancienne version ont été arrêtés avant et après la mise à jour. et ne sont pas restés "bloqués" en mémoire.
Source : habr.com
