homepage Welcome to WebmasterWorld Guest from 54.196.62.132
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque

Webmaster General Forum

    
Website HACKED - help!
Google is directing visitors to scammy site - how did this happen?
uhwebs




msg:4042156
 1:19 am on Dec 13, 2009 (gmt 0)

My website was hacked. I am not a programmer and don't know much about technical web stuff so any & all help would be greatly appreciated.

I noticed when I went to my index page, its fine, but at the very bottom in the HTML there were a ton of invisible links inserted to random sites.

So I uploaded a new (clean) index page from my computer.
But, recently this happened again.

I called my hosting company and they said the permissions on my site were set wrong (to 750 I think) although I *never* changed the permissions.

There was also a gibberish .php file in the main folder, and an .txt file.

They said to change my Root password (I have several sites on a dedicated server, all were infected) which I did.

My hosting company changed the permissions back and removed the inserted files.

Beyond that, they were little help, saying they don't offer any kind of security and I should purchase some (but they didn't say where or how to do this!). They also could NOT tell me how this happened.

Now, here's the weird thing. When I go *directly* to my site, it is FINE. Looks fixed.

But when I search for my site in GOOGLE and then click on my site-- a bunch of "anti virus" pages and scanners pop up!

First a page that was [snip] was coming up, now it is [snip] and it appears the websites that come up keep changing.

My hosting company says that Google's cache is old and it will be fixed when they crawl my site again.

Does this make sense? Why would different sites pop up when I click my site from google, not just the first (which appears to have been shut down)?

Meanwhile, my visitors are being redirected to scammy websites-- is there nothing I can do till Google refreshes the cache?

How did this happen?
How can I prevent it from happening?
I would [prefer] to have my website protected from hackers-- how can I do this? Is there server software to protect my sites from this sort of thing?

Again I am not very tech savvy, so simple explanations are helpful.

Thank you!

[edited by: phranque at 1:48 am (utc) on Dec. 13, 2009]
[edit reason] No urls, please. See TOS [webmasterworld.com] [/edit]

 

Marcia




msg:4042180
 3:00 am on Dec 13, 2009 (gmt 0)

Sounds like there's been a "sophisticated" script installed that's sniffing for Google referrers to do the redirect. Mention was made of something like this a while back in the Google forum.

Here's the thread:

Hack Redirect Analysis from Google's John Mueller [webmasterworld.com]

StoutFiles




msg:4042223
 7:05 am on Dec 13, 2009 (gmt 0)

You will likely need to wipe the entire server and have all passwords changed.

AlexK




msg:4042273
 11:58 am on Dec 13, 2009 (gmt 0)

Hi uhwebs, welcome to WebmasterWorld.

Are your pages pure HTML or PHP?

Let's try to tackle this permission issue for you. Yes, there is a technical issue to get to grips with but--if you want to run a website--you NEED to get to grips with it.

There are two things to look at:

  1. Directory permissions
  2. File permissions

The basic issue is to allow the web-server software to read, but NOT write, into any public-visible directory.

I'm going to assume here that your software is `Apache', with a user-name of `apache-user' and a group-name of `apache-group'. It does not matter what the actual software is, nor what the names are, but you do need to know what they are.

This is the sort of thing that you want to see:

ls -al 
drwxr-xr-- 7 root apache-group 4096 Dec 13 00:17 .
drwxr-xr-x 22 root root 4096 Dec 9 17:34 ..
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.html
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.php
-rwxrw-r-- 1 root apache-group 36336 Dec 12 13:17 bad_file.php
-rwxrwxr-- 1 root apache-group 36336 Dec 12 13:17 even_worse_file.php

This looks complex, but is easy when you break it down.

