IE’s Phishing Filter

The IE Blog has a post about the new Phishing Filter which will be built into IE 7. Basically, there’s a client-side whitelist and a server-side blacklist; if you turn the filter on, every URL you visit which is not on the whitelist gets sent off to Microsoft’s servers to be checked. And if you suspect a site is a phishing site, you can click “Report Phishing Site” on the Tools menu to send that URL off into a queue to be verified.

However, for privacy reasons, IE strips off the URL parameters before sending off URLs. And this is where the problems with such an approach start to become apparent. What guarantees that the web page the manual URL checker person views (requested without URL parameters) is going to be the same one that the original reporter saw?

The URLs phishers distribute by email can be mangled and made unique in many ways; DNS wildcards, mod_rewrite and query parameters are just three. Really smart phishing site implementations would continue to server the phishing content for a given unique URL to the same IP address or class C range, but send innocent content back to any different IP address. Or they could use cookies to achieve the same effect. Microsoft engineer Peter Torr lists quite a few methods of URL mangling while explaining why the phishing filter doesn’t use hashing. However, he doesn’t say that they are all quite effective at making the filter’s life difficult even without hashing.

Server-blacklist-based anti-phishing implementations put you in an arms race, and one in which the phishers hold all the cards. They have 20,000-strong botnets with automatic deployment tools; you have to check every submitted URL by hand. They can invent new ways of obfuscating and redirecting URLs; you are limited by the tools built into your deployed client. They have a large financial incentive; you are giving away a free product.

There’s no magic bullet, but I believe the correct route to take is a combination of greater SSL use (which means we need SSL vhosting), stronger certificate field verification and OCSP, combined with in-browser standalone heuristics and a sprinkling of user education. A minimal amount of the latter is IMO, sadly, unavoidable – it’s very hard to protect people who will put their credit card number into just any web form which asks for it.

10 thoughts on “IE’s Phishing Filter

  1. If we want SSL vhosting, the need for an IP address per SSL vhost has to go. Unlike Opera 8, Mozilla and Firefox (as well as OpenSSL) don’t support server name indication. This is a total showstopper in parts of the world where IP addresses aren’t as cheap as in the US.

  2. Indeed. But, I believe, Server Name Indication requires an SSLv3 HELLO, so we need to start using one of those first – and that ties in to the SSLv2 elimination programme that I’ve just started. After that, there’s a bug open on adding support for it.

  3. IE is using a combination of approaches though. It doesn’t only use heuristics which can be figured out and worked around as Mozilla Thunderbird does. It also uses a blacklist approach. There will, of course, be ways through the combination, but the combination is still better than only one or the other.

  4. The problem I can see with the blacklist is joe-jobs which can be really painfull for small business with little ressources to counter them.

  5. What get’s me the most about the whole thing is I hate the thought that MS could *potentially* track what pages I view.
    Sure, there TOS will say they don’t, but I’m still not comfortable about that.