I had a really interesting lunch meeting with a senior IU member of the administration on Friday. They wanted to chat about the IU Phishing incident, which I blogged about last week.
While we didn't see completely eye to eye on all issues, there was a fairly significant amount of common ground. While I felt that I had been pretty clear in my initial blog post, there seemed to be some confusion, esp. once it had been parsed by those in the media.
Thus, I'd like to clarify a few things:
1. The university 'steel' cluster was not 'hacked' through the use of a security hole. The phishers, whoever they were, logged in using compromised usernames/passwords. That is, they had somehow gotten access to valid user accounts.
This could have been done through another phishing attack, by hacking into student personal computers, or by someone leaving their gmail account open at a public computer in the library. There are plenty of other ways this could happen.
There is very very little that IT staff can do to protect computers from people who have their usernames/passwords stolen. Much can be done to fix system security flaws, but if a user chooses to keep their password on a post-it note attached to their monitor, it is very difficult to keep those bad guys out of their account.
2. There is no forensic evidence that indicates that the phishers obtained their target list (those people they'd send the phishing emails to) by looking at the /etc/passwd file on 'steel'.
Yes, the /etc/passwd file exists, contains usernames (which directly relate to an IU email account for many of the users), and is readable by all users logged in to the machine. If the phishers had wished to, they could have downloaded this file, and gotten a large number of email addressed by doing so. However, there is no forensic information which proves that they did do this.
We know that they had a a large list of targets - but how they got it, to this day, remains a mystery. We know several ways that they -might- have got it, but we do not have evidence to firmly support any of those theories.
3. Since every user who has an account on steel has access to the /etc/passwd file, it would have been quite possible for a student to login to the machine, download the file, and give it to the phishers, or share it online. The phishers wouldn't necessarily need to login to steel to get this, if they could somehow convince a student to get it for them.
4. No one knows where the phishers came from. All that is known is that they bounced their connection through a machine in China. The evidence trail stops there. They very well could have been in Bloomington, and we'd never know.
-----
I guess the main point that we both agreed on, was that this problem did not stem from IU technical staff not doing a good job. As soon as they noticed that those compromised accounts were doing bad things, the accounts were locked and the remote machine in china was blocked from connecting to the university network.
Phishing, as always, is a people problem. It is the age old art of deception moved to a new, and scarily flexible medium. The real take-home from this, I suppose, is that with even a minimal bit of information (someone's name and email address), a phisher can do some pretty significant damage. This makes the job of protecting our data even more critical, and it means that we must train the student body, our friends, and family to have their wits about them.
Monday, April 23, 2007
Wednesday, April 18, 2007
I'm not a lawyer, but....
It's been said that a little bit of knowledge can be a dangerous thing.
As I slowly learn more and more about the law, I start to have these ideas. From a computer security standpoint, they're brilliant - as they get around the problem creatively. However, as I've been told before, the law is not a machine, and it's not as simple to find the legal equivalent of a security flaw.
I had a fairly interesting idea today. Its probably rubbish, however, I think it's worth posting it - if just to stimulate discussion:
As I mentioned in my post yesterday, most state data breach laws only kick in upon the disclosure/loss of data that includes the full last name, and either the full first name, or first letter of the first name.
Lets step back for a moment. Consider the fact that all credit cards include a check digit within the card number. Thus, computer programs can be written that will tell you (without having to send the card number to a bank) if the card number is a 'valid' card number or not. That doesn't mean that the program can tell you that the card is active - merely that the card number has been typed in correctly.
Interestingly enough, if you leave off 1 digit from the credit card number, using the built-in checksum, the programs can figure out what that last digit is - due to the fact that every other combination of digits will not result in the same check digit.
This can be seen as a form of an error correction
With that explained, lets get back to the idea:
What if instead, companies kept customer info in the form of:
Complete last name: soghoian
All of first name but first letter: hristopher
Checksum of full first name: 7
There are 26 possible letters that could go at the beginning of 'hristopher' to make up my full name. However, only one of these ('c') would result in the correct calculation of check digits.
Thus, any time the company needed to look up my data, they would simply calculate the check digits for all 26 possible combinations of my first name, and would thus be able to obtain my full first name and last name.
How practical is this? It would require some time/money to implement, and wouldn't be as useful as storing the full first name due to the requirement to calculate ~13 checks (assuming random choosing of letters) each time a name is needed, but if I am right (regarding the law), then any company that implemented such a system would be able to avoid all the negative publicity and work that is associated with data breach disclosure. Perhaps this would outweigh the implementation costs?
As I slowly learn more and more about the law, I start to have these ideas. From a computer security standpoint, they're brilliant - as they get around the problem creatively. However, as I've been told before, the law is not a machine, and it's not as simple to find the legal equivalent of a security flaw.
I had a fairly interesting idea today. Its probably rubbish, however, I think it's worth posting it - if just to stimulate discussion:
As I mentioned in my post yesterday, most state data breach laws only kick in upon the disclosure/loss of data that includes the full last name, and either the full first name, or first letter of the first name.
Lets step back for a moment. Consider the fact that all credit cards include a check digit within the card number. Thus, computer programs can be written that will tell you (without having to send the card number to a bank) if the card number is a 'valid' card number or not. That doesn't mean that the program can tell you that the card is active - merely that the card number has been typed in correctly.
Interestingly enough, if you leave off 1 digit from the credit card number, using the built-in checksum, the programs can figure out what that last digit is - due to the fact that every other combination of digits will not result in the same check digit.
This can be seen as a form of an error correction
With that explained, lets get back to the idea:
What if instead, companies kept customer info in the form of:
Complete last name: soghoian
All of first name but first letter: hristopher
Checksum of full first name: 7
There are 26 possible letters that could go at the beginning of 'hristopher' to make up my full name. However, only one of these ('c') would result in the correct calculation of check digits.
Thus, any time the company needed to look up my data, they would simply calculate the check digits for all 26 possible combinations of my first name, and would thus be able to obtain my full first name and last name.
How practical is this? It would require some time/money to implement, and wouldn't be as useful as storing the full first name due to the requirement to calculate ~13 checks (assuming random choosing of letters) each time a name is needed, but if I am right (regarding the law), then any company that implemented such a system would be able to avoid all the negative publicity and work that is associated with data breach disclosure. Perhaps this would outweigh the implementation costs?
Monday, April 16, 2007
FOIA Fun. Or. How Phishers hacked into IU
This post should probably be called Indiana Public Records Act Fun - but that doesn't quite roll off the tongue.
I signed up for an Indiana University email account in March or so of 2006. Between signing up and the start of school in September, I'd never used the email address for anything, and a Google query at the time for the address came back negative.
In mid June of 2006, I received a phishing email claiming to be from the IU credit union. The Indiana Daily Student later covered this incident. The article merely mentioned that phishing emails targetting the credit union had been sent out, and that a bunch of students had typed in their info. The article didn't explain how the phishers had learned the email addresses of the students, nor who had launched the attack.
My IU email address is 'csoghoia'. Given that my email address was new, and wasn't published anywhere on the Internet, there was no way for a phisher to learn my address short of an exhaustive address space search (i.e. trying every possible combination of letters) - Unless, of course, the university was hacked, and information was stolen, or, if the university accidentally released my info. Either of these two potential scenarios were alarming, and so I began to look into the matter.
An email requesting information from IU's Incident Response Manager about how phishers had learned my email address resulted in this: "Unfortunately, I cannot comment on this activity as it relates to an active investigation. Be assured we are working aggressively to put a stop to it."
Alarm bells went off... Something phishy (ha ha) was going on.
Thus, on June 23 2006, I filed a Indiana Public Records Act Request with the University. I asked for: any and all information regarding theft or accidental loss of student data including but not limited to names, social security numbers, and email addresses. I am additionally requesting any and all information regarding any ongoing or completed investigations including those by the Office of the VP for Information Technology, of "phishing" emails sent to IU users pretending to be from the IU Credit Union. The scope for these two requests are for documents created within the last 6 months.
On January 11 2007, I received a fat envelope full of papers from the Office of the University Counsel. The response can be seen here. Most of the information was fairly boring, but there were some gems. I've scanned the interesting documents and put them online here.
Typically, when phishers send emails out - they will collect an email list of millions of email addresses, and then send the same email out to them. Thus, in an effort to get the most bang for their phishing buck, the fraudsters target major banks. The idea being, of course, that out of 5 million email addresses, perhaps 200,000 actually belong to Citibank customers. Thus, it doesn't make too much sense for a phisher to send out 5 million emails claiming to be from a small credit union in Bloomington, Indiana. It simply isn't worth it.
If the phisher can get his hands on an email list of every person in Bloomington, then sending an email to every one of those people on the off-chance that they have a bank account with one of the major credit unions in town starts to make sense. This kind of targeted phishing attack has a name: spear phishing.
And what happened in June 2006, was a case of spear phishing.
From reading the documents that I've placed online, I've been able to figure out the following:
Chinese hackers - or at least, someone connecting from a machine in China, broke into one of the accounts on the 'steel' research cluster at IU. This cluster serves the research needs of the student population, and the "about steel" page says that it has over 24,000 accounts active. It seems that most students have accounts - I have one, and I don't recall ever requesting one. Presumeably, it happens as part of the general account setup process.
Ok, so the hackers were able to gain access to Steel. What next?
Every unix machine has an "/etc/passwd" file that lists information on every active user account on the system. Steel has one of these. I just logged into steel a few moments ago to test this, and as of April 15 2007, Steel has over 30,000 user accounts listed in /etc/passwd.
With access to steel, the hackers were able to download the /etc/passwd file, and thus get a list of many many active user accounts. Your steel account name is the same as your IU email address. Thus, the hackers were able to get 30,000 email addresses.
The phishers then sent a large number of fake emails, claiming to be from the IU credit union, to IU users, directly from the steel cluser- that is, the fake emails were sent from within the IU network. A recent report indicates that between 70-80 users were duped by this attack. A subsequent attack happened in Feburary of 2007. It is more than likely that either the same phishers, or another gang using the same stolen email address list, caused this attack. We will probably continue to see attacks, every few months, using the same email list. Eventually, in 2-3 years, when most of the students on the list have graduated, will the list finally be useless. Thus, for the phishers, the capture of the email list is a gift that keeps on giving.
It's also worth noting that the very same phishers launched a similar attack against a credit union in Florida. They left a bunch of forensic evidence behind on steel which proves the link between the two credit union attacks. Clearly, these guys have found a niche (breaking into machines, gathering info, and then targeting small credit unions and banks). My guess is that it's quite profitable.
Which brings me to the most important point of this blog-post: Notification.
Indiana has a Breach Notification Law. However, it is very narrowly written to only kick in when the following information is lost:
- Sec. 3. (a) As used in this chapter, "personal information" means:
- (1) an individual's
- (A) first name and last name; or
- (B) first initial and last name; and
- (2) at least one (1) of the following data elements:
- (A) Social Security number.
- (B) Driver's license number or identification card number.
- (C) Account number, credit card number, debit card number, security code, access code, or password of an individual's financial account.
- (1) an individual's
- (b) The term does not include the following:
- (1) The last four (4) digits of an individual's Social Security number.
- (2) Publicly available information that is lawfully made available to the public from records of a federal agency or local agency.
The act only went into force on June 30 2006 - which is sadly, a few weeks too late.
For the purposes of discussion, lets pretend that the law kicked in on Jan 1 2006. In such a scenario, the university would still not be required to tell any of their students that chinese phishers had access to their email addresses. Why?
Because an email address is not covered by the law. If the phishers had stolen SSN's, then the university would be required to notify the student body...
I want to make it perfectly clear that I am not criticizing the university. They followed the law, and acted in a perfectly legally manner. My criticism, is of the law, which is weak, and ineffective.
As a side note: if the university decided to track students by their full last name and all but the first letter of their full name (i.e. "hristopher Soghoian"), as the law is currently written, the university wouldn't be required to notify students if the school were hacked into, and the entire database of student records and SSN's were stolen. Obviously, tracking students in such a way would not be very practical, but it does demonstrate that the law is fairly narrow, and doesn't cover everything.
My goal in posting this isn't to heap criticism on the university staff. The staff here are overworked, underpaid, and do their jobs as best as they can. The problem here is the law. It is broken, and needs to be fixed. We should not depend on inquisitive graduate students filing Public Records Act requests to learn about these kinds of incidents. The law should be amended so that we're told when they happen.
If you surveyed the student body, and asked them: "If the university were hacked into, and criminals were able to learn your email address, which they could later use for phishing attacks, or even to sell to spammers - would you want to be told" - I'm guessing that a large number would answer yes. Admittedly, this is a fairly loaded question - but in any case...
(As a technical aside: As things currently stand, every one of the 30,000 users who has an account on the steel cluster can get a full list of student's email addresses. This should be fixed. Any evil student could quite easily download the list and then sell it to spammers.)
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.
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:
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.
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.
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.
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.
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.
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:
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.
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.
 |
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.
 |
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.
 |
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.
 |
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.
 |
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.
Thursday, April 05, 2007
FOIA frustrations, lessons learned
I submitted a Freedom Of Information Act (FOIA) request to the FBI last month, to get "access to and copies of any and all documents (including but not limited to) memos, electronic mail, presentations, briefings, meeting notes, guidelines and policies relating or mentioning to "Tor", "onion routing", "onion router", and "anonymous/anonymizing proxy/proxies""
I received word today that my request had come back empty. This is rather shocking, since I've personally spoken to FBI agents who know about Tor - and logically, it, or similar anonymizing proxies must have come up during investigations....
It turns out that with a standard FOIA request, no matter what you ask for, or how it is phrased, the FBI only searches their database for records that have the words of interest in the subject. If an FBI agent writes a case note about someone under investigation, and Tor comes up as part of the report, you won't get it back under a simple FOIA request. Simply put, an agent has to include the word "tor" in the subject of the memo/note for it to come back during a FOIA search.
The magic words, it seems, is to ask for a "full cross-reference search". If you do this, I'm told (by the FBI FOIA people), then they will actually search the contents of all records, instead of just the subject headers..
Grrr.. 1 month wasted just to find that out.
FOIA resubmitted....
I received word today that my request had come back empty. This is rather shocking, since I've personally spoken to FBI agents who know about Tor - and logically, it, or similar anonymizing proxies must have come up during investigations....
It turns out that with a standard FOIA request, no matter what you ask for, or how it is phrased, the FBI only searches their database for records that have the words of interest in the subject. If an FBI agent writes a case note about someone under investigation, and Tor comes up as part of the report, you won't get it back under a simple FOIA request. Simply put, an agent has to include the word "tor" in the subject of the memo/note for it to come back during a FOIA search.
The magic words, it seems, is to ask for a "full cross-reference search". If you do this, I'm told (by the FBI FOIA people), then they will actually search the contents of all records, instead of just the subject headers..
Grrr.. 1 month wasted just to find that out.
FOIA resubmitted....
Subscribe to:
Posts (Atom)