The first 10 characters are the permissions:

  • 1st char: type of file (`d' = directory)
  • Next 3 chars: owner permissions (here is `root')
  • Next 3 chars: group permissions (here is `apache-group')
  • Next 3 chars: everyone permissions (notice is `read-only')

These are the permission types:

  • `r' = read-permission (value = 4)
  • `w' = write-permission (value = 2)
  • `x' = execute-permission (value = 1)

Thus:
`r--' = 4
`r-x' = 5
`rw-' = 6
`rwx' = 7

The most important one is the value of the `.' (dot) file, which is the permissions of the directory that you are looking at, followed next by the permissions of the files themselves.

A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***. The files--whether HTML or PHP--can have 0640 permissions, giving read-only permission for the Webserver software. In that situation, your site can NOT be hacked.

You can get some info by putting the following into a file & uploading it, then loading it (remove after):

<?php
phpinfo();
?>

(as an example, your webserver software is usually reported under `_SERVER["SERVER_SOFTWARE"]'.

I *never* changed the permissions

If your permissions were correct in the first instance, then your server itself has been hacked.

kaled




msg:4042288
 1:11 pm on Dec 13, 2009 (gmt 0)

You should probably check the htaccess file is clean too.

Kaled.

Trucker




msg:4043057
 9:02 pm on Dec 14, 2009 (gmt 0)

Here's what I think happened.

You have a virus on your computer. (The one that pops up and says you're infected with a handful of other viruses and will fix it for something like $39.95) That virus scanned your computer for logins and passwords. The person that received the login information from the virus logged into your website and changed some files.

Your potential visitors aren't seeing google send them to scammy pages instead of your site. It's the virus doing that to you.

I cleaned a friend's computer of this virus last night. I've cleaned 3 others in the last 6 months. I fixed one website that was "hacked" like yours too.

WeWatch




msg:4043400
 1:01 pm on Dec 15, 2009 (gmt 0)

You have a number of good answers here.

First, your site was probably "hacked" originally by using a valid FTP username and password. This was stolen from a PC with FTP access to your website. The virus works in a variety of ways.

First, it knows where many FTP programs store their usernames and passwords (login credentials). When the virus infects a PC that's the first thing it looks for. Many of them store the login credentials in plain text in a file. This scenario is detectable by looking at the FTP logs. There will be strange IP addresses using valid login credentials and uploading the files you find infected.

The virus steals the login credentials and sends them to a server which carries out the infection of websites.

Second, the virus is also sometimes a keyboard logger. It waits until you type in the login credentials after executing your FTP program, records the details, sends them to a server and blah, blah, blah... This will also show evidence in the FTP log files from strange IP addresses.

Third, the virus also "sniffs" the FTP traffic leaving the infected PC. Since FTP transmits all data, including login credentials, in plain text, it's easy for it to see the details, steal them and, well you get the picture. Again, evidence in the log files.

The other way we've seen is that the virus will inject the malscript into the outgoing FTP data stream as it's leaving the infected PC. So the file on the PC looks fine. By the time it's received at the webserver, it's infected. No apparent evidence in the log files as the traffic is generated from a valid PC.

The redirects you're getting are more than likely from an infected/modified .htaccess file. These .htaccess files work in top-level way. So look at all .htaccess files on your website.

You might see something like:

RewriteCond %{HTTP_REFERER} .google. [OR]
RewriteCond %{HTTP_REFERER} .ask. [OR]
RewriteCond %{HTTP_REFERER} .yahoo. [OR]
RewriteCond %{HTTP_REFERER} .excite. [OR]
RewriteCond %{HTTP_REFERER} .altavista. [OR]
RewriteCond %{HTTP_REFERER} .msn. [OR]
RewriteCond %{HTTP_REFERER} .netscape. [OR]
RewriteCond %{HTTP_REFERER} .aol. [OR]
RewriteCond %{HTTP_REFERER} .hotbot. [OR]
RewriteCond %{HTTP_REFERER} .goto. [OR]
RewriteCond %{HTTP_REFERER} .infoseek. [OR]
RewriteCond %{HTTP_REFERER} .mamma. [OR]
RewriteCond %{HTTP_REFERER} .alltheweb. [OR]
RewriteCond %{HTTP_REFERER} .lycos. [OR]
RewriteCond %{HTTP_REFERER} .search. [OR]
RewriteCond %{HTTP_REFERER} .metacrawler. [OR]
RewriteCond %{HTTP_REFERER} .bing. [OR]
RewriteCond %{HTTP_REFERER} .yandex. [OR]
RewriteCond %{HTTP_REFERER} .rambler. [OR]
RewriteCond %{HTTP_REFERER} .mail. [OR]
RewriteCond %{HTTP_REFERER} .dogpile.
RewriteRule ^(.*)$ [URL...] of infectious website goes here/ [R=301,L]

Also, check all of your error pages. When the .htaccess file is corrupted, we usually find that the error pages (404.html, pagenotfound.html, etc.) is also infected and redirecting error pages to malicious sites. Determine how your site handles 404's and check all the webpages associated with that.

Download grepWin, if you're a Windows user, and if you have all your website files on your PC you can quickly find other infected files.

Check for the gibberish you found in that php file. It probably has this string in it:

eval(base64_decode

The hackers have also started obfuscating the php malscripts so search for:

strrev("edoced_46esab") as well. (this just does a string reverse on the code in quotes which is the same as the previous line).

phranque




msg:4044145
 3:19 pm on Dec 16, 2009 (gmt 0)

welcome to WebmasterWorld [webmasterworld.com], WeWatch!

that's a nice first post.

uhwebs




msg:4066591
 1:25 am on Jan 24, 2010 (gmt 0)

WeWatch, you were right!
Turns out there was a trojan on my computer and they got the FTP passwords through there.

And yes, the htaccess file was redirecting traffic.

I found the trojan, formatted my computer, changed all the server passwords, and everything is working & back to normal :)

Rugles




msg:4067341
 4:32 pm on Jan 25, 2010 (gmt 0)

A WebmasterWorld success story!

alahamdan




msg:4070954
 10:38 am on Jan 30, 2010 (gmt 0)

I love happy ending, thanks for all people helped here

blang




msg:4070982
 12:51 pm on Jan 30, 2010 (gmt 0)

Excellent thread, lots of good info here. Flagging this for reference.

A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***

@AlexK> Would you mind detailing the reasoning behind this? I've been a Linux user for 12 years and have acted as sysadmin on a couple of servers for almost as many, and I don't understand your logic. If the directory had group write permissions, then you've got a problem. Having read and execute perms is standard for any directory. This isn't to start an argument, I sincerely want to know if I'm missing something.

J_RaD




msg:4071010
 3:07 pm on Jan 30, 2010 (gmt 0)

uhwebs...what kind of protection are you using against such things? And why didn't it pick it up upon infection.

mack




msg:4071015
 3:15 pm on Jan 30, 2010 (gmt 0)

Be sure to change passwords for any sites you login to. Those account details may also have been obtained by the Trojan.

Mack.

sublime1




msg:4071287
 1:30 am on Jan 31, 2010 (gmt 0)

I am not an employee of, or affiliated in any way with McAffee.

However, a site I am now working on uses McAffee Scan Alert which I had never seen from the inside. I always ignored their badges and most other trust marks, but have recently come to see the service is very useful for a webmaster who pays attention, and would have been very likely to catch the problems you write about.

We did an update last week to our site and managed to let in a cross-site-scripting hole. Within a day, McAffee had notified me, and we fixed it.

Of course this service is useless if you ignore or are not in a position to fix the problems identified. And, it would not have prevented this issue, only notified you of it.

To be honest, I pretty much thought McAffee (and Symantec and their ilk) were pretty much useless.

Tom

UserFriendly




msg:4071306
 2:20 am on Jan 31, 2010 (gmt 0)

Have you positively linked the trojan is linked to site hijacking? (Not something I've heard of before.) A lot of Windows machines are infected with malware, and it may be a coincidence.

Usually when a site gets taken over like that, it's through unpatched blogging software such as Wordpress, etc, so if you are using any pre-packaged software tools on your site, check that they're the latest version.

lammert




msg:4071387
 8:09 am on Jan 31, 2010 (gmt 0)

Good point UserFriendly, because some things in this post don't add up. If the hacker had obtained the password via a trojan, there is no connection with the directory security settings on the server side because he would have entered the server as a normal user with full access rights via FTP, unless the hacker had specific reasons to alter the directory settings for future purposes.

Either the directory settings were already wrong from the beginning, or they have been changed by the attacker to create a back door via Apache to re-hack the computer once the original hole would have been closed. In the latter case there is also a big chance the hacker installed a root-kit on your server. After all it seems that you use user name root to enter your server which is a big no-no in security terms.

For the same reason, the example of AlexK is wrong:

ls -al
drwxr-xr-- 7 root apache-group 4096 Dec 13 00:17 .
drwxr-xr-x 22 root root 4096 Dec 9 17:34 ..
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.html
-rwxr--r-- 1 root apache-group 36336 Dec 12 13:17 good_file.php
-rwxrw-r-- 1 root apache-group 36336 Dec 12 13:17 bad_file.php
-rwxrwxr-- 1 root apache-group 36336 Dec 12 13:17 even_worse_file.php

It should read:

ls -al
drwxr-xr-- 7 some-user apache-group 4096 Dec 13 00:17 .
drwxr-xr-x 22 root root 4096 Dec 9 17:34 ..
-rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.html
-rwxr--r-- 1 some-user apache-group 36336 Dec 12 13:17 good_file.php
-rwxrw-r-- 1 some-user apache-group 36336 Dec 12 13:17 bad_file.php
-rwxrwxr-- 1 some-user apache-group 36336 Dec 12 13:17 even_worse_file.php

where some-user is an unprivileged user account which has only very few rights and is not associated with the user account used to run the apache server.

maximillianos




msg:4071658
 1:29 am on Feb 1, 2010 (gmt 0)

We were hacked last year. A brute forcer guessed our password. It was only by luck I noticed when browsing the history of who had logged in. We ended up buying a new server and moving completely off the hacked one. You never know what they may have done once they obtain root.

Our best solution was to totally lock down our firewall so that the only remote connections allowed were from my home IP. I used a dynamic DNS service to help manage this since my IP would change, and sometimes while on the road I might need to get on the server.

Since then we have not had any problems.... knock on wood! =)

chrisv1963




msg:4071813
 9:45 am on Feb 1, 2010 (gmt 0)

It sounds like you need a new hosting company. One of my websites on shared hosting of a certain "superb" hosting company got infected with a virus over and over again. Service was terrible. The only solution to my problem was moving the website to a new hosting company. I didn't have problems since more than a year.

lammert




msg:4071817
 10:11 am on Feb 1, 2010 (gmt 0)

The OP has his sites on a dedicated server, so it is not caused by a non-secure shared hosting setup.

pageoneresults




msg:4071999
 4:38 pm on Feb 1, 2010 (gmt 0)

The OP has his sites on a dedicated server, so it is not caused by a non-secure shared hosting setup.

Great thread! Let's discuss the potential effects of this hack. Have you checked to make sure your IP range hasn't been flagged and/or blacklisted? Do you think this will have any impact on the reputation of your IP range and/or network?

AlexK




msg:4090305
 10:47 pm on Mar 2, 2010 (gmt 0)

blang:
A 0750 permission for the dot-file is fine, ***as long as the `apache-user' does not own the directory***
@AlexK> Would you mind detailing the reasoning behind this?

Hi blang, and sorry for the long wait - have only just realised that the thread had new postings.

The intent of my comment was purely to point out that if Apache owns the directory, then PHP can post a file into it. For that reason, and as lammert pointed out, public-facing directories all want to be `0750::some-user::apache-group' at max, where `some-user' is an unprivileged user account which has few rights.

There are certainly occasions where the apache-user needs to be able to post a file on the server. Those directories need to be *above* the public directories, and the PHP scripts need to sniff for the ever-so-common `/../../' directory traversal attempts. By the same reasoning, public PHP scripts should avoid include()s and/or require()s which contain server paths that will reveal the server sub-directory structure, as you cannot guarantee that one of millions of accesses will deliver up the script text rather than a correct webpage. Placing a common above-the-public directory within the PHP Path will assist that.

Of course, if a malicious agency is able to get root on the server, the above is academic.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved