Research Suggests Weakness in Anti-Phishing Technology
Security experts have warned for some time now that certain anti-online-fraud technology deployed by many major financial institutions may be lulling online banking users into a false sense of protection. Today, two university researchers released a demo in an attempt to prove that point.
In response to an explosion of "phishing" scams uncovered in recent years and to growing pressure for banking industry regulators, a number of financial institutions -- including Bank of America -- have rolled out services that try to provide additional assurances that an Internet customer is visiting a legitimate banking institution's Web site, not some look-alike fake. Among the most widely adopted of these is a technology called "SiteKey," which industry giant RSA Security acquired last year through its acquisition of PassMark Security Inc.
SiteKey allows banks to display a personal image of the customer's choosing when he or she logs in to their online banking account. In the event that customers try to log in from a public computer or one whose Internet address the bank has never seen associated with the user's credentials, SiteKey prompts the user for the answer to one of several pre-arranged "security questions."
The trouble with this approach, as Security Fix reported last year, is that it assumes a phishing site will not be able to act as the "man in the middle" -- in other words, that the criminals can't figure out a way to intercept and relay the user's special image or security questions to and from the legitimate banking site.
To prove their point, two researchers from Indiana University have released a proof-of-concept program to demonstrate how phishers might act as the man in the middle to defeat SiteKey's protections.
In a video showing how such an attack could be executed, doctoral student Christopher Soghoian and Indiana University professor Markus Jakobssen explain how the program would work against Bank of America's (BoA) SiteKey implementation:
"We prompt the user for her name + state of residence. That information is then sent by our server, not the user's computer, to BoA. We pass on the security question BoA asks to the user, and then send the user's response back to BoA. The bank replies by giving us the SiteKey image and the SiteKey caption. With that in hand, we're able to convince the user that we're the legitimate BoA website, and can then prompt the user for her login password, login to BoA's site, and from there, we'd have complete control over their online banking session. It is important to note that the user never directly connects to BoA, nor does the bank ever communicate directly with the user. Each party believes that we (the would-be phisher) are in fact the legitimate other end of the login session (either the user, or the bank)."
Because the attackers in this example would be logging in from an Internet address never used before by the would-be victim, it would prompt Bank of America to challenge the user to answer their secret question, which the researchers showed could also be relayed.
"Through deceit, we are able to convince the user to enter her security question, and thus get the SiteKey image. There are plenty of ways to convince her to answer the question - the elevated orange terrorist threat level, increased security requirements due to Internet fraud, or data loss by BoA's own systems. For instance, the attackers might then prompt the user: 'Due to increased security requirements, we will ask you to answer a security question at every future login attempt. Thank you for helping to make Bank of America the nation's most secure online bank.'"
Louie Gasparini, chief technology officer for RSA's Site to User Authentication group, said the Indiana University researchers' example overlooks a number of back-end technologies that financial institutions use to detect fraudulent transactions.
"What they're critiquing is just the most visible piece to this technology," Gasparini said. "There is a whole bunch of risk management and fraud detection that goes on behind the scenes so that even if a user's account does get compromised, the bank can still protect that person."
SiteKey and other user-authentication technologies have been a favorite target of Bruce Schneier, chief technology officer for BT Counterpane. Schneier agreed that while these systems can be spoofed, most scammers are liable to avoid institutions that use it. That is, he said, until a more critical mass of banks move to adopt the technology.
"If you're a criminal, you're going to go after the low-hanging fruit, the banks who aren't using this stuff," he said. "When everyone starts using this, the bad guys will change their techniques. So, this isn't going to solve the phishing problem indefinitely, but for now it will help move things around a bit."
The single most realiable way to protect yourself from falling victim to phishing scams is to never click on links that arrive via e-mail or instant message prompting you to log in to your bank account. Online banking users should type in the address of their bank in a Web browser window, and then bookmark that address for future use. In addition, both Internet Explorer 7 and Firefox 2.0 Web browsers include technology that can help alert users if they wind up at a phishing Web site.
By Brian Krebs |
April 10, 2007; 10:01 AM ET
Fraud
,
From the Bunker
,
Safety Tips
Previous: I'd Like a Double Espresso and Your Password, Please |
Next: Critical Vista Flaw Leads Patch Tuesday Lineup
Posted by: David | April 10, 2007 10:59 AM
Your report is almost a year late.
Please see the papers released last summer at this site:
Posted by: Anonymous | April 10, 2007 12:39 PM
There are no Microsoft updates today?
Posted by: A | April 10, 2007 3:11 PM
I think the basic problem is that banks here are too cheap (or reckless) to provide their clients with a hardware token. I have several accounts in Europe that come with a Digipass with which you have to 'sign' transactions. While the man-in-the-middle may still be able to listen in on the session with this approach, he would not be able to divert money in any way.
Posted by: Erik | April 10, 2007 8:07 PM
Which version of site key does this study refer to? In the initial site key, customers entered username and passwords in text boxes on a plain http home page. Then BofA moved the password box to the site key page, which has always used SSL (https) encryption. Sometime within the past year they have begun serving their home page with https. This encryption prevents man in the middle attacks.
Did BofA put the login and text pages on the home page to get more people to sign up for online banking? In their conflict between security and advertising, they initially didn't want to use SSL encryption on the home page because it was too slow when it encrypted that page with the large number and large file sizes of advertising images. Speed is not a problem for SSL encryption of the site key page because it only has one or two images.
Posted by: John | April 10, 2007 11:28 PM
The problem isn't that banks are too cheap to push out two-factor tokens for everyone. It is that in repeated surveys of users they mostly indicate an unwillingness to use them, it decreases their satisfaction with the bank, and they might take their business elsewhere.
For high-value transactions such as treasury management banks all use 2FA. They give the tokens out to the treasurer at companies, etc.
Regular users do not want to be inconvenienced. So, banks that want to follow the FFIEC guidance for doing either 2FA or "enhanced authentication" are often going the enhanced authentication route.
I started summarizing what some large financial institutions are doing here:
http://securityretentive.blogspot.com/2007/03/comparing-enhanced-authentication.html
I welcome more details on what has been implemented.
Posted by: Andy | April 11, 2007 1:57 AM
Who cares!! If the banks and security industry would start telling online customers to use https bookmarks and never to click on anything else to access sites where users conduct financial tranactions, successful phishes will be reduced. If all users used bookmarks there would be no phishes. If there are not enough successful phishes the phishers will have to find other means.
Posted by: Howiem | April 11, 2007 7:58 AM
A hardware token doesn't address the man-in-the-middle attack. The attacker will prompt for the token value, the user will type it in, sending it to the attacker, and the attacker will send it on to the bank to be authenticated.
Posted by: Jim Lippard | April 11, 2007 12:09 PM
Hi All,
Thanks for the great comments so far.
Our full writeup on this phishing attack is available here:
http://paranoia.dubfire.net
Cheers
Chris
Posted by: Christopher Soghoian | April 11, 2007 1:56 PM
HTTPS is hackable, phishable and is also not foolproof. Another myth.
Posted by: Anonymous | April 13, 2007 10:39 AM
The comments to this entry are closed.
Seems to me that the back door trojan you wrote about earlier would also allow an attacker to bypass the site key.
If they are able to see all the transactions between the browser and the end site (after the SSL has been completed) then they could see _ALL_ the Site key information and use that information.
The MIM approach is overly complex compared with the trojan, and the Trojan probably already has been done successfully.
Oh, and since the attacker knows all your information they could easily pull out money in such a way that wouldn't show up on the fraud monitoring reports, despite BoA (or any bank) best efforts.