Saturday, June 30, 2007

Universal Phishing Filter Bypass

Well, I tried to do responsible disclosure, so I could at least claim I care about how secure users are (and get my name in some patch notes, :p), but according to Microsoft "The Internet Explorer phishing filter is not a security feature, so this is not something MSRC would track.", Mozilla haven't replied (email sent early Wednesday), and Opera haven't replied either (bug report added early Thursday), though I didn't give opera much time, I really don't think its a big issue because its not even on by default in Opera.

To better understand how the following idea can actually be utilised, and why it matters, you need to understand the point of the phishing filter. When a phishing site is first created and sent to users, the phishing filter does not know about it - the phishing filter is updated based on a blacklist of URLs which are manually entered.

The reason,the filter works is because while a phisher could encode the address to stop it being detected, or move the server, etc, etc, but all the emails they sent still have the same static blocked link. And this is the whole reason the filter works - all the emails have the same link which is blocked. This doesn't have to be the case, but I'll write something about that some other day.

To avoid this, one can do the following:

Send out phishing emails as one normally would, but instead of pointing to the actual phishing page, point to some central server, which can send your arbitrary response headers, or is under your complete control.

The page the user is sent to, actually redirects the user to an actual phishing page, either on the same server or another.

There is a loophole in the phishing filters where if a page is blocked, but instead of being loaded, it redirects the user, then the phishing warning is not displayed (the phishing warning seems to do checks after the page has been loaded, or at least the html code has).

What this means is that, the moment a phishing URL is added to the list, the phisher can easily just make it redirect elsewhere (or just encode it, and redirect to the encoded URL to bypass the filter), and viola, the link in the phishing email is now working again.

And considering all the filters do direct URL comparisons, and the redirects do not have to be static (i.e. you could use mod_rewrite to make random URLs show the same phishing page), the way current phishing filters are set up you could avoid the indefinitely.

If you want to confirm this, here are the steps I sent to MS/Mozilla/Opera on how to verify it:

1. Find a blocked URL.
- I got from phishtank

2. Point the hosts file entry for the domain to an IP.
- I pointed to

3. Create a directory/page on your server in the same place as the phishing page.
- I created /yahoo/index.php on my localhost

4. Confirm that your page is being blocked.
- I directed my browser to as usual, and it was blocked in all browsers

5. Clear the browser cache/restart the browser.
- IE and Firefox need a restart, Opera needs you to manually clear the cache

6. Edit the file to redirect to another file on the site which is not blocked.
- I created /yahoo/login.php and then used a Location redirect in index.php to redirect myself there:

header ("Location:");

7. Visit the original phishing page again.
- I directed my browser to as usual, and in both browsers, no message was shown to the user, and I was successfully redirected, even though the original page was a known phishing URL in both systems.

Note: The need to clear the cache/restart the browser would not impact an attack, because the redirecting page would never be filtered and cached in the first place, it is merely a symptom of checking that the URL is properly blocked. So if you can trust me that the URL is blocked, you can simply ignore step 4.


Kishor said...

I can think of few other ways to circumvent this.

Filter could not detect the phishing attempt when the phishing page was used in an iframe.


I was actually trying to see if google translate knows about the phishing pages. Seems it does! I could not translate these pages to other languages. But other translators may do that and phishing filters will not detect as a blacklisted URL.

Using translate you can be an International phisher :) and phish a variety of 'audience'.

kuza55 said...

That's definitely true, but the thing with that is, if the google translate URL is blocked, then the URL is no longer valid.

The whole reason what I posted above is useful is because once you have sent out a single URL, and it has been bocked, you can *then* create the redirect to a non-blocked page, and the URL which was originally sent in the email would still work and the user would not be shown a warning message.

I'm trying to get a demo setup, but while the URL has been blocked (by phishtank) now, none of the phishing filters have updated themselves yet, and so I can't show a live example yet.

strider said...

I'm curious, what about simply having rewrite rules which will redirect any url on the server to the same page and then just have a random component in the email sending script? Is something so simple enough to get past anti-phishing filters?

kuza55 said...


Yeah, yhat would definitely stop phishing filters, but I'm not sure yet, how that would impact upon users, I'm thinking if you put something like PHPSESSID= or jsessionid= or similar in the URL, then there'd be more chance of users not getting spooked off, but I haven't had a chance to test it yet, but once I do, I'll definitely post my results.

Anonymous said...

I saw this exact technique descirbed out in the wild, here

It's an outrage M$ haven't patched their browser to take account of your suggestion - having a phishing filter in IE that doesn't work lulls users into a false sense of security.

kuza55 said...

Thanks for that Anonymous :)

Though I don't think we can really blame M$ here too much; they at least responded to my email, which is more than any of the other browser makers did.

Vinícius K-Max said...

nice find!

keep this blug up! :)