Am I hosting a HSBC phishing scam?
December 19, 2010 4:23 PM Subscribe
Google tells me that my domain is hosting a phishing scam. However, the URL they showed me includes directories that are not on my server. How do I fix this?
An email from Google informs me that the following URL is a phishing scam and that I am in big big trouble:
http://mydomain.com/~georg58/getyourskinnyon/files/update/Logon.htm
I've visited, and yeah, it looks like phishing. However, this /~george58/ directory (and all the subdirectories) are nowhere to be found on my server.
Potentially useful info:
- This is an addon domain, meaning the actual files for mydomain.com are located at http://myname.com/mydomain/
- Even after deleting the directory /mydomain/, the phishing URL still worked (yes, I cleared the cache), which has me really stumped.
- This hosting account includes a number of Wordpress blogs, all with their own addon domains. I have checked and all blogs are running the latest version of Wordpress and all have been checked with an exploit-scanning plugin.
- When I visit the phishing URL my favicon is clearly evident in the address bar, FWIW.
- For days my webhost has been sending me reports of excessive CPU usage, always coming from a different one of my addons/directories. I'm using a caching plugin for all my Wordpress sites, they get *very* little traffic according to both Google Analytics and Webalizer, and just today I updated the robots.txt of each site to disallow a crapload of bad bots, just in case.
- While Google Analytics does not show any traffic to the phishy URL, Webalizer does show that it (and it's .CSS file) have gotten a few hits. Which may just be me, obsessively looking at it today.
- Otherwise, all my stats on Webalizer and Analytics looks pretty normal. And no evidence of one IP constantly hitting the site in my access logs, either.
...that's all I can think of. I do have one instance of formMail.php running on the server (and being called by a .SWF). If it helps, I can provide the source code of the phishy page, which is all pretty innocuous looking HTML that mimics an HSBC login page (including a warning about avoiding phishing!).
So my question is: How is something like this possible? And, more importantly, what do I need to do to fix this?
Hope me, Santa!
An email from Google informs me that the following URL is a phishing scam and that I am in big big trouble:
http://mydomain.com/~georg58/getyourskinnyon/files/update/Logon.htm
I've visited, and yeah, it looks like phishing. However, this /~george58/ directory (and all the subdirectories) are nowhere to be found on my server.
Potentially useful info:
- This is an addon domain, meaning the actual files for mydomain.com are located at http://myname.com/mydomain/
- Even after deleting the directory /mydomain/, the phishing URL still worked (yes, I cleared the cache), which has me really stumped.
- This hosting account includes a number of Wordpress blogs, all with their own addon domains. I have checked and all blogs are running the latest version of Wordpress and all have been checked with an exploit-scanning plugin.
- When I visit the phishing URL my favicon is clearly evident in the address bar, FWIW.
- For days my webhost has been sending me reports of excessive CPU usage, always coming from a different one of my addons/directories. I'm using a caching plugin for all my Wordpress sites, they get *very* little traffic according to both Google Analytics and Webalizer, and just today I updated the robots.txt of each site to disallow a crapload of bad bots, just in case.
- While Google Analytics does not show any traffic to the phishy URL, Webalizer does show that it (and it's .CSS file) have gotten a few hits. Which may just be me, obsessively looking at it today.
- Otherwise, all my stats on Webalizer and Analytics looks pretty normal. And no evidence of one IP constantly hitting the site in my access logs, either.
...that's all I can think of. I do have one instance of formMail.php running on the server (and being called by a .SWF). If it helps, I can provide the source code of the phishy page, which is all pretty innocuous looking HTML that mimics an HSBC login page (including a warning about avoiding phishing!).
So my question is: How is something like this possible? And, more importantly, what do I need to do to fix this?
Hope me, Santa!
I'd take a look at your .htaccess file and see if there is anything fishy going on in there. Check the .htaccess file in both myname.com and myname.com/mydomain/ -- That's what I'd do. Best of luck.
posted by ejfox at 4:45 PM on December 19, 2010
posted by ejfox at 4:45 PM on December 19, 2010
Response by poster: Thanks to both of you. There is no .htaccess file in /mydomain/ and the one at the root level doesn't have anything weird in it. Just Wordpress caching stuff.
posted by EL-O-ESS at 4:58 PM on December 19, 2010
posted by EL-O-ESS at 4:58 PM on December 19, 2010
It's possible your Wordpress install itself is compromised. I don't know the technical specifics, but I've been involved in a website where an older WordPress version was infected with all kinds of creepy-crawlies.
posted by Andrhia at 5:12 PM on December 19, 2010
posted by Andrhia at 5:12 PM on December 19, 2010
I apologise for saying something obvious, but "~george58" means the home directory of user george58. So you should look in /etc/passwd file for george58, and see what homedirectory they have set, then go there. Looking for ~george58 as a directory name will not work.
posted by lundman at 5:14 PM on December 19, 2010
posted by lundman at 5:14 PM on December 19, 2010
Response by poster: Thanks, lundman, I've been trying to follow that trail with no luck. There is no /etc/ directory to check in. And my webhost uses the standard Cpanel control panel, which doesn't show evidence of any (other) users or user accounts.
posted by EL-O-ESS at 5:19 PM on December 19, 2010
posted by EL-O-ESS at 5:19 PM on December 19, 2010
Response by poster: Oops, quick followup to lundman: I had to get out of /public_html/ and go to the root, where I found /etc/mydomain/passwd/ but everything in there looks normal(?). No george58.
posted by EL-O-ESS at 5:24 PM on December 19, 2010
posted by EL-O-ESS at 5:24 PM on December 19, 2010
Have you checked your Apache config files? It could be that the directory is set up with an alias.
posted by suedehead at 6:30 PM on December 19, 2010
posted by suedehead at 6:30 PM on December 19, 2010
You could turn up the debugging output of your web server (eg the Apache RewriteLog directive), make a request to the phishy URL, and see what Apache did with it. (My guess is the malware is buried in the Wordpress php stuff, not in apache proper, but who knows.) Remember to turn RewriteLog off when you're done with it, though.
posted by hattifattener at 6:42 PM on December 19, 2010
posted by hattifattener at 6:42 PM on December 19, 2010
httpd.conf, ensure you have the following setting:
posted by rhizome at 8:02 PM on December 19, 2010
UserDir disabled...and try again. Also check for spurious handlers that may swallow ~foo before it gets to mod_userdir. Is httpd.conf (or any of its Includes) owned by the same user that Wordpress runs under?
posted by rhizome at 8:02 PM on December 19, 2010
Contact your web host. If you're using a standard virtual hosting service (where your server is shared with other people), this is as much their problem as it is yours. They don't want to be hosting a phishing site any more than you do. Plus they have far more ability to track this down in terms of tools, experience, and access than you do. Also, you don't want them to think that you're intentionally doing this, as that could cause them to pull your account. So contacting your web host and getting them involved is really the best course of action to clearing this up.
posted by zachlipton at 8:36 PM on December 19, 2010
posted by zachlipton at 8:36 PM on December 19, 2010
I bet wordpress itself is compromised, and the url rewriting in .htaccess is loading the compromised php file. I also bet, having seen similar things, that the problem is more widespread, and there is a shell script running on your server. Start combing through your log files.
posted by advil at 9:05 PM on December 19, 2010
posted by advil at 9:05 PM on December 19, 2010
Best answer: If you're on shared hosting, my bet is that this is linked to a completely separate account entirely.
Many virtual hosts have
http://anydomainthatresolvestotheproperip.com/~accountname/
Running out of accountname's hosting.
If you and I are on the same box, and you run el-o-ess.com and I run toomuchpete.com (with the obvious account names) http://toomuchpete.com/~el-o-ess/ would display the content from el-o-ess.com and vice versa for http://el-o-ess.com/~toomuchpete/.
It's possible that their logging / analytics is going by domain name instead of what accounts files are actually being run.
posted by toomuchpete at 10:23 PM on December 19, 2010
Many virtual hosts have
http://anydomainthatresolvestotheproperip.com/~accountname/
Running out of accountname's hosting.
If you and I are on the same box, and you run el-o-ess.com and I run toomuchpete.com (with the obvious account names) http://toomuchpete.com/~el-o-ess/ would display the content from el-o-ess.com and vice versa for http://el-o-ess.com/~toomuchpete/.
It's possible that their logging / analytics is going by domain name instead of what accounts files are actually being run.
posted by toomuchpete at 10:23 PM on December 19, 2010
Response by poster: Thanks, folks. I am indeed on shared hosting, so I don't have access to things like http.conf and am unable apparently to use RewriteLog, but I contacted the host back at the beginning of this and am still waiting to hear back. I'm poring over the Wordpress databases in the meantime to see if there's any obvious spam injections (which has happened before, but now I use non-standard database prefixes, change passwords often, etc). But this doesn't feel like that did, since I'm not actually seeing weird code in real pages.
The other update I can give is that this is apparently happening on the root domain as well, with the same directory structure. In other words, both the addon domain
http://mydomain.com/~georg58/getyourskinnyon/files/update/Logon.htm
AND the primary domain http://myname.com/~georg58/getyourskinnyon/files/update/Logon.htm
posted by EL-O-ESS at 10:41 PM on December 19, 2010
The other update I can give is that this is apparently happening on the root domain as well, with the same directory structure. In other words, both the addon domain
http://mydomain.com/~georg58/getyourskinnyon/files/update/Logon.htm
AND the primary domain http://myname.com/~georg58/getyourskinnyon/files/update/Logon.htm
posted by EL-O-ESS at 10:41 PM on December 19, 2010
Best answer: You almost certainly got hacked, one way or another. Wordpress vulnerability, hosting vulnerability, insecurely deployed web "file management tool", corrupt wordpress module/theme, etc.
Assuming you didn't do anything overtly dumb (i.e. file management tool, installing a suspect module or theme) then you can have a look around for some interesting artifacts.
Grep your directory tree(s) for 'base64'...
grep -r 'base64' /path/to/htdocs
if you see things like:
eval(gzinflate(base64(
or
eval(base64(
Then there's your problem.
This is the signature of a common obfuscation strategy in wordpress worm/exploit/spammy type code. Often it will be in it's own file in a gallery or upload directory, occasionally it will be injected in a valid file.
While you're at it, ensure wordpress in all instances is the most up-to-date version of the software and make sure you don't have any world writeable directories (this is necessary for "file upload" capabilities in many shared host setups and also an endless cause of trouble), to find these use the find command, something like:
find /path/to/htdocs -perm 777 -ls
To apply more reasonable permissions, adapt the above command something like:
find /path/to/htdocs -perm 777 -exec chmod 775 {} \;
If you want to make sure all the htaccess files are your own, find them:
find /path/to/htdocs -name .htaccess -ls
Then view those files as needed to determine validity.
There's other stuff to, but that's a start.
posted by Matt Oneiros at 12:37 AM on December 20, 2010
Assuming you didn't do anything overtly dumb (i.e. file management tool, installing a suspect module or theme) then you can have a look around for some interesting artifacts.
Grep your directory tree(s) for 'base64'...
grep -r 'base64' /path/to/htdocs
if you see things like:
eval(gzinflate(base64(
or
eval(base64(
Then there's your problem.
This is the signature of a common obfuscation strategy in wordpress worm/exploit/spammy type code. Often it will be in it's own file in a gallery or upload directory, occasionally it will be injected in a valid file.
While you're at it, ensure wordpress in all instances is the most up-to-date version of the software and make sure you don't have any world writeable directories (this is necessary for "file upload" capabilities in many shared host setups and also an endless cause of trouble), to find these use the find command, something like:
find /path/to/htdocs -perm 777 -ls
To apply more reasonable permissions, adapt the above command something like:
find /path/to/htdocs -perm 777 -exec chmod 775 {} \;
If you want to make sure all the htaccess files are your own, find them:
find /path/to/htdocs -name .htaccess -ls
Then view those files as needed to determine validity.
There's other stuff to, but that's a start.
posted by Matt Oneiros at 12:37 AM on December 20, 2010
Honestly, I would start looking for another hosting provider ASAP if you are paying for it. This probably has absolutely nothing to do with anything you've done, and the fact youre dealing with it from Google instead of your hosting provider kind of sucks. If it's a school or a small org or something, this stuff does happen though, and i'd use it as motivation to do your own backups on a regular basis.
posted by yeahyeahyeahwhoo at 7:48 AM on December 20, 2010
posted by yeahyeahyeahwhoo at 7:48 AM on December 20, 2010
Try this: remove your domain name from the equation. Figure out what IP address your domain names resolve to, and then visit the URLs like this:
http://111.222.333.444/~georg58/getyourskinnyon/files/update/Logon.htm
(where 111.222.333.444 is your website's IP address).
If that gets you to the same page (as I suspect it will), you can be relatively certain that this isn't a function of any file on your particular site. It's a way for phishers to out-run google. They find a shared host, open an account, then when they give out their URL, they use the domains of every other legitimate-looking website that's also hosted on the box. When that one gets tagged in google for phishing, they move to another domain (but never have to move files).
In short: if my suspicion is correct your host allowing this to continue is the problem. You should open an abuse report and/or move hosts.
posted by toomuchpete at 9:41 AM on December 20, 2010 [1 favorite]
http://111.222.333.444/~georg58/getyourskinnyon/files/update/Logon.htm
(where 111.222.333.444 is your website's IP address).
If that gets you to the same page (as I suspect it will), you can be relatively certain that this isn't a function of any file on your particular site. It's a way for phishers to out-run google. They find a shared host, open an account, then when they give out their URL, they use the domains of every other legitimate-looking website that's also hosted on the box. When that one gets tagged in google for phishing, they move to another domain (but never have to move files).
In short: if my suspicion is correct your host allowing this to continue is the problem. You should open an abuse report and/or move hosts.
posted by toomuchpete at 9:41 AM on December 20, 2010 [1 favorite]
Response by poster: toomuchpete, the URLs do indeed work if you replace my domain name with my websites' IP address.
I continue to receive generic security "tips" from my webhost about changing my password.
The one new piece of info I discovered (thanks google), is that my host apparently hosts the website getyourskinnyon.info... sound familiar? So can this user have accessed my account in some way?
Details here: http://www.markosweb.com/www/lunarmania.com/ See the section marked "Sites at same IP." One of my websites is listed there, along with getyourskinnyon.info. I've sent that info to my host.
(And yes, I will look into moving all my sites to different hosting.)
posted by EL-O-ESS at 4:17 PM on December 20, 2010
I continue to receive generic security "tips" from my webhost about changing my password.
The one new piece of info I discovered (thanks google), is that my host apparently hosts the website getyourskinnyon.info... sound familiar? So can this user have accessed my account in some way?
Details here: http://www.markosweb.com/www/lunarmania.com/ See the section marked "Sites at same IP." One of my websites is listed there, along with getyourskinnyon.info. I've sent that info to my host.
(And yes, I will look into moving all my sites to different hosting.
posted by EL-O-ESS at 4:17 PM on December 20, 2010
Response by poster: Final update before I stop relentlessly massaging my own question:
If I add a 301 redirect to my .htaccess to redirect
http://mydomain.com/~georg58/getyourskinnyon/ to google.com (or whatever), the URL continues to function with no redirection whatsoever.
posted by EL-O-ESS at 9:50 PM on December 20, 2010
If I add a 301 redirect to my .htaccess to redirect
http://mydomain.com/~georg58/getyourskinnyon/ to google.com (or whatever), the URL continues to function with no redirection whatsoever.
posted by EL-O-ESS at 9:50 PM on December 20, 2010
Ahh, sounds like your webhost has a poorly configured apache virtualhosting scheme (based on your htaccess not having precedent and the aforementioned url's existence and the correlation of the name "getyourskinnyon").
Most likely any url like /~$username will work on this server (try it with your own username, perhaps) which is a pretty shoddy way to set things up.
I'd definitely get a different host.
posted by Matt Oneiros at 10:40 AM on December 21, 2010
Most likely any url like /~$username will work on this server (try it with your own username, perhaps) which is a pretty shoddy way to set things up.
I'd definitely get a different host.
posted by Matt Oneiros at 10:40 AM on December 21, 2010
Best answer: georg58 is an account in their system and if they look at that user's files, they'll find the files above located there.
This is an apache configuration issue and it's a completely different user that's either been compromised or is dirty.
If you've given them this much info and they haven't figured it out yet, find a new host.
posted by toomuchpete at 12:42 PM on December 21, 2010
This is an apache configuration issue and it's a completely different user that's either been compromised or is dirty.
If you've given them this much info and they haven't figured it out yet, find a new host.
posted by toomuchpete at 12:42 PM on December 21, 2010
You know how you get the attention of tech-support people when this is happening to you? Call the sales line during business hours. Tell the salesperson you're going to leave for non-service (i.e. without ETF or anything like that) if they can't find someone with a clue.
posted by rhizome at 6:51 PM on December 21, 2010
posted by rhizome at 6:51 PM on December 21, 2010
Response by poster: Thank you, everyone. The host finally admitted the problem was with another user and has suspended his account. The URLs no longer work (rather, they redirect to a Suspended Account notice). I will begin the search for grownup hosting.
Future Ask-ers: using the WP Exploit Scanner plugin I was able to find some of the dirty code Matt Oneiros describes: eval(base64(withabunchofgibberish. It was in a file in my theme called admin.php, which I did not put there. Whether this was the way in or just a coincidence it was still bad, and probably a result of the stupid Wordpress theme editor which makes your theme directory writeable by default.
posted by EL-O-ESS at 10:23 AM on December 22, 2010
Future Ask-ers: using the WP Exploit Scanner plugin I was able to find some of the dirty code Matt Oneiros describes: eval(base64(withabunchofgibberish. It was in a file in my theme called admin.php, which I did not put there. Whether this was the way in or just a coincidence it was still bad, and probably a result of the stupid Wordpress theme editor which makes your theme directory writeable by default.
posted by EL-O-ESS at 10:23 AM on December 22, 2010
This thread is closed to new comments.
posted by gjc at 4:36 PM on December 19, 2010