Website Defacement – A Personal Account

 

hacked

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

4 Responses to Website Defacement – A Personal Account

  • Found this on my website too. Not sure how they got in. The problem seems to be insecure WordPress themes.

  • Thanks for the tips.

    I’ve recently seen a very similar thing happen on a few websites in my sphere of control, and through investigation it appeared that a vulnerability existed in one of the pluggins used throughout. A pluggin that hadn’t been update by it’s authors in the last 12 months from what we understood.

    So not only should we keep our sites up to date, but we may have to start thinking about the risks associated with older (possibly no longer developed) pluggins too.

  • Just my 2 cents, adding a bit of real world clarity to this equation.
    I ended up fixing a good number of hacked sites at Hostpappa between January through June, 2012, and all appeared to be due to client’s failing to update scripts, poor password management or easy to guess passwords, like admin 123, among other obvious user “issues.”

    My experience was that all sites were “user error” hacked, meaning none appears to be a server level hack.
    My summation: Hostpappa’s 50,000 sites appeared to have been targeted (is all). Wrong place at the wrong time…

    Just a side note on this, using Addons to host sites within a single cpanel account is a really really bad idea- for somewhat obvious reasons.

    Best Wishes,
    Jim Walker
    The Hack Repair Guy

    • I totally agree with you Jim, at least with respect to the sites I was managing. All three sites were setup initially through CPanel and only two of them were WP sites. The two WP sites were based loosely on free themes that were probably using some vulnerable widgets. I have since re-created all the themes in Artister and removed any unnecessary widgets and such.

      While I know HostPappa is not responsible for content hosted by their customers, it would be some additional value-add if they were to use a Web-Application Firewall or some other form of real-time threat intelligence to differ the attacks on their infrastructure and not force the majority of their customers, who are probably not security savvy like you or I, to build security into their applications.

      You are right, this was definately just a drive-by recon by the Kuwait Hackers group, who decided to make HostPappa an example of what could happen when the onus for network-level security is placed on the customer.

      Reputation blacklisting isn’t enough to protect 50K sites and the service provider should standardize on their defense-in-depth approach and provide some piece of mind for that majority of thier customers who are probably SMB or hosting family-related websites.

Leave a Reply

Your email address will not be published. Required fields are marked *

Are You Human? * Time limit is exhausted. Please reload CAPTCHA.