Slashdot Log In
Phishers Defeat Citibank's 2-Factor Authentication
Posted by
timothy
on Tue Jul 11, 2006 04:18 AM
from the time-is-of-the-essence dept.
from the time-is-of-the-essence dept.
An anonymous reader writes "Crypto experts and U.S. Government regulations (FFIEC) have been pushing the need for financial Web sites to move beyond mere passwords and implement so-called "two-factor authentication" — the second factor being something the user has in their physical possession like a token — as the answer to protecting customers from phishing attacks that use phony e-mails and bogus Web sites to trick users into forking over their personal and financial data. According to a Washington Post Blog, 'SecurityFix,' phishers have now started phishing for the two-factor token ID from the user as well. The most interesting part is that these tokens only give you one minute to log in to the bank until that key will expire. The phishers employ a man-in-the-middle attack against the victim and Citibank to log in via php and conduct money transfers immediately when logged in." (An update to the blog entry notes that the phishing site mentioned has since been shut down.)
Related Stories
[+]
IT: Next Gen Phishing Improves on Simple Spam 112 comments
An anonymous reader writes "ZDNet has a writeup about the next generation of phishing. According to the article, as anti-spam engines improve and user education levels increase, phishers will find it easier to hack into web servers and deliver password stealing trojans using browser vulnerabilities or Web 2.0 technologies than spam. Tom Chan from Messagelabs is quoted: 'They are trying to compromise poorly protected Web sites — they basically go in and enter their own code into that Web server,' said Chan, who explained that victims of this new phishing era would not have to do anything wrong in order to get hooked. 'You have gone to a legitimate Web site, you have not made a mistake and done everything right, but then your information gets compromised... because [the phishers] have taken over servers that belong to other people.'"
[+]
IT: Can Banks Shift Phishing Losses to Customers? 425 comments
1sockchuck writes to mention a Netcraft article wondering who should bear the brunt of phishing costs. A group of customers with the Bank of Ireland recently had $202,000 drained from their accounts by phishers. The bank initially resisted the request to refund their money, but allowed it after a suit was threatened. From the article: "The Bank of Ireland incident is one of the first public cases of a bank seeking to force phishing victims to accept financial responsibility for their losses, but it likely won't be the last. Phishing scams continue to proliferate, as Netcraft has blocked more than 100,000 URLs already in 2006, up from 41,000 in all of 2005. Financial institutions continue to cover most customer losses from unauthorized withdrawals. But after several years of intensive customer education efforts, the details of phishing cases are coming under closer scrutiny, and the effectiveness of anti-phishing efforts taken by both the customer and the bank are likely to become an issue in a larger number of cases." So, should a bank be forced to pay back a customer who has lost money to phishers? Or is it ultimately the customer's responsibility to make educated use of technology?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Good. (Score:5, Interesting)
No Good (Score:2)
Re:No Good (Score:5, Informative)
Parent
Re:No Good (Score:3, Interesting)
eg. There's a virus going around that reads "This is an encryted email from AOL.. click on the attachment to read it".
Telling users that encryption is somehow better is just going to leave them open to that kind of attack.
Re:Good. (Score:3, Interesting)
Re:Good. (Score:5, Interesting)
There is, it seems, no winning.
Parent
Re:Good. (Score:3, Insightful)
Having said that, with current methods, maybe a 'someone just transferred $1000 [such an arbitrary number, don't you think?], please login in the next 24 hours to cancel this transaction' might be an effective phishing technique, rather than the old 'we los your details, oops!' tactic; h
Re:Good. (Score:2)
Rabobank security (Score:4, Interesting)
Phishers may be able to coordinate up to the point of this validation, but if one suddenly had to enter an additional verification number of, e.g. "2000.00" (minus the decimal point), it'd be very hard to use phishing for large amounts of money.
Then again, I also have other accounts at two other banks, both of which require only a one-time, 5/6-digit, non-changing, numeric password.
Re:Rabobank security (Score:3, Interesting)
Re:Rabobank security (Score:4, Interesting)
No it will not.
This is an example of how the man in the middle attack would occur on any Swedish bank
Hello, welcome to CitiBank, please insert your account number and the response to the following challenge: 8022 8429
- "Uhm, ok" (login via man in the middle)
There was a problem, please try again with the following challenge: 2842 2020
- "Oh, my bad" (add phising account to users account allow list)
You will need one more challenge/response pair however, which you can get using:
- A third login problem
- Any action performed by the user that would require the response/challenge usually
- Information about "heightened security" and the need to re-verify the identity.
- Information about an e-visa/new savings account/free stocks or anything that would potentially require a challenge
So this is very possible.
This can be solved using client side certificates tho'.
Parent
Re:Rabobank security (Score:2)
Not quite all. Eg Handelsbanken uses certificates instead and is thus safe from MITM attacks.
Re:Rabobank security (Score:3, Insightful)
Are you surprised? (Score:3, Insightful)
Further down the road though, this is why technology leaders need to standardise authentication tokens to include some kind of two way verification
Something like this:
mybankcom - 9 -
The browser implements a "token box," when a post is attempted with said box the domain gets stripped of all special characters (up to the path) and then compared to the first part of the token. If they are case insensitively identical then the browser will submit the rest of the token (the pseudo random number) to the web-site.
The token box would have to look unique and be very difficult to clone... Which might require it to jump out from the main content window, but that is a problem for browser UI developers and beyond the scope of the problem.
Re:Are you surprised? (Score:4, Interesting)
SSL (and other such certification systems) present a trust problem:
When I connect to Alice, she presents a certificate which is signed by Bob. This tells me that Bob has verified that Alice is who she says she is. All very good you might think... except why the hell should I trust Bob? Maybe "Alice" is really Charlie pretending to be Alice and Bob signed the certificate because Charlie paid him a whole heap of cash. Or maybe Bob just didn't actually bother to check before signing the certificate. Either way, I don't know Bob and so he hasn't earnt my trust.
In this case, Bob is someone like Verisign - a large corporation who has been paid a reasonably large amount of money by Alice. If there's one thing I've learnt it's that most large corporations are fundamentally untrustworthy, especially when they're receiving bundles of cash from someone.
This kind of trust problem is not easilly solvable (if it's actually solvable at all). One potential way to do things is have a social network - each person signs the certificates of each of their friends and assigns a "trust score" showing how strong their trust relationship is. When I want to see how trustworthy Alice is, I traverse the network if signatures between me and Alice and can calculate the end "trustworthyness" from the scores of all the interconnections in the network. The problem here is that there usually aren't that many hops between any 2 people in the network - I might trust Bob and Bob might trust Alice, even though *I* don't trust Alice.
Parent
Re:Are you surprised? (Score:3, Insightful)
phishing preys on ignorance (Score:5, Insightful)
Re:phishing preys on ignorance (Score:2, Interesting)
Re:phishing preys on ignorance (Score:2)
Lots of broad, generalizing statements. Those same people might care a lot about their family and visit their brothers and sisters regularly. They may also have a big savings account for an early retirement. Things you may not care about. I'd like to scream to you: "WAKE THE FUCK UP AND STOP MAKING STUPID GENERALIZING STATEMENTS!" at the top of my lungs.
Re:phishing preys on ignorance (Score:3, Funny)
Man in the middle will always work (Score:3, Insightful)
Re:Man in the middle will always work (Score:2)
Re:Man in the middle will always work (Score:3, Informative)
Re:Man in the middle will always work (Score:2)
Re:Man in the middle will always work (Score:2)
Re:Man in the middle will always work (Score:3, Informative)
No, it doesn't. You can change hardware (and even platforms) all day to your heart's content. What you CAN'T do is change the public key. If you, for example, uninstall ssh, and the uninstall removes the keys, and then you re-install ssh and regenerate the keys, you will get this message.
carding (Score:2)
Re:carding (Score:2)
They will Phish for every required parameter (Score:2)
The phishers can also mimic the error path if the token is disallowed or mis-typed.
This is not an easy problem to solve!
Perhaps if banks signed their emails (Score:5, Insightful)
Almost all email clients support s/mime these days, all you and the banks have to do is sign up to a certificate authority and install a certificate. They can be acquired for free.
Re:Perhaps if banks signed their emails (Score:2, Insightful)
2. Because of #1 the only thing a cert proves is that the hostname matches what's in the cert.
3. Phishers have been using faked yet secure websites for years now they'll just switch to emails.
Certs are worse than useless, they're misleading.
Re:Perhaps if banks signed their emails (Score:3, Insightful)
As an aside, many banks are now using DKIM to sign their messages at SMTP time. It's up to the recipient to verify the signatures.
Anonymity - the other side of authentication (Score:2)
Bank Security (Score:3, Insightful)
Website Controls
Additional "next PIN" for each transaction
Challenge response
Enter a PIN challenge based on dollar amounts to transfer
The usual web security stuff - see OWASP for more
Signing transactions with certificates and tokens
Security Awareness
Workstation security is paramount, firewalls, anti-spam, anti-malware, running as non-admin all assist in this process
Some trojans imbedded into IE and pop-up boxes that sift the credentials upon the user typing in their banking website
As you can there is so much you can do.
Have fun!
Re:Bank Security (Score:2, Informative)
Nothing surprising (Score:5, Interesting)
There is an easy fix for this as well - client side certificates. I have an account with a bank in an ex-eastern European country and they use it. Many scandinavian banks use that as well (with the certificate on a token or a smartcard).
In order to authenticate the SSL handshake has to use both client side and server side certificates. After that the actual user id has to match the certificate one. A man in the middle cannot break through that because it will not have the private key from the user machine. From there on even if it can fake the bank interface to the user it cannot fake the user towards the bank. Game, set and match.
The only reason for US and UK banks not to use it is outright incompetence. I remember trying to explain the concept of client side SSL certificates to one of the cretins who have implemented a well known UK bank Internet banking security subsystem. He could not grasp the concept. By the way - he now works in the "risk" (that is the way they like calling this now) department of another well known UK bank.
Re:Nothing surprising (Score:3, Interesting)
No particular reason for client certificates to fail to work once loaded in a non-MS client. I got the east-EU bank mentioned in my original post working correctly with konq and mozilla.
Now, smart cards are a different matter. Some of them are not supported under *nix and MacOS. If the card is supported you should still be in the game.
Similarly, requesting certificates may be a problem. Mozilla has some troubles with handling the certificate-request/certificate import sequence. So does konquer
Re:Nothing surprising (Score:3, Informative)
Ways to beat this.. (Score:3, Insightful)
1) the website is simply at another address, well-educated users will spot the lack of https and the different URL
2) I have an account at postbank(.nl) which uses a password for logging in, and then additional codes for transactions. The password will only give you read only access.
3) At this same bank, the transactions are verified by sending you a text-message; not the most secured channel, but the message doesn't just include a "transaction acceptance code", but also the amount of money being transferred. If something is amiss it's spotted easily through this second channel, beyong the phishers' control.
4) Another bank, abnamro.nl, lists the IP number you were last logged in from on the welcome page.
I feel that 1) could be attacked by phishers using malware, so that's no guarantee.
Using the amount of money to be transferred as part of the challenge is trivial and should simply be implemented at first opportunity. One of citibank's problems is that they're using a token that simply displays a code, rather than a challenge response system; no way to enhance the challenge..
Number 3) is also pretty neat. Reall, I don't care so much about my bankstatements per se that they need to be protected with two-factor authentication (though of course in the US, identity theft might make this more prudent). The ability to check my account without too much rigmarole is very user friendly.
Number 4) would be neat, but also confusing to many users, especially those behind DHCP.
Sum conclusion;
use challenge response, with the amount to be transferred firmly embedded in the challenge, or communicated to the user out-of-bounds.
Re:Ways to beat this.. (Score:2)
2) Citibank uses the system from vasco.com. So now I need to enter 3 passwords. 1 for the site, 1 for the machine and the nymber that the achines gives me. None can be the same like my pin number.
3) In Belgium sending text messages is not cheap. I will be the one paying for it. No thanks.
4) At Citibank you also get a popup from you last login. Like I ever looked at it or rememeberd when I did log in the last time and if this is correct.
The problem is the man in
what is your major malfunction? (Score:2, Informative)
-m10
The problem is in the approach itself. (Score:5, Insightful)
Most people almost never create new billing and transfer "destinations". We could afford to go in person once or twice a year to do this. The very few who need these options are usually kwolegeable about security issues. Even if they are not, the fact that there is so few of them is a protection in itself. Remove these options from online banking and even a "phished" account will be of limited use to the phisher since the only thing he can do with it is pay your bills.
This solution was actually implemented in the beginning of online baking. The idea of pushing "new" features with no regards to their actual impact is almost like a disease in the current corporate world.
Depends on the user... (Score:2, Interesting)
Matrix card (Score:3, Insightful)
My bank uses a two-factor authentication system, the second factor being a card with a 10x10 matrix of double-digit numbers. When you login, the website asks you for your username, PIN and the number which appears in certain coordinates in the matrix card.
It used to ask you for it in the login page itself. Nowadays you need to have a mobile phone number associated with your account; when you try to login, the coordinates are sent to you by SMS. In that way, even if a phisher gets your username, PIN and full matrix, they cannot login because they don't know what coordinate is asked to you (and you receive the unsolicited SMS, so you can alert the bank). They would have to steal your cellphone too.
Ah, and you have to enter those numbers using an on-screen keypad which moves around randomly anter you click on each number, so keyloggers are now useless too.
One Fix - Note for Firefox Developers (Score:5, Interesting)
I know this won't fix all problems with phishing emails, but it should fix one factor of it. Could those who contribute their programming skills to Firefox make it so the actual domain of the site you are at is highlighted? This means that if you are at a site
http://citibusinessonline.da.us.citibank.com.tufel -club.ru/sahdlhasal
Firefox would display it as:
http://citibusinessonline.da.us.citibank.com. tufel-club.ru /sahdlhasal
I know some victims refuse to think about it at all and refuse to even look at the URL but this would give them one more tool to use to possibly see it is a scam.
I've said it once.... (Score:4, Insightful)
If email encryption and certificates were a *STANDARD* feature by the major email clients (desktop and web based), then institutions could set a blanket policy that any email communication from them to their clients/customers must be encrypted and/or contain a digital certificate. Even better, these certificates could contain usage policies so that email clients could automatically filter/delete messages w/o the proper certificate or that don't follow stated policies.
The trick is that the user needs to be abstracted away from the encryption/signing process so that they understand the basics of what encryption/certificates are but can use them with with just a click or two.
A good example of taking security technologies and providing them to the user in a well abstracted form is TLS under HTTPS. IMHO, phishing would be drastically reduced if email encryption/certificates, along with usage policies, were as common and supported as TLS under HTTPS is today.
[Pre-rebuttle]I am not saying that this will solve ALL phishing scams. I'm just saying that there are technologies out there that, if commonly supported and intergreted into email clients/services, would greatly increase the difficulty of pulling off a phising scam.[/Pre-rebuttle]
Do you assume you can trust the terminal? (Score:4, Interesting)
In the US, most users are accessing their accounts from their work or home computers. Although keyloggers may be present on these machines, it isn't very common yet. In northern europe, the use of internet terminals in cafes or kiosks is much more common. On these machines, it is likely that keyloggers will be present, so it is conservative to assume that everything the user does will be logged someone.
This assumption (everything the user does is logged) drives the need to require access to some thing (PIN grid, token generator, etc) that is needed in addition to the normal username and password. The higher level of justified paranoia drives a higher perception of security requirements.
One tremendous downside to this: loss of one of the best features of online banking - ease of use and portability. I personally have about ten online accounts with different banks, and I use all those accounts frequently. Everything I need to know to manage my personaly finances is carried in my head, and I can access my accounts from any computer anywhere in the world with nothing more than the knowledge I possess. Having to carry any sort of physical object to access my accounts would be a tremendous loss, one that would probably drive me to seek another bank, or a bank in another country, to avoid.
Postbank (Score:3, Interesting)
In the past (actually it's still possible for people who don't have a cell phone or don't want to use this system) the number wasn't sent as an SMS, but was on a long list of numbers they would mail you (the list was printed and sealed by a machine, no humans would see it before you). This was a nuisance because I kept losing the list and it was a hassle to use, but this new system is quite convenient in my opinion. I always have my cell phone with me, so I can do my banking from any location.
Who is being verified? (Score:4, Insightful)
The whole "phishing" thing is based on the fact that the bank's end can be spoofed, and customers have no reliable way to verify that they are really talking to their bank. A Man-in-the-Middle is simply a variant of this, in which the customer thinks they're talking to the bank, when they're actually talking to the MitM, who is talking to the bank.
Adding extra stuff to better authenticate the customer is not going to help here. Confusing the issue by just talking about "authentication" doesn't help either, since it conflates the two directions of authentication into one, and people don't notice that the customer may not have authenticated the bank.
... and bad reporting to boot (Score:2)