Adam Stiles

Glad to be able to announce this - MarkMonitor has acquired CollectiveTrust. I've joined the MarkMonitor team and am looking forward to pushing our ScamAlarm client-side anti-phishing technology to the next level. That's all for now.

Wikipedia defines a parasite as "an organism that spends a significant portion of its life in... a host organism... without immediately killing it."

Phishers host their web sites using a number of methods (free hosting, shared hosting with stolen credit card, hacked servers, etc) but a common and growing method occurs when phishers take advantage of insecure web applications that allow them to upload their phishing site to run as a part of another site. In this mode, a phishing site acts as a parasite to an existing host.

Here's the flow:

1. Phisher learns about a vulnerability to a downloadable web application (this means a web app you can run on your own server). For example, older versions of Simple PHP Blog (insecure versions are still available on SourceForge) have an image file upload vulnerability. This allows remote users to upload arbitrary files to the hosting server.
2. Phisher searches for sites running the version of the vulnerable application. Many web apps have keyword strings that make it easy to find hosts running that version. I'm won't go into details, but think "powered by...".
3. Phisher finds targets, exploits the vulnerability, and uploads their own code to the server. The phishing site is then accessible to the outside world without raising any flags on the compromised host. The web application will generally continue to function normally.
4. Wash, rinse, repeat.

Why would a phisher want to run their site as a parasite to another host instead of as a standalone? At least three reason:

1. Cheap - no fake credit card data is needed, and no goofy ads forced on their sites by free web hosts.
2. Harder to Detect - some anti-phishing tools (not ScamAlarm) look at how long a given domain has existed as a clue to its phishiness. Running as a parasite can make your phishing site look old and legitimate (and sometimes even popular). The phisher can also avoid displaying an IP address as its host name.
3. Harder to Block - Blocklist providers have to block at the URL or partial URL level, not at the host level. You don't want to kill the host when you're trying to kill the parasite.

I don't mean to pick on Simple PHP Blog. Any number of other applications (blogs and photo galleries especially) are similarly vulnerable. The SPB author quickly patched the vulnerability once it was discovered. The problem is that many people downloaded and installed the older version and have never updated it.

Technorati Tags: phishing

Sunbelt BLOG describes a virus that modifies the host file on victim machines to facilitate phishing attacks. By modifying the host file, the virus ensures that users attempting to visit sites like PayPal, Wachovia, BankOne, LloydsTSB and others are directed to a phishing server at IP address 216.32.94.147.

This kind of attack represents a departure from the typical one-off phish-by-email attacks that we normally see. Not only is it a passive attack (the phisher has to wait for you to attempt to visit one of its targets), but it also requires a much smarter web site to host the attack. When a user connects to phishing site, code on the server (PHP in this case) must look at the "host" header to determine where the user intends to go (remember, all the target financial sites are hosted on the same site). Depending on the header information, the site does an internal redirect to the appropriate sub-site.

Tags: phishing, fraud

O'Reilly Network has an excerpt from the book Security and Usability that deals with phishing and user interfaces. The article is a good introduction - nothing that couldn't have been written a year ago, but a good introduction just the same.

Crypto-guru Bruce Schneier tackles phishing in a new article on Wired.

Looking for an technical introduction to a full range of phishing techniques? Check out the slides from Jeremiah Grossman's Phishing with Superbait talk at BlackHat this year. Its pretty comprehensive and has EXCELLENT visuals. Wish I could have been there.

An intelligent post from Microsoft's Peter Torr on the decision to send URLs instead of hashes to the phishing filter. I appreciate his discussion of the threats and mitigations balanced against the costs and benefits of each approach.

About a month ago I predicted the death of the IE7 phishing filter based on sketchy details of the MS implementation. Since that time, MS has also released an antiphishing plugin for the MSN toolbar and the IE blog has released more details about how the phishing filter works. After analysing the blog posts I stand by my prediction.

My previous reservations still stand and I have several others I will cover later. Here's the zinger for today: for sites that aren't on the block list, the MS approach will be easy for phishers to circumvent.

A little background. In an attempt to "anonymize" the data it sends home, IE7 removes query strings from URLs. The query string is anything after the (?) in the URL. Instead of phoning home http://example.com/?username=adam they will send home http://example.com/. Its great the MS wants to protect privacy, but they've also opened up an easy way for phishers to beat the system.

