Hacked/redirected ONLY for www prefix

[coachm]

This is driving me nuts, and web company isn't being very helpful (shared server). On one of my sites, I'm getting the www.example.com pages hijacked via some phantom 302 redirects.

I've disabled everything that might be doing this, including wordpress, any other php on the site, and checked .htacces files, even deleted them.

I'm getting the problem with both my windows machine, and on my android tablet (both going through same router).

He scanned the site using several different tools and all the files, etc come up clean, and for some reason he claims the site doesn't redirect for HIM.

The only thing in common for my windows machine and tablet is the router, so I'm thinking it's a messed up apache server, or at least something upstream from me.

Any hints that I can try to figure this out?

(added: The redirects happen almost all the time, but NOT all the time)

[incrediBILL]

Have you had someone else report the same issue?

It's possible your router is hacked, as this could happen in DNS and not have anything to do with the site itself.

However, my guess is if you're running any ad networks on your server it's a 3rd party ad network that's hacked and sending the redirects.

[lucy24]

Can I assume you've tried the obvious tests that you do whenever you suspect a router issue? Plug the internet cable directly into the computer, bypassing the router. Can't do it with the tablet of course-- but if it never happens when you're not using the router, then you've got a pretty strong diagnosis. Does the problem continue after you've re-installed the router software?

[phranque]

you can take your router out by of the equation by using someone else to fetch your page.
try w3c's html validator or fetch as googlebot in GWT or try analyzing your page speed [gtmetrix.com] or...

[coachm]

Thanks for the replies. More clues. When I did an .htaccess directory from www.example.com to example.com all of my static pages work properly, but my wordpress installation (in a subdirectory) still redirects. Have disabled wordpress, but can't figure how something in a subdirectory would cause redirection in the root.

More telling, when I did the above redirection, my traffic doubled, telling me that it isn't a problem with my computer or router.

So, a server hack? Something to do with nameservers?

[wilderness]

but can't figure how something in a subdirectory would cause redirection in the root.

PHP vulnerability and/or SQL injection.

[coachm]

PHP vulnerability and/or SQL injection.

Thanks. Ok. If that effect is possible, I have a better idea where to look.

More info. I found another site owned by someone else also doing the same redirect. Another of her sites doesn't.

Also the redirect occurs with a completely empty sub-domain I've never used.

My sites are all plain html static with a wordpress blog attached. I disabled the blogs, renamed the directories, and removed ALL permissions for the wp directories to disable.

So, apart from testing from another Internet location, any thoughts on what to try next? This really looks to me like a server/nameserver hack. That's been in place for a very very long time.

[phranque]

it must be the server.
a nameserver cannot provide a 302 status code to a web request.

(i assume you have checked your server access log to insure that it was your server getting the request)

[coachm]

If there are any clues in the headers returned, this is what they look like. It's obvious what's happening, but it's not obvious HOW it's happening.

Request URL:http://www.example.com/
Request Method:GET
Status Code:302 Found
Request Headersview parsed
GET / HTTP/1.1
Host: www.example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://example.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
DNT: 1
Response Headersview parsed
HTTP/1.1 302 Found
Date: Tue, 11 Sep 2012 18:20:07 GMT
Server: Apache
Location: [scuzzballhijackingsite.net...]
Content-Length: 0
Connection: close
Content-Type: text/html

[phranque]

did you see the corresponding request at Tue, 11 Sep 2012 18:20:07 GMT in your server access log?

[coachm]

This is still ongoing. Does anyone know whether Sucuri is a legitimate web scanner? It is sometimes showing some issues, but with these things, it's hard to know who exactly to trust.

[phranque]

i see an unanswered question but i don't remember why i asked it.

sucuri is well known.

[lucy24]

Maybe checking whether the request actually reached the server as opposed to being intercepted at some point between?

[scooterdude]

Strikes me that shared hosting is cheap, if the sites important to you, in this instance, moving it pronto might be an idea

And I would NOT reinstall the files from the old host apart from a database back up of wordpress blog, and even that only having done a scan for what ought not be there, fresh install of wordpress perhaps via fantastico,

And for important sites, i'd tend to stick with hosting companies with a reputation to protect

not advice, just what i've done in the past when spooked :)

[coachm]

Hopefully, the last update on this: After weeks of figuring, I learned a bit more. The malware uses cookies, invisible frames and other things to hijack sites. Typically, it doesn't hijack that often, and it seems to use things like OS, geotargeting, whatever. So, for example, for a while the only hijacking occurred on my android tablet, but was ok on desktop.

There are other cases redirecting to quizingles but some of the reports also had malware reports bout them, so it was hard to get more details. It resembles some other hijack techniques in that if you look at the source code of the pages, you won't see anything out of the ordinary -- the javascript payloads are encoded.

It appears I've gotten rid of it, although I still don't understand how it infected things, or how it really works.

After a lot of trial and error, I discovered that if I removed the javascript counter script from a major well known provider of free and paid counter services, AND if I uploaded clean files, the infection went away. No redirects.

When I added the code back, once again, the hijacking started.

My guess is that there's an exploit somewhere -- either in a web name server, the webserver, workpress local installation, or even a password hack that IN COMBINATION with the javascript from the counter company, produces the hijack.

I've contacted the company and haven't heard back yet.

Now, I've thought I had this solved before, so I'm being cautious here, but it seems pretty consistent.

I've also decided to permanently close my self-hosted wordpress blogs. Not much traffic, and to be honest, just too many risks associated with it.

But I'm dying of curiousity as to the details of exactly how this thing infects, and works. I'll probably never know. It doesn't seem widespread enough to worry anyone.

[lucy24]

if I removed the javascript counter script from a major well known provider of free and paid counter services

+

It doesn't seem widespread enough to worry anyone.

=
Ah ha! If one necessary component is a counter, then no wonder we don't see it more often.

I used to have a counter. Think I shut it down in 1997 ;)

[coachm]

Ah. Well, might have spoken too soon. The redirect seems to be back, at least when I use my tablet. I decided to redirect my subdomain library.customerservicezone.com to customerservicezone./db in .htaccess, and it does the redirect thing, even though no files in the subdomain should be accessed.

Go figure. I still think there's something odd going on at the hostnexus end.

[scooterdude]

The redirect seems to be back, at least when I use my tablet

Sounds very like a hijack script on your tablet, on a pc i'd try hijackthis, dunno about tablets tho

en.wikipedia.org/wiki/Hijackthis

[coachm]

Absolutely not a hijack script on my machines, since others get it in other cities.

It's back. Really back.

[edited by: incrediBILL at 1:58 am (utc) on Oct 7, 2012]
[edit reason] no sticky requests, see TOS [/edit]