49

I have a client's site (http://changewise.biz) being redirected to a Viagra store (mywifeishappy.com). We've gone through all the usual suspects but cannot find the culprit that's causing the redirection:

  • First thing we checked all the .htaccess files; all clean.
  • Checked robots.txt; again, nothing.
  • Checked all 522 PHP files for malicious code (this is a WordPress site running at RackSpace); we did find a line of code that has a base64decode of some code in the wp-options table of the site. 76 instances of this, all of which were removed, with still no joy.
  • Went to Google Webmasters to have Google re-index the site, in case it was holding faulty index data about the site; this may take a while.

What's strange is that when I access the site via its direct URL in my browsers (http://changewise.biz) I see it fine. When the client does this in his browsers, the site ends up at Viagra. And - when both of us Google "changewise" and click the link that Google returns in its SERP, the site is redirected to the Viagra store.

Anyone with any ideas about this? I've spoken to RackSpace tech support and they can't offer any ideas; they don't see any other vulnerabilities in the hosting setup. Client is very frustrated, as am I.

Improve this question
8
  • 2
    Did you check the DNS entries?
    – Philipp
    Commented Apr 25, 2014 at 13:31
  • Yes. I used ViewDNS.info to have an initial look (I've requested access credentials to domain registrar to examine the DNS. So far, only reported issue is local nameservers don't return IP addresses (glue) along with NS records. evidently missing A records need to be added for each of the two current nameservers that point to RackSpace.
    – Lew
    Commented Apr 25, 2014 at 13:50
  • 3
    Related: security.stackexchange.com/questions/39231/… .
    – Deer Hunter
    Commented Apr 26, 2014 at 5:14
  • Did you check your .htaccess files? Since they start with a . you might miss them on an ls.
    – Polynomial
    Commented Apr 26, 2014 at 8:44
  • 1
    FWIW, the redirect target page is compromised with a javascript code packer/obfuscator, so best not to view with browser.
    – David J. Liszewski
    Commented Apr 28, 2014 at 5:46

6 Answers 6

Reset to default
40

I noticed that from a Google search, if I take the referer (www.google.com) out of the web request to changewise.biz, it does not redirect to the spam site.

If I do not take the referer out, I get the spam site (and subsequent requests always get it since it is then cached in the browser).

So I think it is not faulty old Google data, but something in your site that looks at the referer.

Your site is serving the following http response when refered from google.com:

HTTP/1.1 301 Moved Permanently
Server: Apache/2.2
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 25 Apr 2014 14:10:26 GMT
Location: http://mywifeishappy.com/
Connection: Keep-Alive
Content-Length: 305

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://mywifeishappy.com/">here</a>.</p>
<hr>
<address>Apache/2.2 Server at www.changewise.biz Port 80</address>
</body></html>
Improve this answer
4
  • 1
    +1 for a good first step. Then the OP (or the client) should check the apache files configuration (as well as any .htaccess and the like in the topmost folder of the website's hierarchy. And the index files as well.) to see which one is adding the redirection
    – Olivier Dulac
    Commented Apr 25, 2014 at 16:58
  • 1
    I second the "check configuration files" also check deeper into the PHP files. PHP can be obfuscated by base64 encoding and other means. Check log files for errors that might lead you the right way, try to wget the index and see if it is what it is supposed to be...
    – David Wilkins
    Commented Apr 25, 2014 at 18:19
  • I'm guessing there's a redirect in .htaccess
    – Polynomial
    Commented Apr 26, 2014 at 8:44
  • Yep, as mentioned above and in my question, first thing i did was check .htaccess - all of them - and robots.txt. Also checked all the index.php files. Did a GREP with various options across the entire installation, finding 78 files infected with code that does str_rotate13 and base64_decode. Got rid of all that.
    – Lew
    Commented Apr 28, 2014 at 4:31
23

I would suggest that your apache process itself is backdoored, because even access to non-existing pages with something like google\. in the referer gets redirected. E.g. like

GET /this-page-does-not-exist/ HTTP/1.0
Host: www.changewise.biz
Referer: foobargoogle.

Just search google for 'apache backdoor redirect referer' - you will find enough reports of similar problems. The best reaction would be to take the server immediately down (to save customers from getting infected and thus save your reputation) and install it again from a source known to be not affected by the backdoor.

Improve this answer
4
  • 5
    But please backup your (presumably pwnd) apache installation first, it would be nice if you could share it for further analysis if it was indeed the problem.
    – chubakueno
    Commented Apr 26, 2014 at 4:07
  • 4
    sucuri hast stuff on this
    – that guy from over there
    Commented Apr 27, 2014 at 5:13
  • 1
    To concur: when typing changewise.biz directly the website shows up fine. However, changewise.biz/foobar redirects me to http:// medtabletinc.com (not mywifeishappy.com)
    – Daze
    Commented Apr 27, 2014 at 13:44
  • Sucuri is the ticket. Thanks a LOT for this suggestion!
    – Lew
    Commented Apr 28, 2014 at 7:33
8

I had something similar a few months ago. Turns out that the problematic code was php hidden in a jpg file in the uploads folder.

Go through your uploads (including dot-hidden files) and run file on each one. make sure the sheep are all sheep, and not hiding a wolf.

Improve this answer
3

Turn off javascript and see if you still get redirected:

1) If you still get redirected then the problem is in the server-side code, and is generating a redirect (permanent and stored by your client's browser maybe).

2) If you don't get redirected, then the problem is in the javascript that is being returned - maybe check caching of javascript in the browser and make sure the site is cleaned up.

Improve this answer
4
  • 1
    Or you could just simply curl -v...
    – Stephen Touset
    Commented Apr 25, 2014 at 21:55
  • 1
    Brilliant. Yes, i disabled JS and did NOT get redirected. So now the question is which JS is causing this. Viewing JS from the browser Tools > Web Developer Extension > Information > View JavaScript shows all the JS currently loaded, but nothing in those files is doing a redirect. There's several hundred JS files in this installation, and no easy way to check since the redirect could be implemented in 101 different ways.
    – Lew
    Commented Apr 28, 2014 at 6:02
  • Or, if not a pile of JS files, then a couple of lines of JS code buried at the end of a page, using some kind of obfuscator to conceal its purpose. The malware scan identified 6 infected pages, and i found 2 that i could delete, but not in the others.
    – Lew
    Commented Apr 28, 2014 at 7:43
  • Is it feasible to check the file dates and thus narrow down your search to files which have been changed in the last few days (or whatever)?
    – Tom Chantler
    Commented Apr 28, 2014 at 8:52
2

Try renaming the public_html directory to public_html.bak or similar, then create a new fresh public_html directory with a static html page to test.

This will prove if the issue is in the site itself or database, or if it is the Apache server or configuration itself that is compromised. If the above does not solve the issue, my assumption would be that the hosting box itself is compromised.

If the above does stop the redirection, I'd re-build it with a fresh wordpress install and restore the data.

Improve this answer
1
  • 1
    Thanks for this tip. I did try this and the new static HTML file is shown. However, we've also determined that accessing the site directly is not at issue; entering the URL in the address bar takes you there. But clicking the link from a Google search does redirect. Disabling JavaScript does NOT redirect. So it still seems that there's something in the site. Probably rebuilding would eliminate the JS that's causing the redirect. Thanks for taking the time to reply - appreciate it.
    – Lew
    Commented Apr 28, 2014 at 5:57
2

This definitely is some kind of referrer hijacking. You checked the .htaccess files and PHP code but did you try to decode the base64 your found?

When your docroot is clean, you might want to check your server-config, and there is still the possibility of some kind of apache/ebury/cdork rootkit, but my first guess would be:

  • some malicious PHP include that computes those redirects if Google is found in the referrer header
  • .htaccess manipulation.

Is your version of WordPress + plugins up-to-date? Do you run some kind of plague like PLESK or WMHC or other server management software to administer your server?

edit:

if you have a clean backup, run a diff for each file to find malicious includes 'n'stuff; i hope you have a copy of the "infected" docroot?

if someone is able to alter your files on the server you shoudl also find the vuln that leads to the compromise, otherwise this will happen again.

you should also check for strange crontabs for the webserver-user (as root: crontab -l -u $webserver-user )

Improve this answer
2
  • Yes. did try to decode that base64 string. It's over 50,000 bytes long, and it features everything imaginable - file accesses, all kinds of crazy stuff. But removing all that code didn't eliminate the problem. Your theory about PHP that computes the redirect seems plausible. The .htaccess files were all clean, and that was the first thing i checked.
    – Lew
    Commented Apr 28, 2014 at 6:00
  • @Lew: see my edit
    – that guy from over there
    Commented Apr 28, 2014 at 9:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .