Colleagues who use versions 4.87β¦4.91 of Exim on their mail servers β urgently upgrade to version 4.92, after stopping Exim itself in order to avoid hacking through CVE-2019-10149.
Several million servers around the world are potentially vulnerable, the vulnerability is rated as critical (CVSS 3.0 base score = 9.8/10). Attackers can run arbitrary commands on your server, in many cases as root.
Please make sure you are using the patched version (4.92) or a patched one.
Or patch the existing one, see the thread .
Update for centus 6: cm. - for centos 7 it also works if it has not yet flown directly from epel.
UPD: Ubuntu affected 18.04 and 18.10, an update has been released for them. Versions 16.04 and 19.04 are not affected, unless custom versions were installed on them. More .
Now the problem described there is actively exploited (by a bot, presumably), I noticed infection on some servers (running on 4.91).
Further reading is relevant only for those who have already βhitβ - you either need to transport everything to a clean VPS with fresh software, or look for a solution. Shall we try? Write if someone can overcome this malware.
If you, being an Exim user and reading this, are still not up to date (not convinced that 4.92 or a patched version is available), please stop and run to upgrade.
For those who are already there, let's continue...
UPD: and gives the right advice:
Malware can be a great variety. By launching the medicine for the wrong thing and cleaning the queue, the user will not be cured and may not know what he needs to be treated for.
The infection is noticeable like this: [kthrotlds] loads the processor; on a weak VDS by 100%, on servers it is weaker but noticeable.
After infection, the malware deletes entries in cron, prescribing only itself there every 4 minutes, while making the crontab file immutable. Crontab -e cannot save changes, throws an error.
Immutable can be removed for example like this, and then delete the command line (1.5kb):
chattr -i /var/spool/cron/root
crontab -e
Next, in the crontab (vim) editor, delete the line and save:dd
:wq
However, one of the active processes overwrites again, I understand.
At the same time, a bunch of active wgets (or curls) hang on the addresses from the installer script (see below), I still knock them down like this, but they start up again:
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}'`
I found the Trojan installer script here (centos): /usr/local/bin/nptdβ¦ I donβt post it to avoid it, but if someone is infected and understands shell scripts, please study carefully.
Will add as information is updated.
UPD 1: Demolition of files (with preliminary chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root did not help, as well as stopping the service - I had to crontab completely for now tear out (bin-file rename).
UPD 2: The Trojan installer was sometimes also lying around in other places, the search by size helped:
find / -size 19825c
UPD 3/XNUMX/XNUMX: Attention! In addition to disabling selinux, the trojan also adds its own SSH key in ${sshdir}/authorized_keys! And activates the following fields in /etc/ssh/sshd_config, if they have not already been set to YES:
AllowRootLogin yes
RSAAuthentication yes
Pubkey Authentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: To summarize at the moment: disable exim, cron (with roots), urgently remove the trojan key from ssh and edit the sshd config, restart sshd! And then itβs not exactly what it will help, but without it itβs generally a disaster.
I moved important information from the comments about patches / updates to the beginning of the note so that readers would start from it.
UPD 5/XNUMX/XNUMX: that the malware changed passwords in WordPress.
UPD 6/XNUMX/XNUMX: , testing! After rebooting or turning off the medicine, it seems to fly off, but so far at least so.
Who will make (or find) a stable solution, please write, you will help many.
UPD 7/XNUMX/XNUMX: writes:
If you havenβt already said that the virus is resurrected thanks to an unsent letter in Exim, when you try to send a letter again, it is restored, look in /var/spool/exim4
You can clear the entire Exim queue like this:
exipick -i | xargs exim -Mrm
Checking the number of entries in the queue:
exim-bpc
UPD 8: Again : FirstVDS offered their own version of the treatment script, let's test it!
UPD 9: Looks like works, Thank you for the script!
The main thing is not to forget that the server has already been compromised and the attackers could have managed to plant some more atypical nasty things (not registered in the dropper).
Therefore, it is better to move to a cleanly installed server (vds), or at least continue to track the topic - if there is something new, write in the comments here, because obviously not everyone will move to a fresh installation ...
UPD 10: Thanks again : it reminds that not only servers are infected, but also Raspberry Pi, and all sorts of virtual machines ... So after saving the servers, do not forget to save your video consoles, robots, etc.
UPD 11: From important note for "manual healers":
(after applying one or another method of combating this malware)
you definitely need to reboot - the malware sits somewhere in open processes and, accordingly, in memory, and writes itself new to cron every 30 seconds
UPD 12/XNUMX/XNUMX: there is another (?) malware in the Exim queue and advises you to first study your specific problem, before starting treatment.
UPD 13/XNUMX/XNUMX: rather move to a clean system, and transfer files very carefully, because. The malware is already in the public domain and can be used in other, less obvious and more dangerous ways.
UPD 14: reassuring themselves with the fact that, like smart people, they donβt start from root - one more :
Even if it does not work from root, a hack occurs ... I have debian jessie on OrangePi UPD: stretch, exim is running from Debian-exim and it still happened hacking, lost cron and so on.
UPD 15: when moving to a clean server from a compromised one, do not forget about hygiene, :
When migrating data, pay attention not only to executable or configuration files, but also to everything that may contain malicious commands (for example, in MySQL this can be CREATE TRIGGER or CREATE EVENT). Also, don't forget about .html, .js, .php, .py and other public files (ideally, these files, like other data, should be restored from local or other trusted storage).
UPD 16/XNUMX/XNUMX: ΠΈ : there was one version of Exim in the ports in the system, but in fact another version was running.
So everyone make sure after the update that you are using the new version!
exim --versionSpecifically, we dealt with their situation together.
The server used DirectAdmin and had its old da_exim package (old version, without vulnerability).
At the same time, with the help of DirectAdmin's custombuild package manager, in fact, a newer version of Exim, already vulnerable, was later installed.
Specifically, in this situation, updating through custombuild also helped.
Don't forget to make backups before such experiments, and also make sure that before/after the upgrade all Exim processes of the old version and not "stuck" in memory.
Source: habr.com