5

I have about 10 websites hosted on shared server by a2hosting, on apr 20 some of the js files for some of the websites were appended with a function that detects the device and if it is mobile it redirects to other websites with promotions. Using find ./ -name "*.js" | xargs grep "adabefbccdbe()" from public_html directory (where adabefbccdbe() is the name of the redirect function) I can detect all of the files that were affected and remove the code. I have issued a support ticket to my hosting provider. When I sftp to my server I can see that all of the files were edited on april 20th, it affected javascript files for wordpress, magento and static websites, however it only affected 7 out of 10 websites on the server.

My question is is there a way to see who and how was able to edit these files? And what can I do to make sure that this would not happen again?

  • This is a related question. Maybe not a duplicate since you are on shared hosting, which changes things a bit. – Anders Apr 21 '16 at 14:20
  • Move to a VPS as shared servers are notoriously insecure. There are dirt cheap ones (eg: Digital Ocean). – Neil Smithline Apr 21 '16 at 14:32
  • @NeilSmithline I agree that VPS might be more secure that a shared hosting. However, if I get hacked on Digital Ocean it's entirely my problem, since their part of the work is only to make sure that my droplet is working, in other words no customer support. – AntK Apr 21 '16 at 14:46
  • Both Magento and WordPress are notorious for having serious vulnerabilities if not kept patched. The shoplift bug in Magento allowed easy database insertion of admin level users which then could be used to log into the downloader to install a php file manager like MagePleasure. Other WordPress vulnerabilities allow for direct shell and file access. Their plugins, depending on the developers security willpower and expertise can be vulnerability sieves. – Fiasco Labs Apr 22 '16 at 3:15
  • @AntK Just an off topic question, how well known is your website? I am just started to run e-commerce website on a shared hosting server. Should I be concerned? – 4 Leave Cover Nov 10 '16 at 7:55
4

There is a canonical question entitled "How do I deal with a compromised server?". Since you are on a shared host, there are some limitations to what you can do. I still strongly recommend you to read the full accepted answer.

Below I will discuss how this applies to your situation (i.e. on a shared hosting). Quotes are from the mentioned answer.

1. Take your site down.

Whatever other problems you have, leaving the system connected to the web will only allow the attack to continue.

You can not know for sure that you have removed all infections. At this very moment you might unkowingly be spreading malware to your users!

2. Damage control.

Change all your passwords for all accounts on all computers that are on the same network as the compromised systems.

Check your other systems. Pay special attention to other Internet facing services, and to those that hold financial or other commercially sensitive data.

If the system holds anyone's personal data, immediately inform the person responsible for data protection (if that's not you) and URGE a full disclosure.

3. Try to figure out what happend.

If you just put your site back up as it were, the same thing will just happend again. You need to try to understand what went wrong.

With shared hosting this can be hard, since it is possible that the hackers used an exploit in the server software itself or in some other persons account. You will need to contact your hosting provider and get them to help you with this. It can not be taken for granted that they will cooperate. If they do not, I recommend you to read your contract and possibly contact a lawyer to find out what rights you have.

However, you can examine some things on your own - namely your own site. Go through all the software you run (WordPress, Magento etc). Are you running the latest versions? Are you running any plugins? Are there any known security holes in the versions or plugins you are running? Especially WordPress plugins are frequent offenders when it comes to security.

There is some limited forensics you can do on your own. If you have backups, compare them to see what files have been changed at what time. The injected JavaScript you discovered might not be the only thing the attackers changed. There might have been multiple changes at multiple times (possibly by multiple attackers), so you can not know for sure that the date when the JavaScript files were changed was the date of the initial breach.

Especially if you run a lot of your own code, you might want to do a more detailed pentest to find any vulnerabilities.

4. Consider new hosting.

Especially if the breach was "their fault" or they did not help you to determine the cause of the breach, it might be time to move to new hosting. As others have mentioned, a VPS is more secure but can also require more effort on your part to run.

5. Get your site back up again.

Restore static files from a backup before the breach. Reinstall all software, and only use the latest versions. So dont just copy paste the files from your old vulnerable WordPress installation back up to the server from a backup.

And obviously, fix any problems discovered during step #3.

3

OK, I will try to focus on the part of "who".

My question is is there a way to see who and how was able to edit these files?

It depends, but what can you do is following:

  • analyze server logs (auth, apache, ftp etc.)
  • while you are analyzing logs keep in mind to check if there is any kind of information about pre-attack phase (sometimes attackers are making 'mistake' and they forget to hide their info, while gathering information) - this can be useful
  • analyze mails, if there is something suspicious in the content (maybe they did a social engineering thing)
  • analyze uploaded files (exif data)
  • and lastly, check if they left a defacement page with their email, facebook, twitter, nickname, friends nicknames etc. :)

Based on all information, do a simple report and now it's your turn to gather information about him.

2

Essentially, you would be looking at forensic investigation of the server, which would look in great detail at any access logs, error logs, files with unexpected timestamps, and so on, looking for the specific method that was used in this case. This would need to be carried out at a server level in order to be worthwhile, though, which wouldn't normally be possible with a shared hosting provider.

In this case, all you can control is your own site - you could have a software audit or penetration test carried out against it (with the consent of the server owner), and see whether there are any specific issues within this. However, since it's a shared server, there may well be issues in other sites on the same system which you can't affect. In that case, your only option would be to move to a different provider - ideally a VPS, where only your code is on it. There are various managed VPS providers, although they tend to be more expensive than shared hosting providers, since the resource requirements are higher.

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.