Powered by Blogger

22 March 2008
  Tax Phish
Internal Revenue Service
United States Department of the Treasury

After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $270,25 Please submit the tax refund request and allow us 2-6 business days in order to process it.

To access the form for your tax refund, please click here"

It's that time of year, and phishing emails are out using tax refund as a motivator for people to enter private banking information and get their identity stolen. This specific instance quoted above arrived in my inbox recently, from [] by way of I'm not exactly sure what mushrooms and roots have to do with my tax refund, nor do I really know why a computer in Amsterdam is helping out the IRS. ( is allocated to

Clicking on the link sent me to a site that forwarded to another server in Amsterdam:

Graciously, I filled out the form with some bogus data and proceeded. Of course, after claiming my refund, I have to tell the IRS where to send it:

It's staggering how much information they want. Pleasantly, there were links all over each page about the "IRS Privacy Policy"... none of which actually worked. Skipping fields was also not allowed:

Once all the information was filled in and submitted, the refund was confirmed.

The site that was hosting this phishing has been taken down, but I'm waiting for more to show up. They were using a redirection service (which is still operating), so as soon as a new copy of the site goes up, they can simply modify the redirect to get more victims. Hopefully the redirect will be taken down soon -- I am not optimistic, however, since the redirect is hosted in Venezuela.

Labels: , , , ,

10 July 2007
  webapp bummers
I recently gave a talk at Google recently entitled "Drive-By Pharming and other WebSec Bummers." I talk about the previously publicized drive-by pharming attack, and also other related web 2.0 issues, giving an overview of what we think the problem boils down to.
10 April 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

Also posted to

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 (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.

  • "" 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 and he blogs regularly at

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:

The Stop-Phishing Research Group at Indiana University,, 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.
15 February 2007
  Drive-by Pharming
With Symantec, Markus and I have developed an attack called "Drive-by Pharming" to which many people with home broadband routers are vulnerable.

In short: visiting a web page can cause malicious JavaScript to execute, changing the DNS settings on your broadband router. As a result, you cannot trust domain name resolution on a compromised router. The Solution is to set a hard-to-guess administrator password for your router.

Link to my blog post
Link to Zully's Blog Post (Symantec)
Link to the Press Release
19 November 2006
  Validating Phishers

A reader of our blog recently informed me that Chase is requiring its customers to "update their profiles." Shady enough, this was the first thing he saw when logging into his account yesterday.

Isn't this a common phishing ploy? "Please come update your account info." This clearly makes recognizing phishers hard, since now they're not the only one directly asking for your private info.

(Link to a screengrab of the site)
17 November 2006
  apwg eCrime summit
This week the APWG held an eCrime Research Summit.  I've taken a few notes from some of the talks I've seen, and posted them on my personal blog.

day 2, law and enforcement (17 Nov 2006 12:00)
Sven Karge (16 Nov 2006 13:59)
John Brozycki (16 Nov 2006 13:44)
Brad Keller(16 Nov 2006 10:12)
25 October 2006
  Airport (in)security for the masses
Bruce Schneier coined the term security theatre to describe security countermeasures that provide the feeling of security while doing little or nothing actually to improve security.

The entire airport/TSA experience is a classic example of this. Passengers are frisked, have their nail clippers confiscated, are required to remove their shoes, their belts, to put their toiletries in quart (but NOT! gallon) ziplock bags - all, essentially, so that we can see that TSA is doing something.

Yet, all the while, a tiny fraction (less than 5%) of checked bags are x-rayed, and positive matching of bag->passenger is only done for single leg flights. If you miss any of your connections (or walk out of the airport at the first stopping point), the airline will happily fly your ticking suitcase on to the next destination.

With that in mind - I now now present: Chris's Northwest Airlines Boarding Pass Generator

Using this, you can:

1. Meet your elderly grandparents at the gate
2. 'Upgrade' yourself once on the airplane - by printing another boarding pass for a ticket you're already purchased, only this time, in Business Class.
3. Demonstrate that the TSA Boarding Pass/ID check is useless.

Over the past few weeks, I've written a fair bit about Airport Security at my blog. This project stems from the research I've been documenting there.

The goal of this is to prove that the ID/boarding pass check, as currently done by TSA, is deeply flawed, and is trivial to bypass. If we want to make ourselves safer, ziplock bags and 8 dollar an hour security guards checking IDs is not the way forward.

Have fun, and be careful.