Tuesday, April 10, 2007

A Deceit-Augmented Man In The Middle Attack Against Bank of America's SiteKey ® Service

See a video of the phishing attack in action (quicktime .mov, 700k): mirror 1, , mirror 2 , mirror 3, mirror 4

Executive Summary

We present this demonstration of a "deceit-augmented man in the middle attack" against the SiteKey ® service used by Bank of America (the underlying technology is also used by other companies). This, or a similar attack, could be used by a phisher to deceive users into entering their login details to a fraudulent website. BoA's own website tells users: "[W]hen you see your SiteKey, you can be certain you're at the valid Online Banking website at Bank of America, and not a fraudulent look-alike site. Only enter your Passcode when you see the SiteKey image and image title you selected."

We believe that this statement is not completely true, as our deceit-augmented man-in-the-middle attack shows. Whereas a normal man-in-the-middle attack identically replicates the attacked site, a deceit-augmented man-in-the-middle attack may present the user with a slightly different user interface than the regular interface. Man in the middle (MiTM) attacks are not a new threat - they have been known about for a number of years, and phishers have already used them to target Citibank and other online banks.
How a man in the middle attack works against an online bank. The user communicates with the the phisher, while believing that she is speaking to the bank. The phisher can use deceit to query the user for more information than the bank would normally ask for. Using this additional information, the phisher can communicate with the bank, while pretending to be the user.

We are putting this demonstration online to help warn the public of this risk. Just because you see your Sitekey/Passmark image, or Yahoo personalized sign-in seal, you should still be careful. Those security schemes, alone, are not enough to protect your security online. We suggest that users protect themselves from phishing threats online by adopting the following online security best practices:

  • Look for the SSL (lock) icon on the right hand side of the address bar in the browser.

  • Do not click on links in emails from anyone claiming to be your bank, financial firm, or anyone to whom you give money or personal information. Instead, type the Internet address into the address bar by hand.

  • For sites that you regularly go to (your own online bank), type the address into the Internet address bar, and then make a bookmark. Use this bookmark in the future.

  • Use anti-phishing software. Firefox 2.0 has this kind of technology built in. Users of other browsers should download one of the anti-phishing toolbars distributed by reputable groups. These include: Netcraft, Google and Microsoft.

  • If your bank has a "remember me" feature, use it. When you re-visit your bank's website, you should see your login name filled in already. While this is by no means a foolproof security feature, it is at least a signal that can help you to determine if you are visiting the bank's legitimate website.

In late 2005, federal regulators released guidance documents which strongly suggested that banks begin to roll out two-factor authentication schemes for their online banking systems. Bank of America responded by introducing it's SiteKey service, which used technology licensed from PassMark Security ® (now RSA ®, the security division of EMC ®). Shortly after the launch, some in the security community questioned the service, and voiced their concerns that a "man in the middle" (MiTM) attack could be performed to convince a user to reveal her username and password(s) to a phishing website. At the time, Mark Goines, chief marketer for Passmark told a journalist that "a man-in-the-middle attack is not possible" as SiteKey uses a "secure cookie" to link a user's PC to the Bank of America Web site. The cookie can only be read by a server with a specific security certificate and not by a malicious Web site set up by an attacker in such an attack, Goines said.

A phishing page displaying a user's SiteKey

Man in the middle attacks are possible in spite of the "secure cookies" that Passmark includes with their services. This is due to the fact that the human factor is often the most important, yet weakest link in a security system. The necessary feature that enables customers to login from computers that they have not used in the past (a new computer at home, an Internet cafe on vacation, etc) - after being prompted for the answer to one of their security questions - enables a phisher to prompt the user with her security question, and display her SiteKey image and then steal her login information.

A number of large financial institutions besides Bank of America have licensed the technology underlying the SiteKey system, including Vanguard and Pentagon Federal Credit Union. Yahoo ® uses a similar technology, which is vulnerable to the same deceit-augmented MiTM attack. Other second-factor schemes based on cookies and security questions are also vulnerable to attacks of the kind we demonstrate. Deceit is a powerful tool in the hands of an attacker - and it can be used to convince an innocent user to give away whatever authentication information that is supposed to remain secret.

The legitimate BoA login page

