Post Mortem of a Hack…

We had a call from a client recently that said that their site was hacked and it was serving up content not associated with them. We were a bit surprised by this as we monitor the site AND we also look for specific keywords to prevent this sort of hijack. Our immediate reaction was to investigate the cause of the hack but as the “redirected content” was of an adult nature, the client themselves rolled back the changes without keeping a copy of the hacked files. This left us a bit in the dark and with the monitoring software also “blind” to the change we had nothing to go on with.

What happened next was rather surprising: while trawling through the logs to see if we could find something of note, the hacker got in again and redid the hack. Quite nice of him/her to do that while we were watching as we then had a timeframe to work with (within 15 minutes) AND we could see the files that had changed.

Once we had that information we quarantined the changes, rolled them back and blocked the hacker’s IP address so we had stability and could investigate further.

What we found was a very sophisticated hack that targeted the .htaccess files on the server and setup a redirect that excluded MOST external monitoring solutions based on HTTP_USER_AGENT. The “polluted” .htaccess was quite extensive:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} …467 browser agents listed!… [NC,OR]
…some other conditions applied…
RewriteRule ^(.*)$ <<site>> [L,R=302]

As our monitoring system uses their own “UserAgent” setting this was not recognised by the HTTP_USER_AGENT pattern and therefore did not see the change to the site – so we never got the alert that the site had been altered.

Digging a bit deeper we found the root cause of the hack: an out of date WordPress installation with a misconfigured theme that allowed upload of PHP files that could then be run. This went searching for web application folders that had files that could be overwritten. While the client had “secured” their WordPress files by executing a chmod -w * they had not also executed that on the .htaccess files (as these are not picked up by the “*” pattern match).

Remediation Steps:

  1. Upgrade WordPress, the Plugins and Themes to the latest version
  2. Secure the .htaccess files
  3. Ensure that the wp-uploads directory does not allow server execution ANY files

Result:
We learnt a valuable lesson here and will be applying some changes to our standard setup procedures across ALL clients (whether they use WordPress or not). We are also reviewing the logs of the attack with a third party to see if we can track back to the individual(s) concerned.

Bookmark the permalink.

Comments are closed