Collègues qui utilisent les versions 4.87...4.91 d'Exim sur leurs serveurs de messagerie - mettez à jour de toute urgence vers la version 4.92, après avoir arrêté Exim lui-même pour éviter le piratage via CVE-2019-10149.
Plusieurs millions de serveurs dans le monde sont potentiellement vulnérables, la vulnérabilité est jugée critique (score de base CVSS 3.0 = 9.8/10). Les attaquants peuvent exécuter des commandes arbitraires sur votre serveur, dans de nombreux cas depuis root.
Veuillez vous assurer que vous utilisez une version corrigée (4.92) ou une version déjà corrigée.
Ou patchez l'existant, voir le fil de discussion .
Mise à jour pour cents 6: cm. — pour centos 7, cela fonctionne également, s'il n'est pas encore arrivé directement d'epel.
UPD : Ubuntu est affecté 18.04 et 18.10, une mise à jour a été publiée pour eux. Les versions 16.04 et 19.04 ne sont pas affectées sauf si des options personnalisées y ont été installées. Plus de détails .
Maintenant que le problème qui y est décrit est activement exploité (par un bot, vraisemblablement), j'ai remarqué une infection sur certains serveurs (fonctionnant sous 4.91).
Une lecture plus approfondie n'est pertinente que pour ceux qui l'ont déjà « compris » - vous devez soit tout transporter vers un VPS propre avec un nouveau logiciel, soit rechercher une solution. Devons-nous essayer ? Écrivez si quelqu'un peut surmonter ce malware.
Si, en tant qu'utilisateur d'Exim et en lisant ceci, vous n'avez toujours pas mis à jour (vous n'avez pas vérifié que la version 4.92 ou une version corrigée est disponible), veuillez arrêter et exécuter la mise à jour.
Pour ceux qui y sont déjà arrivés, continuons...
UPD: et donne les bons conseils :
Il peut exister une grande variété de logiciels malveillants. En lançant le médicament pour la mauvaise chose et en vidant la file d'attente, l'utilisateur ne sera pas guéri et ne saura peut-être pas pourquoi il doit être traité.
L'infection est visible comme ceci : [kthrotlds] charge le processeur ; sur un VDS faible, il est de 100%, sur les serveurs, il est plus faible mais perceptible.
Après l'infection, le malware supprime les entrées cron, s'y inscrivant uniquement pour s'exécuter toutes les 4 minutes, tout en rendant le fichier crontab immuable. Crontab -e ne peut pas enregistrer les modifications, donne une erreur.
Immuable peut être supprimé, par exemple, comme ceci, puis supprimez la ligne de commande (1.5 Ko) :
chattr -i /var/spool/cron/root
crontab -e
Ensuite, dans l'éditeur crontab (vim), supprimez la ligne et enregistrez :dd
:wq
Cependant, certains des processus actifs sont à nouveau écrasés, je suis en train de le comprendre.
En même temps, il y a un tas de wgets actifs (ou curls) accrochés aux adresses du script d'installation (voir ci-dessous), je les fais tomber comme ça pour l'instant, mais ils recommencent :
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kill -9 `ps aux | grep wge[t] | awk '{print $2}'`
kill -9 `ps aux | grep cur[l] | awk '{print $2}'`
J'ai trouvé le script d'installation du cheval de Troie ici (centos) : /usr/local/bin/nptd... Je ne le publie pas pour l'éviter, mais si quelqu'un est infecté et comprend les scripts shell, veuillez l'étudier plus attentivement.
J'ajouterai au fur et à mesure que les informations seront mises à jour.
UPD 1 : la suppression de fichiers (avec chattr -i préliminaire) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root n'a pas aidé, ni l'arrêt du service - j'ai dû le faire crontab complètement pour l'instant, supprimez-le (renommez le fichier bin).
UPD 2 : l'installateur du cheval de Troie traînait parfois à d'autres endroits, la recherche par taille a aidé :
trouver / -taille 19825c
UPD 3 : Attention! En plus de désactiver Selinux, le cheval de Troie ajoute également son propre Clé SSH dans ${sshdir}/authorized_keys ! Et active les champs suivants dans /etc/ssh/sshd_config, s'ils n'ont pas déjà été définis sur OUI :
PermitRootLogin oui
RSAAthentification oui
PubkeyAuthentication oui
echo UsePAM oui
Mot de passeAuthentification oui
UPD 4 : Pour résumer pour l'instant : désactivez Exim, cron (avec racines), supprimez en urgence la clé du cheval de Troie de ssh et éditez la config sshd, redémarrez sshd ! Et il n’est pas encore sûr que cela soit utile, mais sans cela, il y a un problème.
J'ai déplacé les informations importantes des commentaires sur les correctifs/mises à jour au début de la note, afin que les lecteurs commencent par elles.
UPD 5 : que le malware a modifié les mots de passe dans WordPress.
UPD 6 : , testons ! Après un redémarrage ou un arrêt, le médicament semble disparaître, mais pour l’instant, c’est tout.
Quiconque trouve (ou trouve) une solution stable, écrivez-nous, vous en aiderez beaucoup.
UPD 7 : écrit:
Si vous n'avez pas déjà dit que le virus est ressuscité grâce à une lettre non envoyée dans Exim, lorsque vous essayez de renvoyer la lettre, elle est restaurée, regardez dans /var/spool/exim4
Vous pouvez effacer toute la file d'attente Exim comme ceci :
exipick -je | xargs exim -Mrm
Vérification du nombre d'entrées dans la file d'attente :
exim-bpc
UPD 8 : Encore une fois : FirstVDS a proposé sa version du script de traitement, testons-le !
UPD 9 : il semble que fonctionneMerci pour le scénario !
L'essentiel est de ne pas oublier que le serveur était déjà compromis et que les attaquants auraient pu réussir à planter des choses plus désagréables atypiques (non répertoriées dans le compte-gouttes).
Par conséquent, il est préférable de passer à un serveur complètement installé (vds), ou au moins de continuer à surveiller le sujet - s'il y a quelque chose de nouveau, écrivez dans les commentaires ici, car évidemment, tout le monde ne passera pas à une nouvelle installation...
UPD 10 : Merci encore : cela rappelle que non seulement les serveurs sont infectés, mais aussi Raspberry Pi, et toutes sortes de machines virtuelles... Alors après avoir sauvegardé les serveurs, n'oubliez pas de sauvegarder vos consoles vidéo, robots, etc.
MISE À JOUR 11 : À partir de Remarque importante pour les guérisseurs manuels :
(après avoir utilisé l'une ou l'autre méthode de lutte contre ce malware)
Vous devez absolument redémarrer - le malware se trouve quelque part dans les processus ouverts et, par conséquent, dans la mémoire, et en écrit un nouveau sur cron toutes les 30 secondes
UPD 12 : Exim a un autre (?) malware dans sa file d'attente et vous conseille d'étudier d'abord votre problème spécifique avant de commencer le traitement.
UPD 13 : passez plutôt à un système propre et transférez les fichiers avec une extrême prudence, car Le malware est déjà accessible au public et peut être utilisé d’autres manières, moins évidentes et plus dangereuses.
UPD 14 : s'assurer que les gens intelligents ne s'exécutent pas depuis root - encore une chose :
Même si cela ne fonctionne pas depuis root, un piratage se produit... J'ai Debian Jessie UPD : Stretch sur mon OrangePi, Exim s'exécute depuis Debian-exim et il y a toujours un piratage, des couronnes perdues, etc.
UPD 15 : lors du passage d'un serveur compromis à 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 également à tout ce qui peut contenir des commandes malveillantes (par exemple, dans MySQL, cela pourrait être CREATE TRIGGER ou CREATE EVENT). N'oubliez pas non plus les fichiers .html, .js, .php, .py et autres fichiers publics (idéalement, ces fichiers, comme les autres données, doivent être restaurés à partir d'un stockage local ou d'un autre stockage fiable).
UPD 16 : и : le système avait une version d'Exim installée dans les ports, mais en réalité il en exécutait une autre.
Alors tout le monde après la mise à jour, vous devez vous assurer que vous utilisez la nouvelle version !
exim --versionNous avons réglé ensemble leur situation spécifique.
Le serveur utilisait DirectAdmin et son ancien package da_exim (ancienne version, sans vulnérabilité).
Dans le même temps, avec l'aide du gestionnaire de packages personnalisé de DirectAdmin, une version plus récente d'Exim a été installée, qui était déjà vulnérable.
Dans cette situation particulière, la mise à jour via custombuild a également aidé.
N'oubliez pas de faire des sauvegardes avant de telles expériences, et assurez-vous également qu'avant/après la mise à jour, tous les processus Exim sont de l'ancienne version. et non « coincé » en mémoire.
Source: habr.com