Man in the middle attacks are an established form of deceit, and are well understood by the computer security community. There are existing MiTM tools that work against 802.11 wireless networks and secure shell & secure web (https/SSL) connections. Russian phishers used MiTM attacks against Citibank's two-factor authentication scheme last year. A similar attack against ABN Amro (a Dutch bank) was recently revealed by the press. Researchers in the security community have previously voiced concern that the SiteKey system is vulnerable to a similar attack. We believe we are the first to provide a demo that allows people to see just how convincing a deceit-augmented MiTM attack can be.

"Phishy" BoA login page 1

A recent study by researchers from MIT & Harvard found that when they removed the SiteKey image from users’ login sessions, only 3% of the users did not continue with their login session (a group which included both subjects role-playing with fictitious accounts and passwords, and subjects using their own accounts and passwords). It was evident from their study that not everybody noticed the absence of the SiteKey image. Another recently published study showed that eBay users did not notice if their personalized greeting was removed, and that they would log in even if it was absent. The subjects in the latter study were not aware of being studied, and did use their own accounts and passwords. These findings suggest that the outcome of the MIT/Harvard study would not be affected if subjects were unaware of that they were studied, and they used their own accounts and passwords. Another important finding of the MIT & Harvard study was the fact that 100% of users typed in their password even when the site was being served over a non secure session (i.e. there was no lock icon in the toolbar).

While a more prominent display of the SiteKey image may improve the security of the scheme (as users will not so easily ignore the absence of a correct image), the scheme would still be vulnerable to man in the middle attacks, as these would truly cause the correct image to be displayed, no matter how the site is redesigned. The Stop-Phishing Research Group at Indiana University has developed a demonstration of a deceit-augmented man in middle attack against Bank of America so that members of the general public can better understand and appreciate what such an attack would look like, the vulnerability of SiteKey to this type of attack, and that phishers would be able to display users’ SiteKeys in the context of a man in the middle attack. Ultimately, we wish to highlight the need for users to pay careful attention to various characteristics of the sites they are visiting, and to take steps including the best practices noted above, to help avoid falling prey to phishers.

"Phishy" BoA login page 2 (asking security question)

We believe that a man in the middle attack against Bank of America or another institution using the technology underlying SiteKey’s would look as follows. Our demonstration is based on a concise 130 line ruby script that carries out this attack and that could be written by a phisher with average skills and in a relatively short time.

  • The user is prompted for her name + state of residence.

  • That information is then sent by the phisher's server, not the user's computer, to BoA.

  • The phisher passes on the security question BoA asks to the user, and then send the user's response back to BoA.

  • The bank replies by giving the phisher the SiteKey image and the SiteKey caption.

  • With that in hand, the phisher can obtain the valid SiteKey image from BoA, which in turn allows the phisher to present this to the user in order to convince her that they are the legitimate BoA website.

  • The phisher can then prompt the user for her login password, login to BoA's site, and from there, the phisher would have complete control over the user's online banking session.

Why does BoA allow users to get access to their SiteKey image after answering her security questions? The reason is simple. Normally, BoA knows to present the right SiteKey image to a user because it recognizes the computer that user logs in from as belonging to the user in question. This is done using secure cookies. But what happens if there are no cookies? Say that the user wants to log in to her BoA account from a computer that she has not successfully used to connect to BoA's website with before. Before sending the SiteKey image to the user, BoA will require the user to provide some evidence of her identity - the answers to the security questions. Once BoA receives these, and has verified that they are correct, then it will send the user's SiteKey image to the user. That allows the user to verify that it is really communicating with BoA, and not an impostor, which in turn, provides the user with the security to enter her password.

This is the loophole that we use in our demonstration. Through deceit, we convince the user to enter her security question, and thus get the SiteKey image.

RSA's Passmark technology is part of a complete package. They include a sophisticated risk/threat engine as part of their RSA Adaptive Authentication product. Just like the credit card companies use data mining to pick out fraudulent transactions based on signals and fuzzy data, RSA too gives banks the ability to assign a good/bad score to an IP address, and the risk that it may be an attacker and not the real customer.

If a naive attacker did deploy a phishing site similar to the one we have demonstrated in this page, it is quite likely that RSA would very quickly suspect that something bad was happening - simply due to the fact that hundreds of different users' SiteKeys would all be requested from the same IP address.

