This Just In: Number of Authentication Factors Not Important When Host is Hosed

You can have 20 factor authentication, but if your host security is already compromised, what have you solved? Not much. 2 factor authN is fighting the last war, when the fields were green, the host was secure and all we needed was SSL, a network firewall, and a stiff upper lip.. I previously blogged:

At the OWASP conference last spring Andrew van Der Stock described a large banks design options for dealing with phishing. They wanted to go to two factor authN. They were looking at USB dongles, but they assessed that 2/3 of their customer's PC had some malware on them, so they did not want to put their "good stuff" (the dongle) into their customer's bad stuff. So instead they sent authZ codes via SMS to the customer's cellphone. "Perfect" security? No. Nice, incremental improvement over current state? Ya sure, ya betcha.

The Man in the Browser (MITB) attack uses Web 2.0 style attack vectors essentially a viral mashup. Finextra reports:

The bank says that its customers opened an email attachment that resulted in a virus being executed on their machines. This virus changed their browsers' behaviour so when they went to open the real ABN Amro online banking site, they were instead re-directed to a spoof site.

The customers then typed in their passwords, which the attacker in turn used to access the bank's real Web site. The customer's own transactions were passed along to the real site, so they didn't notice anything wrong right away, while the attacker simultaneously made their own fraudelent transactions using the bank's urgent payment feature.

ABN Amro has issued its customers with two-factor authentication tokens for several years. But the man-in-the middle attack gets around this security measure by passing the ever-changing part of the password from the token to the bank along with the never-changing part - essentially piggybacking on a legitimate log-in.

Financial Cryptography blogs additional commentary on MITB. The issue is that 2 factor authN is great if you are authenticating to a secure machine or channel, but is only a speed bump if the box or channel is already 0wend. That war is over and lost. It is a head scratcher why RESTians, Web 2.0, Ajaxians, et. al. blithely assume that these wonderful new technologies (and I mean that babe) do not require any new security mechanisms.

So, everyone update your threat models. I used to do an exercise when I doing security architecture with clients. We would walk through their security architecture, describe the rationale for each component and service, etc. Then I would say "imagine the firewall is not there, how does your security function now?" etc, etc. Now we can add one moe to the list - imagine a malicious agent inside your customer's browser.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

Comments

[Bob McCormick]

Fascinating story. The banks attempt to get around the issue of compromised end user hosts was quite clever, but in the end the criminals were more clever by far.

However, I fail to see what your rather unprompted broadside against REST and AJAX has to do with the story. Since the root of the problem was malware on the users PC, I should think that a WS-Security protected transaction would have been just as vulnerable.

[Gunnar]

There is no question that you can easily write insecure apps in WS-*, SAML, whatever. The point I am trying to highlight is that at least these technologies bring new security mechanisms to bear on the security arms race we are in. The REST and Ajax story is - we have SSL and network firewalls, what else do we need?

In my opinion you have to sadly assume a malicious environment. Kim Cameron has a good post today on this as well

http://www.identityblog.com/?p=740

[Bob McCormick]

They do bring new security mechanisms, but IMHO those mechanisms wouldn't address the issue you've chosen to highlight. :-)

Also, while WS-Security introduces new security mechanisms, it also introduces significant complexity. That complexity can't be ignored, particularly because it has security ramifications of it's own.

For example, I'm quite concerned about the rather large attack surface of a WS-Security secured message.

Interoperability is also a big concern because of the breadth and lack of specificity of the WS-Security spec.

But back to the bank attack in question... It's really a fascinating case that IMHO has close parallels to the difficulties the content industry (RIAA, etc) has had with DRM technology. Both come down to the fundamental question of controlling application behavior (and securing data) on a potentially hostile platform that you don't control.

[Gunnar]

The problem is that the 2 factor authN goes into a single communication band. The example I linked to using SMS separates communication bands. For one thing, you need to have support multiple security token types to do this. WS-Security and WS-Trust are designed to support Kerberos, SAML, X.509, Username/password hash, and other token types, as well as other namespaces. This is a major difference, and can be used to build a system that is resilient to some of the threats above. For example a transaction can have multiple token from multiple namespaces, aggregated across multiple hosts, and context (bands).

Now to the complexity issue, for sure this is a real concern, and needs to be worked, but this is a lot different than saying "let's just keep using SSL and network firewalls like it is 1995" style security architecture.

[Igor Drokov]

As the automatic trackback failed "Response: [Failed] As a measure to prevent automated commenting, please verify yourself via this captcha check."

Here is a manual one :)

"As many security experts point out, two-factor authentication is not going to prevent financial fraud and identity theft, e.g. see Schneier. Let me play devil's advocate for a moment. For all its failures, could implementation of 2FA disrupt currently established online criminal practices? I think so."

http://blog.cronto.com/index.php?title=2_factor_authentication_not_useless&more=1&c=1&tb=1&pb=1

[Andrew van der Stock]

Hi Igor,

The SMS is a form of transaction signing. Weak transaction signing for sure, but it's better than 2FA authC, as the MITM scenario proposes.

The attacker has to

a) conduct a DNS or other infrastructure level attack (such as install a Banking trojan) against the victim

b) take over the active session, either by navigating the user to a perfect copy of the site (hard) or just interceding with some added Ajax background music, such as a forceful CSRF to which the user is unaware

c) Convince the user that they must give up a sound credential. With a 2FA fob with no transaction signing, this is easy and many will fall victim. This is why 2FA fob only does not work and is a waste of money. If the user sees a message on their phone for no reason, saying:

"The token code to transfer $2900 to account "blah" is 437485. If you did not make this transaction, do not enter the code and call 1800 EXAMPLE immediately. This token expires in 30 seconds."

A user will hesitate to enter that unless they're already in the process of entering a transfer. If it's the wrong value, and the wrong destination, they will not enter it.

SMS 2FA is extremely cheap, and extremely effective. For customers without a mobile phone, transaction signing calculators from Vasco et al cost $20 on up to a couple of hundred for the EMV capable fancy ones. I like the intermediate EMV calculators - they force the user to put their corporate credit card into the device thus ensuring they have a mental picture as to the value of leaving the token around. All too often, I find tokens in desk drawers and such. Making the user aware of the exact value by hooking a real monetary instrument to a disconnected calculator is so close to three factor authentication: something you know, something you have, and something you are, as to not count. I doubt the attackers will work out a suitable attack path for these devices unless *we* make mistakes.

And sure enough, we will make mistakes. But the cost will be a lot less than it is today. The day of the password ended a long time ago. It's time to move on to a world where devices are *always* assumed to be trojaned, and the network is *always* assumed to be tainted (DNS pinning attacks, etc), and so on. SSL no longer cuts the mustard alone.

Andrew

[Jeff Zhuk]

Gunnar is absolutely right in the main thing: there is no absolute security cover but each security layer adds more security.

No questions, we pay high price for security in performance and complexity, but we might pay much more for its absense.

P.S.
Gunnar,

I am very glad to see you online:-)

Jeff Zhuk

[Igor Drokov]

Andrew,

Thank you for your comment.

Whilst I am not convinced that SMS-based or CAP/EMV calculators are the best solution, I couldn't agree more with the statement that transaction signing is required to protect against Man-in-the-Middle attacks.

In fact, my last post on the subject was exactly about it:
"Transaction verification can protect agains MiTM"
http://blog.cronto.com/index.php?title=transaction_verification_can_protect_aga