Website Defacement – A Personal Account

Published January 12, 2012 | By netcerebral

My Website 12/12/12

It’s been a while since I had to put my SANS Incident Handling hat on or did root-cause analysis and Network Forensics on an actual attack this close to home. December 13th, 2011 marks the day that 144 websites mapped to the same IP address hosted by HostPapa were injected with a number of files that replaced their home pages with that of some script kiddy’s – website defacement on a large scale. Admittedly, netcerebral.com was one of the 144, as were two others, that I manage part-time.

Synopsis

The attacks appeared to originate from Kuwait (inconclusive) and when I traced the names of the attackers, their email addresses and the “Muslim Hackers” they were sending “GR33T5” to, it became evident that this was “bragging rights” under the shroud of “hactivism”. In fact, the hackers went as far as to list all 144 websites hacked at the same HostPapa IP address on www.zone-h.org, a pubic attribution of website defacements where hackers brag and place “mirrors” of the website defacements as proof of their misconduct.

The hackers jointly go by the alias of “7rb-team” and, according to zone-h.org, have successfully defaced 3,414 homepages since December 2nd, 2011 (and are currently still active with almost 100 defacements daily, in January 2012 alone).

Anatomy

Since HostPapa has not provided the access logs for the date of the attack (they had been requested but HostPapa doesn’t keep archives) we are left to assume the attack vector that was used to inject the PHP code into the websites. I have narrowed it down to either a SQL Injection or PHP URL Inclusion. The sites all had “wp__” ID tags on the WP core, no .htaccess files, out-dated WP PHP plugins and a number of other vulnerabilities, inherent to WP (themes are another possibility). I suspect the attackers used recon scanning to detect the open vulnerabilities on the site and then compromised the vulnerability to write files to the root of the virtual directory.

Once the PHP shell was injected, they connected remotely and ran the Syrian Shell which automated the creation of all “index.htm” files and downloaded all of the other artifacts that I found on the site.

Clean Up

The service provider detected the mass infection across the customer’s sites a day after the attacks and shut-down the sites. They opened a ticket and notified one of the billing contacts that the site had been shutdown and instructed us to backup the site so they could wipe it away and we could then manually restore the site. Fortunately, I had backups that I had done months prior to the attack but some of the newer posts were missing. The other issue is that, while I had backups of the site directories and MySQL for each, the attackers had injected files to the home root directory that needed to be cleaned up as well (directories such as /cgi-bin, /cpanel, etc were all infected).

I eventually decided to backup the entire site with all three domains, download and unzip them on my local PC, where I had Apache, PHP and MySQL running in a VM sandbox. I went through the painstaking task of removing 50+ occurrences of “index.htm” (the defacement page) and 5 instances of PHP shell kit code that had been injected in the root of the parent website. Next, I dropped all of the tables in two of the databases (the third site doesn’t use a DB) and restored from backup in MyPHPAdmin. Once the sites were functioning the way I wanted, I upgraded the WP core, updated all plugins and then installed WDS Security plugin, which found additional vulnerabilities, which I cleaned up on both sites.

The Evil Script

One other advantage of having the VM sandbox is that after I made a backup and export of the sanitized site, I reverted the VM snapshot back to when the site was infected and played around with the Syrian Shell (not recommended in a prod environment!) and could replicate what the attackers did once they had the PHP file uploaded to the site.

When you open up the code in an editor the first line of the code reads:

# syrian shell is a php evil script , please use it against Israel Only

Apparently the attackers didn’t read this line and showed no discrimination about who their targets were going to be.

The malicious script also comes with a GNU Public License disclaimer with more preamble about attacking Israel and then proceeds to allow the attacker to configure their own password for the shell.

The script then immediately starts to list privileged functions such as:

Get Real IP Address
Open Base Directory
Base64 Encode/Decode
Safe Mode (Read-Only)
Search and Count a File Name (such as index.html)
Suicide (aborts and deletes shell)
CMD Shell (Win/Linux)
Index Changer (supports multiple CMS tools)
Get Passwords (reads /etc/passwd, domainalias and shadow files)
System Info (runs netstat, arp, routes, ls, etc)
MD5 Password Hashing
Database Tools (Oracle, MS SQL, MySQL and PostGRES

Hardening

To be fully convinced that I was no longer at risk, I upgraded to the latest WP v3.3.1 on all sites, updated all plugins, disabled any that weren’t in use, created .htpasswd and .htaccess files and installed the IP Filter plugin to block a list of bad IP addresses and installed WDS Security on all sites (and corrected an y issues detected by WDS). I have since started to automate backups of the MySQL database and WP files so next time I get hacked, I can simply drop all the tables in the DB and restore from a backup.

I have definitely learned a valuable lesson in how vulnerable PHP/WP is and will stay on top of the site with updates, etc.