A smart phisher will return different content to end users (browsing the URL with the query string intact) than it will to the MS phishbot. The end user gets a scam site and the MS phish bot gets innocous content.

The fundamental flaw in the MS approach is that the analysis is performed on a server instead of on the client, and the client and server may be looking at entirely different content. Smart, client-side phishing detection engines like ScamAlarm don't have this problem.

You know phishing is hitting mainstream when it shows up Dilbert. Looks like Dogbert has a new hobby.

I have a prediction to make - the Phishing Filter, as currently implemented in IE7 beta 1, will be radically re-engineered (or even removed) from the final release of IE7. Keep reading and I'll tell you why.

I haven't installed IE7 beta, but I have read a blog post (and comments) on the IEBlog from the IE team that gives details about the IE7 Phishing Filter (PF).

A little background. The browser is the last line of defense against phishing attacks, and therefore the most important. Spam filters can be bypassed (and bayesian filters actually help phishers get through to likely targets), and network filters are only as effective as their most recent blocklist update. Most network filters don't understand javascript and are easily fooled.

Browsers can use two complimentary methods to defend against phishing sites.

The first method requires a block list. Whenever you initiate a navigation (click a link, type a URL in the address bar, select a Favorite) the browser checks the host or url of the requested site against a block list. If found, the browser warns the user and blocks the navigation. The advantage to blocking sites pre-navigation is that you stop users from navigating to sites that could also dump malware/trojans/etc on their machine. Pre-navigation protection is only as effective as the block list it relies upon. If your block list is out-of-date, and phishing sites come and go quickly, or you are the first user to find a phishing site then you are not protected. As block lists become more widely deployed, phishers will find ways to thwart them: dynamically generating unique urls or obfuscating urls so that every combo must be added to the block list or risk misses or false positives.

The second method is post-navigation heuristics and/or content analysis. Whenever a new page is loaded, the browser analyzes that page and tries to determine whether it is a phishing site. The earliest AP products used very simple rules to warn users based on things like geolocation or funny url characteristics. These simple rules do a decent job of detecting phishing sites, but have a high false positive rate. One downside is that the toolbar approach requires constant attention and never gives the user a definitive recommendation. Second generation anti-phishing products like ScamAlarm use content analysis and extensive rule sets to identify phishing sites. ScamAlarm heuristics currently identify over 99% of phishing sites. If you have a good heuristics implementation, you don't need a block list.

So, where does the IE7 Phishing Filter fit in? It seems that the primary tech in IE7 is a real-time block list. A real-time block list gets around the my-block-list-is-out-of-date problem by requiring the browser to phone home on every navigation request. Don't miss this. Every navigation will generate a request to an MS server, ask the MS server if the URL (or a hash of the URL or host) in question is OK, and then warn the user if there is a problem. That's a ton of traffic! If the request is synchronous, it slows down your browsing experience. If its asynchronous, then the warning may not load until its too late. The IE team likes to talk about 400 million IE users. If that number is correct, we're talking tens of billions of requests daily, all
routing through an MS server. Not only does this create tons of extra traffic and a single point of failure susceptible to denial-of-service attacks, but the privacy problems are unprecendented - do you want MS knowing the URL of every site you visit? Even hashed url/host data can be recovered by a determined data miner. I can imagine every reviewer of IE7 cautioning users to turn off the Phishing Filter because Microsoft is watching their every move on the internet.

The IEBlog also hints at a strategy to use some post-navigation rules:

[E]ven if a site hasn’t been reported yet, Internet Explorer will warn you about sites that might look a “little bit phishy” because they use some features commonly used on phishing sites.

How this works out will remain to be seen, but the tone of the description leads me to think IE will rely on first generation rules (is the site hosted on an IP address, does it use a non-standard port, is it hosted in an axis-of-evil nation?). MS doesn't sound confident that IE7 will be able to definitively identify phishing sites, just that it can recognize sites that look a "little bit phishy". This doesn't sound like a trainable system that can detect specific sites and targets as much as something that recognizes generic characteristics - the characteristics that phishers are getting more and more adept at avoiding.

The fact that MS has been working on a solution demonstrates that they think phishing is a huge problem. Its too bad that their privacy-busting implementation (and ineffective rules?) may lead users to turn it off.