However, just as criminals use obfuscation and hiding tricks to perpetrate other kinds of online fraud, such as the use of a dual-personality page to perform click-fraud, so could phishers use obfuscation and hiding tricks to camouflage a MiTM server. This can be achieved by proxying users' SiteKey requests through the hundreds of thousands of infected/vulnerable home computers (known as "bot networks"on the Internet), through the perfectly legitimate Tor anonymizing network, or by using more complex techniques - such as using compromised home routers - using vulnerabilities recently described by Alex Tsow et al. and Sid Stamm et al. They recently demonstrated the ease with which home routers can be taken over by attacker, and have their software modified without the user's knowledge. These routers can then be used to perform click fraud, or hijack home users' web browsing sessions.

A Few Notes:

  • Source Code: To provide the factual support for our discussion above regarding the threat of a man in the middle attack against a site using the technology underlying SiteKey’s, and demonstrate how relatively easy such an attack would be to perform, we have posted an excerpt of the ruby script here. This is the portion that would connect to BoA and download the Sitekey imageB. A real attacker would incorporate other elements, such as HTML/images to mimic the bank’s website, that are not present with the code.

  • "sitekey.evil-phisher.com" does not exist. The demo was created on a university computer with a copy of the apache webserver running on the 'localhost'.

  • Our thanks to Sid Stamm for lending his javascript expertise during the early stages of this project.

  • SiteKey® is a registered trademark of the Bank of America Corporation. Bank of America has not sponsored, participated in, or approved this demonstration material.

  • PassMark® is a registered trademark of PassMark Software Pty. Ltd. Co.; RSA® is a registered trademark of RSA Security; EMC2® is a registered trademark of EMC. Neither RSA nor EMC has sponsored, participated in, or approved of this demonstration material.

  • Yahoo!® is a registered symbol of Yahoo! Inc.

About the Authors:

This is a project by Christopher Soghoian and Prof. Markus Jakobsson, both with the Stop-Phishing Research Group at Indiana University.

Christopher Soghoian is a graduate student in the school of Informatics at Indiana University. His research is focused on the areas of phishing, click-fraud, search privacy and airport security. He has worked an intern with Google, Apple, IBM and Cybertrust. He is the co-inventor of several pending patents in the areas of mobile authentication, anti-phishing, and virtual machine defense against viruses. His website is http://www.dubfire.net/chris/ and he blogs regularly at http://paranoia.dubfire.net

Markus Jakobsson is a computer security researcher and entrepreneur, best known for his research on phishing and anti-phishing. He is an associate professor in the School of Informatics and associate director of the Center for Applied Cybersecurity at Indiana University and specializes in understanding and preventing phishing. He is a visiting research fellow of the APWG, a founder of RavenWhite, a founding member of RSA eFraud Forum, and a consultant to the financial sector. He is the inventor or co-inventor of over 80 security related patents and patents pending, and a co-editor of Phishing and Countermeasures: Understanding the Increasing Problem of Electronic Identity Theft, released in 2006 by publisher Wiley, John & Sons. His website is: http://www.informatics.indiana.edu/markus/

The Stop-Phishing Research Group at Indiana University, Stop-Phishing.com, is striving to understand, detect and prevent online fraud, and in particular, to reduce the economic viability of phishing attacks. We achieve this goal through a cross-disciplinary research agenda in which we consider all facets of the problem, ranging from psychological aspects and technology matters to legal issues and interface design considerations. We are attuned to needs and concerns within the financial sector, among privacy advocates, and of common users, and are dedicated to turning the tide.


yoshi said...

As there been any usability studies on using images as an authentication mechanism?

Earlier in the year - I opened up an account with ING to observe its security features (and to get the 25 bucks) and i found a couple of things troublesome. I noticed that the image did nothing for me. I see the image and I have no idea if that is the one I chose during the signup phase. My memory just doesn't work that way. When your authentication is based on validating something is correct that you can't be sure of - it invalidates that authentication scheme.

So why go as far as pulling the image down? Why not just put up a random image from the list that is presented during the account sign up phase (which is easily grabbed by the attacker by attempting to sign up for an account)? What are the odds that someone would be fooled by that? My guess is quite a few.

Another thing I noticed had to do with the security questions. This has more to do with usability. A favorite question is "What is the city were you were born?". Lets take a city with "Saint" in its name. If you attempt to enter in "St. Louis" you will get an error message stating that you can't use special characters. Which means the period is out. My entire life I have shorten "Saint" down to "St." and now I can't use a familiar spelling because of some seemingly arbitrary decision done by the designers to, i'm sure, make things simpler. So when asked that question during some validation scheme (say from an unfamiliar machine) I am bound to get that question wrong.

