My Linode Hacked

What was hacked? A user account? Root? Website? What was it running? PHP? Running as which user? Where does it have write permissions? We'll need way more information than what you're giving us.

@Nuvini:

What was hacked? A user account? Root? Website? What was it running? PHP? Running as which user? Where does it have write permissions? We'll need way more information than what you're giving us.

Thank you for replying.

We are running a bunch of WordPress sites on one linode. Hackers created a folder called "progress" with an index.php file (with user "www-data") that was allegedly being used as a phishing script. Unfortunately I deleted

it right away without inspecting the file, but is there a way I can find out how that folder ended up in there? What script generated those files?

You've been compromised.

The only SAFE solution is to scrub your hard drive and start fresh. This time use SECURE passwords and lock down your Wordpress installs.

There's only been a zillion articles about the largest botnet attack on Wordpress sites to date, and how to lock it down. Never fails to amaze me how people ignore all the secure warnings and just hope they won't be on the wrong side of the attack.

Maybe write this down on a post-it note and stick it to your monitor

"Security is a ONGOING PROCESS not a one shot task"

I appreciate your response, vonskippy. However, it does not help me at all. I am aware of the security issues and that's why I am here. What I would like to know is if there is a way to investigate and find out how those files where originated.

Thanks!

You've given no information to go off of. Are you running the latest Wordpress? Are all themes and plugins up to date?

Okay first off, if they're being created as www-data, I assume PHP runs under that user. You'll need to check how you have configured PHP. If it is possible for PHP to write to the entire system and other websites as well, you'll need to find all files/folders that are owned by www-data and check if they're legitimate. If you configured PHP so it can only access the directories of the specific website your scope will be more limited.

The following should probably work to find all everything under www-data so you can check if there's something dodgy. I should sort by date but I'm not sure if the syntax is fully correct:

find / -user www-data -exec ls -hlrt {} +

Make sure to run it as root, otherwise you'll get lots of errors with no permission.

You can use WPscan: https://github.com/wpscanteam/wpscan (ruby wpscan.rb –url --enumerate) to scan your sites. I have this running locally, so if you want I can run it as well if it's too much hassle for you to set up. You'll have to tell me which websites though.

Good luck

Thank you for your help. I will see what I can do with the information you provided.

I fixed permissions and was able to find some other files with malicious scripts.

Also, my cpu was up to 120% today (normal was around 30%), so I ran this command "ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | less" to figure out what was using it the most. The line below represent 65% of the usage.

-> import pty pty.spawn('/bin/bash')

Does it mean anything to you guys?

Ultimately, you will have to consider your Linode tainted beyond repair and will have to redeploy. You will not be able to trust that there is not a rootkit installed. If you're just doing this as an experiment, cool - save the disk image, compact it, and make a new one.

@derfy:

Ultimately, you will have to consider your Linode tainted beyond repair and will have to redeploy. You will not be able to trust that there is not a rootkit installed. If you're just doing this as an experiment, cool - save the disk image, compact it, and make a new one.

It shouldn't be -that- bad if it's just the www-data user they got access to. But if they got root you can't trust any data on there.

If it's just www-data, find the files owned by that user and remove them if it's suspicious. The /bin/bash thing is probably a reverse shell. If it is still running you could get more information about it at /proc/$pid/cmdline (cat it) or /proc/$pid/exe (ls -liarh)

Might also want to check for dodgy Apache modules. I believe a popular thing these days is to infect apache with bogus modules as some sort of backdoor. Not sure though, I don't use Apache.

But how do you know that getting in as www-data didn't lead to a root exploit being used?

Once a machine is compromised, it's tainted and should be destroyed and redeployed from known good backups.

I think redeploying is the safest way to go.

Redeploying is absolutely the only sane thing to do in this circumstance.

We have a really great write-up on the reasons for this over on ServerFault. I'd highly recommend that you check it out when you have a chance.