Dealing with Hacked Websites

hackers-suckSimply put, hackers suck.  Over the past six to eight months, I’ve had to deal with the hacking of many former (and a few current) client websites.  All but one of the exploits came through older versions of Joomla, and the exception being an older WordPress site.  Version 1.0 of Joomla is ancient by Internet terms, and there were several security exploits discovered with it.  Add to this that there are often third party extensions with additional exploit possibilities. This environment makes it so any jackass who can write a script that searches source code on pages for specific components or Joomla references can then upload files to your server.  Ugly.  Really ugly.

The compromised websites in all cases continued to function, at least somewhat.  One hacker injected a file into the site that would in turn alter the htaccess file adding mod_rewrite rules that would redirect anyone coming from Facebook, Google and just about any other search engine or social networking site.  If one were to type the URL in directly, nothing happened.  No URLs in the search engines were altered either; the redirects in the htaccess file hijacked only people who had headers from one of these sources.  A couple of sites had files that were posting text on pages and adding new links.  One hack destroyed the ability of using the administrator section of Joomla causing a 500 error upon login.

The fix for these hacked websites depended largely on the degree that the current site’s data had to be kept or maintained.  If it was a small “brochure” website, simply rebuilding it completely on a new platform was faster than attempting an upgrade of Joomla 1.0 to one of the more modern versions.  That Joomla upgrade path is a rather crooked one; one must first upgrade to 1.5, then to 2.5 or 3.x with very different paths along the way.  There is no guarantee that any non-standard components will be kept and the template used will most certainly no longer work in the newer version.  For most people, a new site was the simplest and most direct path.

However, for those that didn’t want an upgrade — despite knowing that the site could still be hacked even after removing perhaps some of the exploits — the following was the path I took for cleaning things up:

  1. Determine what has been changed by using SSH and running the following command –

    find . -mtime -5-type f

    This will display what has been changed in the past five days.  (Change the number 5 above to whatever you need it to be to find files not added or altered by you or the client.)  Run this command at the root level of the website or above if needed.

  2. Replace the altered files with clean ones either from a backup or from a download of the original source code.
  3. Change passwords on the site and FTP/SFTP/SSH.  While not guaranteed to have been compromised, it’s just smart to do this given the exploited code.
  4. Find the exploit if you can.  Things like older versions of the JCE html editor, folders set to 777 permission levels and such were obvious things that needed updating.  Remember, the best thing is to upgrade the entire system  but if the clients doesn’t want to go there yet, or this is simply an effort to get the site “up and running” again, so be it.

For one former client, I was able to remove the exploits, then save off ever page of their website as an HTML file.  I used these saved files to make a static version of the website.  Keeping the Joomla template directory in place and the images directory, I was able to remove the Joomla CMS from their site.  This simple brochure website has had perhaps three minor updates in 8 years and had no contact form or advanced functionality within it so it really didn’t make sense to keep Joomla around.

The following websites were also very helpful to me —

http://www.ben90.com/2011/01/exploit-tmp-minisuhosin-oscommerc/

http://www.joshpate.com/2013/01/how-to-fix-hacked-by-hmei7-on-joomla-web-site/

Leave a Reply

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