Matt said...

@Tim: I believe ING (and SiteKey generally) has the image paired with a phrase you create. I think crafting a memorable, personal phrase to accompany the image is a pretty solid way to boost your confidence you are observing your shared secret with them.

Anonymous said...

Nice work! Between this and the paper "The Emperor's New Security Indicators", perhaps Bank of America and the other companies using SiteKey-like technologies will finally stop claiming security where none exists. I like how you get the user to answer the challenge question in an apparently legitimate manner.

Anonymous said...

When freedom of speech is infringed upon the government is overstepping their bounds. You don't see them shutting down websites showing you how to cook meth. I believe the patriot act should be repealed unless they can show that it's actually stopping terrorism. And just saying there hasn't been any more attacks since 9/11 is not good enough.

Tom Keetch said...

Won't MitM attacks be detectable by the banks? Since a single server accessing "SiteKeys" for tens, or hundreds, of different users will look suspicious and may help to identify phishing sites. SiteKey doesn't solve the phishing problem, but it does raise the bar.


Anonymous said...

"Won't MitM attacks be detectable by the banks?"

You assume they're paying attention...

Unknown said...

@Tom: Requests to BoA could be redirected through a network such as TOR (http://tor.eff.org/) to keep the requests coming from different (and anonymous) IPs.

kwh said...

The bottom line is that this kind of multi-factor authentication won't work because the user's intent when they visit the site isn't to ensure their security, it's to pay an ebill, check their balance, or download a statement. These are things which they do at a teller simply by producing their photo ID. Therefore, when multiple prompts and things occur which aim to increase security, they're only interrupting and distracting the user from what they intend to do, and like interruptions, they will be granted minimal attention.

When people want to ensure security, they normally are aware of risks, and engage in a securing activity; they lock the door to their house and check the doorknob as a matter of habit, or they find a proper place to chain their bike up to, which is visible and secure. This is the interface analogy which needs to be pondered.

Anonymous said...

The phishing site will not be able to present BoA's SSL certificate. A user paying attention to the browser's "lock" icon will not be fooled.

Red_Eye said...

Thank god someone finally has proven what I knew all along. That prompting a user for security information of any kind is worthless. A good php programmer should always be able to perform a MitM attack.

Anonymous said...

Until recently, Bank Of America also happily served www.bankofamerica.com under http only, including the left-side login form that asks for an "Online ID" (which defaults to an individual's Social Security number). And there was Javascript preventing users from submitting forms without entering an Online ID, so users could not simply click the submit button to move to an https page. Fortunately, they've fixed that.

Peter Lombardo said...

First thought is that once BoA sees that one IP or a small pool of IPs is logging in with 200+ more usernames, it should cut service and add those IPs to a deny list.

It's not a fix but a simple deterrent BoA should have in affect already.

The 'bad-guys' would then have to use a larger range of IPs which isn't impossible but is more work and ups the deterrent/difficulty factor.

Unknown said...

"The 'bad-guys' would then have to use a larger range of IPs which isn't impossible but is more work and ups the deterrent/difficulty factor."

Multiple IPs are not a problem for phishers at all. They use hacked PC's, and use them as man-in-the-middle proxy servers to steal identities.
They use round robin DNS to point users to different IPs.

Anonymous said...

I made a mockup of this MITM attack to BofA right after I was required to accept sitekey to continue accessing my account a couple years back. Anyway, all the MITM phisher needs to do it use their botnet to proxy the image requests to BofA, or simly use Tor if you don't have your own personal Botnet yet.

Anonymous said...

use a larger range of IPs

The artcile mentions the use of bot-nets for this purpose. With a huge number of compromised machines that can route traffic to the web site blocking by IP won't be useful for long, if at all.

Anonymous said...

A lot of "smart" spammers/phishers are already using end users computers to server their websites + DNS.

Chances are the computer that is going to Bank of America on behalf of the phisher goes to Bank of America for the real owner of the PC as well.

Anonymous said...

Until recently I was a security consultant for mostly community banks ($10 million to <$1 billion in assets with state charters).

I vehemently argued throughout 2005-2006 to my clients that adopting adaptive authentication such as sitekey/passmark was not a solution to phishing.

Adaptive authentication is *not* multifactor authentication. At best it is 1.x-factor authentication: it still requires you to only know things, and not have or be things, but requires you to know more things than is traditionally required.

My last consulting gig I had a very long argument with the client spelling out this very attack and they just didn't think it was actually possible for an attacker to go to all this effort "just" to steal their customers' information. And why would anyone attack their little bank anyway? Uh, because you have money in it and are small so you are probably poorly defending that money?

The only solution to bank phishing remains the implementation of true multifactor authentication or one-time pads/passwords.

The FDIC simply caved to pressure from big banks when they allowed adaptive authentication to meet their requirements for multifactor authentication.

I commend the authors of this paper for spelling out what many of us in the field have known and been arguing for the past couple years. Hear, hear!

I am sharing this with my old colleagues to spread the word an up the pressure on the feds to no longer accept this technology as adequate for mitigating the risk of phishing.

Anonymous said...

@ Tom Keetch

The sophisticated attackers will use bot nets or anonymizers. I'm sure many of those bots will also belong to legite customers.

Trying to save this technology by blocking IPs simply is not a winning strategy.

Anonymous said...

The funny thing is that numerous banks in Poland (where I come from) adapt two-factor authentification in form of password charts or rsa tokens, or some other electronic solutions like that. My bank asks me to pay about 5 GBP / year for account with hell lot of stuff and a rsa token.

On the other hand in the UK (where I live) a lad who was opening my account at Barclays made slightly confused expression when he heard about tokens. "So it's like a small calculator? And you punch code there? RSA tokens?"..

No wonder that in the UK frauds are such a problem if the security is poor. And is even poorer than most ppl think. I had insight in some of the security "solutions" employed by major international banks as I work for a company providing crypto hardware.. and it's ridiculous what these ppl do.

They only want to get legislation compliance and nothing more.

Anonymous said...

I don't understand why everyone is so concerned with all the phishing techno-babble. Bookmark an https page for each site where you conduct financial transactions and never use anything else to access the site. What's so hard about that?


Anonymous said...

I quite agree with John Rodenbiker.

The sad thing here is that we've had asymetric encryption systems for years, and use them every day, even when accessing these very banking sites. Every major browser is capable of storing a signed certificate and a corresponding private key that would make MITM attacks pointless, and yet we don't use it.

Rory McCune said...

I actually think that parts of the RSA adaptive Authentication model do react well to phishing threats and could do well against these types of attacks.

Using the data mining style (a la credit card systems like hunter) authentication it should be possible to build up a profile of "usual behaviour" for a given customer.

So for example "Joe usually logs on from one of 2 or 3 IP addresses geo-located in the US, the evening one corresponds to an ISP leased address and the daytime ones correspond to a company owned netblock".

All this information is fairly easily accessible from traffic that the instituction will see.

Now even if the phisher bounces the traffic through a botnet or TOR to prevent all the MITM'd traffic from coming from one IP address you'll still see very odd patterns which could flag a response from the system, along the lines of "hello Joe could you please enter the code that we've just texted to the mobile phone we have on file for you to confirm the new payment you've set-up"

In this model the role that sitekey serves is to force the attacker to do a flat MITM attack in the first place, which should make the traffic more noticeable.

Anonymous said...

Adaptive Auth is truly multifactor authentication (MFA) as required by the FFIEC. Instead of forcing a user to carry around a token (like a RSA SecureID key) it is reading approx. 30+ variables from the user's hardware device (ex: desktop PC, laptop, etc.) in an attempt to create a unique id (digital fingerprint) of that device. In so doing, they (RSA) are attempting to make the device (the customer's PC) into the 'token'. It is also taking IP geolocation and other variables into consideration and will block any access attempts that present too high of a risk score. Ultimately the pix and captions are there as a secondary measure (and to make the consumer feel better).

All of this stuff is configurable by the banks. You see, the banks must comply with the federal regulations, but they don't want to inconvenience their customers. It (Adaptive Auth) can (if the institution wants to configure it to do so) block access altogether, logging the attempt and sending an e-mail to the customer at a predefined e-mail address, or even supply a challenge question via a automated phone call before giving a customer access, but this is all dependant upon the institution choosing to use those features of the Adaptive Authentication product.

RSA's product is capable of stopping this type of attack, especially if you were to also implement something like the PhishingNet application from the 41st Parameter (http://www.the41.com/site/solutions_phishing.html) in combination with Adaptive Authentication, but the institutions have to choose to use a configuration that is strong enough.

Anonymous said...


UK banks (including Barclays) are now increasingly using tokens.

The issue is that tokens are still able to be affected by MITM attacks.