Colleagues, if you are using Exim version 4.87…4.91 on your mail servers, urgently update to version 4.92 after stopping Exim to avoid being hacked via CVE-2019-10149.
Potentially millions of servers worldwide are vulnerable, with the vulnerability rated as critical (CVSS 3.0 base score = 9.8/10). Attackers can execute arbitrary commands on your server, often as root.
Please ensure that you are using the patched version (4.92) or one that has already been patched.
Alternatively, patch your existing version; see the thread .
Update for centos 6: see — for centos 7 it works too, if it has not yet come directly from epel.
UPD: Ubuntu affected 18.04 and 18.10, an update for them has been released. Versions 16.04 and 19.04 are not affected unless custom variants have been installed. More details .
The problem described there is currently being actively exploited (by a bot, presumably), I noticed infections on some of my servers (running 4.91).
What follows is only relevant for those who have already 'fallen'—either move everything to a clean VPS with fresh software or look for a solution. Shall we try? Write if anyone can combat this malware.
If you are using Exim and reading this, yet still haven't updated (ensured that you have 4.92 or a patched version), please stop and rush to update.
For those already affected—let's continue...
UPD: and gives the right advice:
There can be a multitude of malware. Running a remedy intended for something else will not clean the user's queue, and they might not even realize what they need to be treated for.
Infection is noticeable as follows: [kthrotlds] overloads the CPU; on a weak VDS, it goes to 100%, and on weaker servers, it's noticeable.
After infection, the malware deletes cron entries, leaving only itself to run every 4 minutes, while making the crontab file immutable. Crontab -e cannot save changes, throwing an error.
You can remove the immutable attribute like this, after which remove the command line (1.5kB):
chattr -i /var/spool/cron/root
crontab -e Then in the crontab editor (vim), delete the line and save:dd
:wq
However, some of the active processes rewrite it again, I’m investigating.
At the same time, there are a bunch of active wget (or curl) processes running on the addresses from the installer script (see below), I am currently terminating them like this, but they restart again:
ps aux | grep wge[t]
ps aux | grep cur[l]
echo "Stopping..."
kills -9 `ps aux | grep wge[t] | awk '{print $2}'`
kills -9 `ps aux | grep cur[l] | awk '{print $2}'`
The trojan installer script was found here (centos): /usr/local/bin/nptd… I won't post it to avoid issues, but if anyone is infected and understands shell scripts, please take a closer look.
I'll update as more information comes in.
UPD 1: Deleting files (after running chattr -i) /etc/cron.d/root, /etc/crontab, rm -Rf /var/spool/cron/root didn't help, nor did stopping the service — I had to completely remove crontab (rename the bin file).
UPD 2: The trojan installer was sometimes found in other locations as well, searching by size helped:
find / -size 19825c
UPD 3: Attention! In addition to disabling selinux, the trojan also adds its SSH key to ${sshdir}/authorized_keys! And activates the following fields in /etc/ssh/sshd_config, if they weren't already set to YES:
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
echo UsePAM yes
PasswordAuthentication yes
UPD 4: Summarizing up to this point: disable exim, cron (with roots), urgently remove the trojan key from ssh and edit the sshd config, restart sshd! And even then it's not certain this will help, but without this it's a disaster.
I have moved important information from comments about patches/updates to the beginning of the note, so those reading it start there.
UPD 5: that the malware changed passwords in WordPress.
UPD 6: , testing! After a reboot or disabling the fix, it seems to drop, but at least it's something for now.
If someone makes (or finds) a stable solution, please let me know, it would help many.
UPD 7: writes:
If it hasn't been mentioned, the virus resurrects due to an unsent email in exim; when trying to resend the email, it restores itself, check in /var/spool/exim4.
You can clear the entire exim queue like this:
exipick -i | xargs exim -Mrm
Check the number of records in the queue:
exim -bpc
UPD 8: Again : FirstVDS offered their version of the script for recovery, let's test it!
UPD 9: It seems that working, thank you for the script!
Just don't forget that the server has already been compromised and the attackers could have inserted other atypical nasties (not described in the dropper).
Therefore, it's better to move to a fresh server setup (VDS), or at least continue to monitor the topic — if something new arises, please comment here, as not everyone will be migrating to a fresh installation…
UPD 10: Thanks again : it serves as a reminder that not only servers get infected, but also various virtual machines… Raspberry Pi, and all sorts of virtual machines… So after rescuing the servers, don't forget to save your gaming consoles, robots, etc.
UPD 11: From an important note for those "healing manually":
(after applying a method to combat this malware)
a restart is absolutely necessary — the malware resides somewhere in the open processes and, consequently, in memory, and it writes itself into cron every 30 seconds
UPD 12: another (?) malware in their exim queue and advises to first study their specific issue before starting treatment.
UPD 13: to quickly migrate to a clean system, and transfer files very cautiously, as the malware is already publicly available and can be utilized by others in less obvious and more dangerous ways.
UPD 14: calming themselves by saying that smart people don't run as root — another :
Even if it operates not as root, hacking can still occur… I have Debian Jessie on my OrangePi UPD: stretch, exim is running from Debian-exim and still got hacked, crons and others were wiped.
UPD 15: when migrating from a compromised server to a clean one, don't forget about hygiene, :
When transferring data, pay attention not only to executable or configuration files but also anything that might contain malicious commands (for example, in MySQL this could be CREATE TRIGGER or CREATE EVENT). Also, don't forget about .html, .js, .php, .py, and other public files (ideally, these files, like the other data, should be restored from a local or another trusted storage).
UPD 16: and : the system had one version of exim on the ports, while a different one was actually running.
So it's advisable for everyone after an update to make sure that you're using the new version!
exim --versionSpecifically, we resolved their situation collectively.
DirectAdmin was used on the server and its old da_exim package (old version, without vulnerabilities) was installed.
Using the DirectAdmin package manager custombuild, a newer version of exim was installed, which is now vulnerable.
In this particular situation, updating through custombuild was also helpful.
Do not forget to back up before such experiments, and ensure that all processes of the old version of exim and did not 'hang' in memory.
Source: habr.com
