|Plesk and Horde Have Phishing Vulnerability|
Horde Webmail Is a Potential Phish Pharm
| 3:52 am on Aug 11, 2008 (gmt 0)|
Here's a WebmasterWorld exclusive because I just noticed it today, you won't see this vulnerability alert posted anywhere else.
Horde webmail is used by Plesk, which is how I discovered this problem from cutting and pasting text out of a Horde webmail screen into a blog editor. The blog post had been posted many days before I went back and to my horror, saw all of the links in the blog post were redirecting back through my webmail account!
Normally I notice those things and cut out the Horde redirect but in this instance it just slipped through the cracks.
Likewise, using the right mouse to "copy link location" from a link within a Horde email and pasting it will also result in exposing the same phishable redirector links if you aren't paying attention.
Horde uses a URL redirect filter (go.php) for all links included in the email to attempt to filter out certain bad things, for example a link in email to:
Would be turned into:
When I clicked on the links redirecting through Horde as shown above, they still worked, even in another browser, or on another machine!
What that means is anyone could phish for customers by using spam with something like this:
People reading the email would see my site in the URL and probably think it was safe to click through and that's when the fun starts.
This means people can use your Webmail server for all sorts of phishing exploits without ever hacking into your server, and your customers are particularly at risk of being phished to get account information. As a matter of fact, the URL could even be used to post spam on some other insecure site, loads of fun.
To fix the problem I dug through Horde and make a quick and dirty patch to fix the problem so anyone not logged into webmail will get the Horde login screen to avoid phish attempts.
Here's a sample of the quick patch I made to Horde on Plesk.
Edit the Horde file "go.php" that in Linux with Plesk may typically be located at:
Add the following line below the header comments in go.php but above all the other code in the file:
|require_once '/usr/share/psa-horde/imp/lib/base.php'; |
Remember, this is a quick and dirty patch and that path was the same on two of my Linux servers but yours may be different. From the Linux command line use "locate base.php" to find the explicit path to the code on your server and use that explicit path.
That will stop anyone that figures out you're using Plesk or Horde in general from using your own site as a phish pharm.
If you're using a Plesk host, you might want to ask your hosting company to apply this patch to save your site from phishing as it requires root access to the server to implement this change.
Hope this helps to secure your site.
[edited by: incrediBILL at 4:22 am (utc) on Aug. 11, 2008]
| 5:29 am on Aug 11, 2008 (gmt 0)|
Amazing how you find this stuff! The above is an example that was shown to me in reference to the Homograph Spoofing Attack I posted about a month or two ago. In fact, the "live example" shown to me looked similar to the above and used one further step of encrypting the characters just as you would in some links to make them "look official".
It makes you wonder how long the vulnerability has been there and whether or not anyone has exploited it as of yet. :(
| 5:57 am on Aug 11, 2008 (gmt 0)|
I know it's been there a few years, I've been running Horde over 3 years and never noticed.
That's why I say NOTHING, and I mean NOTHING, is truly secure.
| 1:13 am on Aug 12, 2008 (gmt 0)|
Search for "go.php?url" in google and you'll find some articles discussing other vulnerability of the script.
| 1:21 am on Aug 12, 2008 (gmt 0)|
|Search for "go.php?url" in google and you'll find some articles about this. |
Yes, there are some additional vulnerabilities with GO.PHP and I found all those before posting this. Nobody seemed to notice that it was wide open for phishing while they were looking into all the other issues.
Those patches merely cured exploit symptoms yet left the gaping hole that was exploited in the first place allowing further exploits such as phishing possible.
I simply closed the gaping hole.
All phishers have to do is scan every domain on hosting companies using Plesk for "http://webmail.example.com/horde/services/go.php" and any positive hits and they have a new phishing hole.
I'm hoping people start closing this hole in their servers ASAP.
| 3:29 am on Aug 12, 2008 (gmt 0)|
I had wondered why hackers for the past two months were looking for Plesk and Horde when it was not a part of any set-up I was involved in, so I checked about a month ago. What was happening is my hosting company was extending a Plesk option on new accounts and as you say they apparently do use Horde. It seemed like the hackers were rambling through the servers looking for the things you mention. I didn't know whether they were snooping or trying to use mail servers.
| 3:40 am on Aug 12, 2008 (gmt 0)|
There are a bazillion ways to phish - this is but one of them. There are alot of webmail programs with very similar setups.
| 3:47 am on Aug 12, 2008 (gmt 0)|
|here are a bazillion ways to phish - this is but one of them. |
Yes, but there aren't a bazillion ways to get my domain names (or any others using Plesk) on the front of the URL, short of finding a way to hack into the server, and make my customers feel comfortable clicking a link that appears to come from my site and providing their login details and perhaps even their credit card data for "advertising renewal" or some such scam.
|There are alot of webmail programs with very similar setups |
I agree, scary isn't it?
I can only report and provide patches for the products I'm using ;)
Hopefully if other products have gaping phish holes like this, someone will take my lead and close them as well.
[edited by: incrediBILL at 3:51 am (utc) on Aug. 12, 2008]
| 7:00 pm on Aug 12, 2008 (gmt 0)|
One of my ISPs uses this type of link, but the link also includes an embedded long hexadecimal number that is generated by the server. It's some sort of hash of my email address and the URL of the site being visited, plus some other unknown factor. If you alter the number, or make a new link and invent your own number, the redirect doesn't work, and all you get is "Internal Server Error 500" each time. That seems reasonably secure to me.