Forgot your password?
typodupeerror

Phishers Defeat Citibank's 2-Factor Authentication 233

Posted by timothy
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.)
This discussion has been archived. No new comments can be posted.

Phishers Defeat Citibank's 2-Factor Authentication

Comments Filter:
  • Are you surprised? (Score:3, Insightful)

    by Manip (656104) on Tuesday July 11, 2006 @05:33AM (#15696548)
    This isn't at all a shocker. The authentication problem is only one piece of a very complex puzzle. But in this case simple and common SSL certificate verification would work to stop such a man-in-the-middle attack.

    Further down the road though, this is why technology leaders need to standardise authentication tokens to include some kind of two way verification ... So when you enter your token into the browser, first the browser checks the web-site is the "owner" of that token and if it is not then it warns the user, after verification the browser then sends the token and the user is verified to the site.

    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.
  • by grrowl (953625) on Tuesday July 11, 2006 @05:35AM (#15696554) Homepage Journal
    The target authorities and security developers should be aiming for, in my opinion, is not the people who do the wrong-doing, but the users themselves. The major difference that phishing has from hacking or physical robbery is that the attack is forceful against either the bank's online front or the customer whereas phishing preys on not physical or technological weakness but on intellectual weakness: ignorant users are conned into giving up personal details, going to a particular site or running a program because they are unaware of the risks. In phishing cases there really should be a bigger push for educating customers through more than just 20-pixel-high signatures on electronic correspondance. There should be in-bank brochures, tv spots/advertisements (or at least addendums to current tv spots) and users should clearly know never to click a link in an email from anyone, especially if it's pertaining to a bank or paypal-like site or in a personal mail from someone unfamiliar. There's a reason many geeks have clean-as-whistle computers (I virus and spyware scan every now-and-then -- about every 6 months -- and they both always come up clean) whereas the "common user" has problems with viruses and scumware seemingly constantly, and that reason is education and not-so-common sense. The answer then is obviously to educate, and make that sense common.
  • by WebHostingGuy (825421) on Tuesday July 11, 2006 @05:37AM (#15696558) Homepage Journal
    A man in the middle attack will breach just about any security you have. Unless you can recognize it, or teach others to, this sort of attack will always work. The trick is that it is sophisticated and you have to educate people to know when they are connecting to the correct site or not; that is, check the URL and the SSL certificate when connected. And, never use self-signed SSL certificates.
  • by Colin Smith (2679) on Tuesday July 11, 2006 @05:51AM (#15696593)
    People might just be able to determine if they were valid or phishing attempts.

    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.

     
  • Bank Security (Score:3, Insightful)

    by nighty5 (615965) on Tuesday July 11, 2006 @06:03AM (#15696623)
    As a security consultant I use lots of ways to defeat all types of security controls. and in true Slashdot way I didn't read the article. There is no silver bullet to security, it requires successive layers of controls (defence in depth) to adequately protect against attacks. It is no suprise to see two factor auth is defeated in this situation, but there is other controls a web application can use to safe guard against these attack types:

    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!

  • by wfberg (24378) on Tuesday July 11, 2006 @06:07AM (#15696633)
    Let's see

    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:Good. (Score:3, Insightful)

    by stunt_penguin (906223) on Tuesday July 11, 2006 @06:42AM (#15696719)
    ^ sorry, your method of sending all (or all recent) transaction info as a mark of authenticity in the email would probably help to eleminate that type of attack since the phishers would have no way of providing this info.

    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; has anyone seen the like of this yet?
  • by Parandor (779995) on Tuesday July 11, 2006 @06:43AM (#15696722)
    Why is online banking allowing you to create new billing accounts online? Why can you make a transfer to a new, unlisted, account online? Answer: Banks want to save money.

    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.
  • by MonsoonDawn (795807) on Tuesday July 11, 2006 @07:00AM (#15696762) Homepage
    1. Certs are entirely too easy to obtain.
    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.
  • by Anonymous Coward on Tuesday July 11, 2006 @07:32AM (#15696841)
    The only reason for US and UK banks not to use it is outright incompetence.

    No, it's not an easy fix, it's a huge hassle. If the client-certificate is going to be on the user's computer, then the user can only bank from one computer. Many people have multiple computers (desktop, laptop, spouse's PC, work PC, etc), will you issue client-certificates for all of these? If you do, you now have a certificate issuing problem. And if the client-certificate is in the browser, then it can be read by rootkits & spyware.

    If you're going to use a token (smartcard or key fob), then you have interoperability problems with different browsers/operating systems for a full ssl client certificate.

    The handheld tokens where you have to type a challenge & get a response don't implement a full ssl client certificate, and are subject to MITM attacks, as was described in the article.
  • Matrix card (Score:3, Insightful)

    by Tarrio (151332) on Tuesday July 11, 2006 @08:01AM (#15696954) Homepage

    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.

  • Re:Good. (Score:2, Insightful)

    by porlw (169848) on Tuesday July 11, 2006 @08:23AM (#15697063)
    Note quite.

    1. The SMS only happens if you actually try to do a transaction.
    2. The SMS also supplies destination account and amount.

    So MIM would only work iff they intercepted an attempt by me to make a payment, and I didn't check the details in the SMS. If I get a transfer SMS out of the blue then I know something's up.

    If I lose my mobile then I do what our stone-age ancestors did, and actually go to the physical bank building and fill out a transfer request.

    If I make regular payments to a particular account I can also preset the details and avoid the SMS procedure. Requires some paperwork at the bank, though, so they can verify my identity then.

  • by Henry Stern (30869) <henry@stern.ca> on Tuesday July 11, 2006 @08:28AM (#15697088) Homepage
    You're underestimating the problem here. Banks can sign their e-mails using S/MIME until the cows come home and it won't do a thing to combat phishing. Phishing victims are naive and would not relate to the importance of checking for a valid S/MIME signature. They already have similar funcitonality in their web browsers with SSL and the "lock" icon and it's not working.

    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.
  • by jrumney (197329) on Tuesday July 11, 2006 @08:40AM (#15697150) Homepage
    The trust problem you describe goes away if bank issues its own client certificates to customers. The bank does trust itself doesn't it?
  • by Zemran (3101) on Tuesday July 11, 2006 @08:58AM (#15697229) Homepage Journal
    That all sounds too complicated for me, I think I will just stay poor instead...
  • Re:Good. (Score:2, Insightful)

    by SilverJets (131916) on Tuesday July 11, 2006 @09:24AM (#15697338) Homepage
    How's about protecting you from the man in the middle attack by a little extra procedure, though ?

    How about not clicking on every bloody URL in every e-mail you receive?

    No matter how good the security, it will always be defeated by the stupid users it is there to protect.
  • Re:Good. (Score:1, Insightful)

    by avirrey (972127) on Tuesday July 11, 2006 @09:34AM (#15697410)
    If I had to wait a week for a listing of my transactions.... I'd blow a fuse. I want to see it online, I want instant convenience, that's the world we live in. You can't 'make' a transaction, and then cancel it 1 week later!! After the fraud you are just plain and simply screwed, seeing a fraud transaction in the first place did nothing to prevent the fraud to begin with! Get a clue guys, we want prevention not a 'catch' 1 week later.
  • by Temujin_12 (832986) on Tuesday July 11, 2006 @09:47AM (#15697497)
    ...and I'll keep on saying it.

    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]
  • by jc42 (318812) on Tuesday July 11, 2006 @01:30PM (#15699369) Homepage Journal
    I can't help but notice that all the authentication schemes being discussed are basically way that the bank verifies the customer is who they say they are. But the issue isn't that; it's that the customer is being tricked into thinking that they're talking to the bank when they are actually talking to someone else (who may be talking to the bank). There is nothing that I see that helps the customer verify that it's actually their bank on the other end.

    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.

We can predict everything, except the future.

Working...