My Site says Viagara or Cialis in Google - Niagara Web Design | Niagara Custom Software | Niagara Web Hosting | Niagara Internet Marketing | Niagara SEO | Swhistle Soft

We hear various terms thrown around whenever a popular web site gets hacked. SQL Injection, session hi-jacking, cross site scripting, etc. Web site hacks are usually done my malicious users and in more cases than not, just to prove they can exploit a security flaw on your web site.

As web site developers, we had to recently deal with a web site hack with the sole motivation to steal web site traffic from the targeted web site. The attack caused our clients web site to be indexed by Google with false page titles, descriptions, and in some cases redirecting the traffic to a third party web site. When a regular user visited the site everything seemed normal. The HTML source was not altered in any way. So how was Google indexing the site with the false information?

The malicious user was successful at spreading hidden PHP code throughout the site, leveraged by the fact that the images folder had world writeable access and using the knowledge to upload a password protected rootkit. Please note the initial hack entry point being the images folder. This was not the end of the trail, and removing the PHP scripts from the images folder was definitely not the solution. Upon inspection of the PHP scripts it became evident that the file contained somewhat encrypted code. The code was being escaped > eval > gzinflate > base64decode which effectively hides the real source code from prying eyes. This code was also password protected so that not just anyone can use it.

In order for us to locate the real problem files in the site that were causing the redirection and not just how the redirection was being created took a little skill (and obvious knowledge of how the scripts were working). In our case, the scripts got loaded from one main entry point that we were able to locate fairly easily. Being the sole developers who manage the site we were also able to utilize file date and timestamps to determine which files were modified. Once we had this information we were able to locate the changed files, which in this case were JPEG files. That’s right! The hacker appended PHP code to the comment section of the JPEG files. The code was heavily obfuscated, much more than the main entry point, with just cause. These altered image files contained the “magic” code that resulted in 90% of the web sites Search Engine listings to be falsified.

We finally managed to remove all traces of the hack from files throughout the site. Once this was done, we re-submitted the sitemap to Google. The web site pages were once again re-indexed and the search listing started to display normally again.

Many of you might think --- great problem solved. Well, if the site was attacked and all we did was remove the malicious scripts what is protecting the site from getting attacked again?
Simple! By employing the following simple tips we are able to increase the security of the site:

1. Minimize the World writeable folders. Optimally, you don’t want to have any folders that can be writeable by the real world. However, there may be situations where you cannot avoid it. In this case, use a combination of .htaccess rules, file type limitations and your upload handling scripts.
2. There have been recent advances in code injection inside image files (i.e. comment section of files). This site identifies the problem and proposes a solution using “readfile” to echo the image to screen. This solution, however, does not protect attacks against visitors to your web site. A more thorough solution, which we have implemented, would be to strip out comments from image files.

After further investigation into the attack we determined that the redirection was based on specific criteria which help the attack go undetected a bit longer. They used HTTP headers to detect search engine bots (via User-Agent type) and redirected based on that information. This was how the scripts were able to get Google to index the web site pages with the false information, yet when a regular user visited the page everything looked fine.

In addition, if you are planning on trying to identify the malicious person using system logs, don’t expect to find a usable IP address. In our case they hid behind a TOR network, anonymous proxies, etc.

Proper monitoring and responsiveness can help to locate the sources of the issues and possible mitigation factors to such issues, keep your eyes and mind open. Once the issue has been corrected the search engines will re-index your site.

We hope this Real World case study will help you protect your sites against similar attacks.