Doug Ross @ Journal

Making Phishers Solve the Captcha Problem (Updated)

The more I read about Bank of America's solution to the phishing problem, the more I believe it susceptible to man-in-the-middle (MITM) attacks. The Wall Street Journal described BofA's system, called SiteKey (or PassMark), a few months ago in some detail. The BofA site describes it as well.

As I understand it, if you haven't signed into SiteKey before, you will get a randomly selected challenge question. Once you've answered the challenge successfully, a secure cookie is deposited on your PC. Subsequent authentications from that PC will force you to view a pre-selected image that will confirm you're signing into Bank of America, rather than a spammer's zombie machine in Taiwan.

Sidebar: isn't it odd that when you go the Bank of America site, you immediately note that the page is presented in cleartext ("http://"), not SSL ("https://). The first step to combat phishers is to provide an SSL connection... first time, every time. Customers need to get used to expecting a secure connection on every BofA page. Yes, their sign-in operation itself is secure. I just think it a tad bizarre that every page isn't secure as well. Just for the customer's peace of mind.

As far as I can tell, there's no way for SiteKey to distinguish a malicious, zombie PC from a user's virgin computer. The zombie PC could present a false BofA store-front to the victim and proxy login information from the user to the bank and any resulting pages and images from the bank to the victim. This would be a classic Man-in-the-Middle (MITM) attack and SiteKey does not appear to be a valid defense against this sort of assault.

Step 4 of the BofA SiteKey page even states the following:

If we don't recognize your computer: We will ask you one of your secret SiteKey Confirmation Questions. After you answer your question correctly, we will show you your SiteKey.

Sounds like it's completely susceptible to a man-in-the-middle: the classic phisher's false store-front. Users flush their caches and/or lose their cookies all the time. A user therefore wouldn't be at all surprised to answer their confirmation questions. That's why a MITM attack against SiteKey is so logical. After reading this description, I believe banks have to make it much, much tougher on the false-storefront operators.

I believe you've got to make phishers solve the captcha problem.

A Blogger Captcha

You know captchas: they're the odd-looking images representing stretched or melted alphanumeric text that can (presumably) be read by humans, but not malicious bots.

The example at right is the kind of captcha that Google's Blogger service employs. Blogging and eail services require captchas in order to prevent spambots from signing up for their free services for mass-advertising and mass-emailing campaigns.

The challenge for systems like SiteKey is to create a captcha-like problem for phishers. I think I have the seeds of just such a solution. The idea is to make a man-in-the-middle attack bloody difficult by requiring a graphical blending operation that could only be performed by a human. And, even then, only using time-consuming photo editing software.

Educating Users

But the first order of business is education. A financial institution must educate its users to expect an "anti-fraud" checklist on the sign-in page. This checklist can be used by the customer to determine whether a bank site is the real thing... or a false phisher's storefront. The education step can be achieved through a snail-mail campaign, ATM marketing literature, and similar public relations efforts. Once customers expect the anti-fraud checklist, the next action in the campaign is to:

Squeeze the man-in-the-middle

The concept is simple. Force the man-in-the-middle (MITM) to present information specific to both the client and the server. The information must be blended -- in an image (JPG or GIF) -- using a consistent appearance for it to appear legitimate. After the user has entered a sign-in name, the anti-fraud checklist page depicted above, should appear.

The key element of the page is the GIF or JPEG image, dynamically created like a captcha, which would consist of three checklist items depicted at the top of this article.

The MITM gets squeezed by changing fonts

Why is this checklist so difficult for a MITM to present?

Checklist item #2

In a normal situation (with no MITM involved), the bank's server should be able to deduce the client's general location through IP-address-to-location mapping like that provided by Geobytes.

If the MITM is screen-scraping item #2, it will have the location of the phisher's MITM machine, not the client's real PC. For the MITM to present the correct location data, it will have to use an IP-address-to-geographic-location mapping algorithm and deduce the real user's location on its own. It must then render that -- with the server-side information provided by the financial institution -- using a consistent typeface, background color, and blending pattern.

Checklist item #3

The server has non-sensitive information about the customer (e.g., a check number that recently cleared, the last four digits of the customer's home phone-number, the customer's ZIP code, etc.) that can be presented on the page. This is called a "shared secret" that only the customer and the bank should know.

And for the MITM to retrieve the shared secret, it will have to screen-scrape checklist item #3 from the image the bank has presented. It must now attempt to merge it with checklist item #2, which it must generate on its own...

Captcha problem

Once the MITM has generated the real customer's location (item #2 - remember, it can't screen-scrape item #2!) and then screen-scraped the bank's shared secret (the item #3 part of the image), it must now blend the information graphically so that it all looks legitimate. That's the captcha.

Each time the bank site appears, its fonts are randomly changed, the font sizes are changed, the colors and patterns are changed... Everything that the real financial institution would use to present the checklist is generated randomly, but entirely consistently. A MITM attempting to proxy the information from the server -- and generate the client's location properly -- must somehow merge that information in a graphic that looks consistent to the end-user.

Without some serious artificial intelligence, the MITM is trapped having to solve a classic captcha-style problem. And I, for one, thinks that's a hard row to hoe for the phishers.