Online Bank Security - BROKEN !?!?!

nidO

securityguy wrote: »

The Poodle SSLv3 attack allows, under some fairly rigorous circumstances, the theft of authentication cookies.

This is a much more properly-written write-up than the OP's but is, unfortunately, based mostly on old information, only hinted on by your last paragraph.

Last month's discovery that POODLE also affects certain implementations of TLS 1.0 through 1.2 if the server does not properly check for padding is where several of the tested banks currently fall down (having checked them properly, approximately half can be considered "broken" for this reason only), and are vulnerable to the TLS variant of POODLE.
As you mentioned though exploiting this isn't a trivial attack and the benefit of it is moderate at best against online banking, and there are few to no reported attacks actually being successfully carried out to my knowledge.

You are correct though that most of the rest only fail SSL POODLE and are secure against TLS attacks because they check padding correctly - However, oddly the majority of these do not apply server-side downgrade attack protection so any browser that actually supports SSL at all is still vulnerable to a downgrade attack against these sites.
Again a combination downgrade + SSL POODLE attack is very complex and again isn't actually happening much in the wild, simply exploiting straight SSL POODLE is much more straightforward but pretty much applies to IE6 only, and protecting against that means preventing users using IE6 from accessing their online banking at all.

The remaining few which "fail" according to the OP simply use less-than-ideal ciphers and none of them enforce the "bad" ciphers by default (and neither should anyone's browser), so this presents minimal risk.

TLDR: A small number are "insecure" because of a trivial cipher issue that shouldn't affect anyone, a larger number are "insecure" because they allow moderately straightforward attacks against IE6 and much more complex attacks against any browser that supports SSL (still most of them at this point, though it can always be manually disabled) and the surprisingly large number of the rest are "insecure" because they don't correctly protect against POODLE via TLS, which over a month after the flaw was discovered is on the one hand unforgivable but on the other is very difficult to exploit for minimal benefit.

securityguy

That'll teach me to rely on last month's seminar :-)

I'm not confident enough to risk my own money, but I suspect that even if I gave an attacker the cookie used to secure a login session (ie, don't mess about with POODLE, just take this cookie I'm giving you) they wouldn't be able to extract money for any practical scenarios with UK banks. Counter-examples welcome.

"very difficult to exploit for minimal benefit."

Quite. The OP appears to posit an attacker who is willing to engage in substantial effort to obtain no money, but have a good chance of getting a paper accepted at a top conference.

Precisely

Archi_Bald

securityguy wrote: »

they wouldn't be able to extract money for any practical scenarios with UK banks. Counter-examples welcome.

I absolutely agree the risk is minimal. I can think of one bank where this may not be the case but for obvious reasons I am not going to post it on a public forum. I'll drop you a PM.

6_6_6

Ok too many assumptions there for my likening. I tend to think those that feel proven attacks are necessary before a cypher is deemed unfit for purpose are approaching security from the wrong side of the fence. I’m not sure that’s what you’re saying but some parts seemed to fall along those lines.

Since computer security is all about prevention, if we have to react due to a breach, it's already too late and your security has failed. It goes without saying, anyone in charge of securing a system whilst allowing use of a cypher / protocol that has been shown to suffer a real world practical attack of any sort, as of today, might be deemed to have committed gross misconduct.

However, practical attacks are not what define the security / cryptography industry generally. The goal is to avoid them in the first place. With security we only get one chance to do the right thing. When cryptanalysts are reporting what they consider to be theoretical weaknesses in 3DES or RC4 for example, we as assumed non-mathematical geniuses, need to sit up and listen.

The question is no so much about what they currently achieve with today’s technology, since it’s always only a matter of time until ‘they could’. It’s more about how far can you distance yourself from any future perceived threats. We have our reports on how cyphers and protocols work, envisaged weaknesses, peer reviewed by thousands of ‘experts’, sometimes it takes a small group to show the world, other times the consensus is easily reached. However, the banks are ignoring the advice over cyphers recommendations by the likes of WASP, mozilla and other major groups.
So if security is about doing what you can today and each day, and doing it well. It is incumbent upon any security professional, to take all the possible mitigating steps available to them, prioritise them in the most pragmatic way you can within the budget available, then ensure they are implemented correctly.
So when we see banks, which have plenty of money to spend on IT let me tell you, whether they chose to is another matter. Neglect configuring the TLS settings so as to order the cyphers correctly, enable the latest cyphers to support the latest browsers, fail to disable implicated cyphers and protocols on the premise that the currently understood likelihood of a practical attack as not being particularly high, I call into question justification for not doing so. The organisation that doesn’t act according to what their risk profile is and responsibilities can support, is a foolish company.

You provide one, not !!!!ing off people using an unsupported decade old browser. But how is that within the interests of security? I find it difficult to believe we still have that many users on IE6 for instance, logging into their banking. If raw statistics prove it to be above 5% for arguments sake, then is it not better to direct those users into installing the latest browser? They seem to be very deft at doing the same when it comes to pushing Trusteer Rapport. Humm is this deliberate misdirection though negligence / incompetence or down right corporate voracity?
I would never leave it to assumption, that just because it’s a bank, that they will be competent. Nor assume that banks will make best use of multi-factor auth.
Notwithstanding creating new PAYEs, I would not seek to minimise the amount of disruption and potential loss transferring payments between readymade PAYE accounts could cause. Some people have a number of PAYE accounts set up and First Direct for example does not request the regeneration of a transaction security code to do so.
Non the less, and no less a threat, I take the point about monetisation and what we might assume to be a infeasible attack for what would amount to a mere statement , but again, we are not black hats. We can learn from them though, and we know very well there are a variety of character types out there, all very capable adversaries, where monetisation is not their priority.
Again this comes down to the time investment needed to secure the connection vs costs. And simply put, I can think of two factors to consider.

1. Support of old clients (legacy support)
2. Supporting the latest clients.

I have more issue with the fact these banks are not providing strong modern encryption schemes for clients that can use it, which by some accounts amounts to around 90% of the internet. They only seem to be bothered with legacy support, and as yet I have never seen figures that justify such risks. The time it takes to harmonise and rollout HTTPS updates to servers so they support modern TLS 1.2 and the top cyphers is chicken feed to these people. Kudos to Santander, they did it. They looked into what I said, ran it past like minded experts in the field and decided the extent to which they needed to support this legacy argument, was to reach only as far back as TLS 1.0 - TLS_RSA_WITH_RC4_128_SHA which is not so bad at all, since they have also implemented the cypher ordering correctly, so most of us will be authenticating using TLS_ECDHE based cyphers which rock PFS.
Now does that mean Santander don’t care about these alleged thousands of users behind every corporate firewall unable to log into banking. What we can assume is that the real world statistics proved this was insignificant or at least worth the sacrifice. I would 100% agree with that. It’s a good move, and hopefully the others now follow.
If we consider though for a moment, that there might be companies that’s till have staff working on XP and IE6, no longer supported by Microsoft, no longer receiving security patches etc. If these machines have access to the intent, they are likely to be crawling with botnet and malware, should we even seek to support them to the detriment of the rest of the Internet! Would you as a bank want such clients connecting to your systems? Again, I think this is an old straw man argument which no longer holds water under scrutiny. Since when has 'good enough' security been good enough ? Sony is an example of a company who took a good enough approach, you should see what they are doing now!

There is a nice report that touches on the very exacerbation i am experiencing today; http://www.computerweekly.com/news/2240238466/Delusion-about-cyber-security-growing-says-Cisco-report


[FONT=&quot]I think you might have glimpsed the post when I copied the summary of another post into my first post. I changed the line “there is nothing that we, at our end, can do to protect ourselves” in line with my original post to “there is very little that we, at our end, can do to protect ourselves” . I give two simple measures right in the first post, of ways to help mitigate poor website HTTPS implementations. You also have HTTPS everywhere which can help in other ways. [/FONT]

bubieyehyeh

I've previously tried to report similar issues to a UK bank, and was unable to get messages passed on to techies within the bank who might understand. So I know the banging your head against a brick wall feeling.

They rejected my complaint, and said I could go to the ombudmen, then the heartbleed bug hit and in fixing that they fixed the fault I had been reporting for months.

The fault which was allowing people to connect to internet banking via HTTPS using a null cipher - which provided no encryption/protection.

The same bank also had a fault in their internet banking where some "secure messages" sent while logged in failed, and then the error report including the "secure message" was send to the customers email address. The customer service person didn't think it was an important problem, but did agree they would fix it "in time".

esuhl

ceredigion wrote: »

Would somebody be kind enough to translate the above in to English please

From what I can gather, SSLv3 encryption is insecure.

But Firefox v34 and Chrome v39 onward disable SSLv3 by default. So, if you use those browsers (from what I can gather), you don't need to worry and can go and read some more interesting threads.

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
http://threatpost.com/google-removes-sslv3-fallback-support-from-chrome/109455

securityguy

The problem with all these sorts of threads is that there is no evidence at all that these are realistic threats. Online security has become the province of security researchers looking to get papers published. There is an opportunity cost to chasing down threats that aren't being actively pursued; for example, two-factor authentication mitigates a range of both theoretical and very real attacks (never mind subtle crypto exploits, let's worry about key loggers which really are being used by attackers) but hasn't been adequately deployed by many of the UK banks. Worrying about that should be far, far higher up the list of priorities than concerns about frontal and side-channel attacks on crypto. After all, with the variety of authentication used by some banks where the account code and the sum of money are put into an offline device, an attacker who can read and modify every message --- a Dolev-Yao attacker, if we're writing papers --- still gets no advantage.

Similarly, there's an opportunity cost in improving customer behaviour. You can only effectively tell them a small number of things, and you should make those the things that have the most leverage. The main things that will keep customers safe will be not sharing credentials, keeping machines patched and protected against keyloggers and logging out properly after finishing a banking session. Exotic attacks aren't happening because they are much, much harder to mount _profitably_ than the scaremongers would have you believe, and although they can't be completely discounted, they should figure much lower down people's priorities than defence against real, in the wild attacks.

Over on Techie Stuff, there's someone worried that, and someone else supporting that worry, that email attachments can "infect" iPhones. Nothing's impossible without a formal proof proving it, of course, but the security design of iOS makes such an attack extraordinarily difficult, and the poster in that case would be better off spending their energy on (say) putting a pin lock on their phone than worrying about a vanishingly unlikely, extraordinarily exotic attack.

There's no evidence that criminals are making any attempt to break banking crypto, and the vast majority of banks are using two-factor well enough that the monetary loss of such a break would be negligible. That's good security engineering.

6_6_6

securityguy wrote: »

The problem with all these sorts of threads is that there is no evidence at all that these are realistic threats. Online security has become the province of security researchers looking to get papers published. There is an opportunity cost to chasing down threats that aren't being actively pursued; for example, two-factor authentication mitigates a range of both theoretical and very real attacks (never mind subtle crypto exploits, let's worry about key loggers which really are being used by attackers) but hasn't been adequately deployed by many of the UK banks. Worrying about that should be far, far higher up the list of priorities than concerns about frontal and side-channel attacks on crypto. After all, with the variety of authentication used by some banks where the account code and the sum of money are put into an offline device, an attacker who can read and modify every message --- a Dolev-Yao attacker, if we're writing papers --- still gets no advantage.

Similarly, there's an opportunity cost in improving customer behaviour. You can only effectively tell them a small number of things, and you should make those the things that have the most leverage. The main things that will keep customers safe will be not sharing credentials, keeping machines patched and protected against keyloggers and logging out properly after finishing a banking session. Exotic attacks aren't happening because they are much, much harder to mount _profitably_ than the scaremongers would have you believe, and although they can't be completely discounted, they should figure much lower down people's priorities than defence against real, in the wild attacks.

Over on Techie Stuff, there's someone worried that, and someone else supporting that worry, that email attachments can "infect" iPhones. Nothing's impossible without a formal proof proving it, of course, but the security design of iOS makes such an attack extraordinarily difficult, and the poster in that case would be better off spending their energy on (say) putting a pin lock on their phone than worrying about a vanishingly unlikely, extraordinarily exotic attack.

There's no evidence that criminals are making any attempt to break banking crypto, and the vast majority of banks are using two-factor well enough that the monetary loss of such a break would be negligible. That's good security engineering.

There is never likely to be evidence that criminals are making any attempt to break banking crypto, until they have broken it.
For a bank to switch on up to date security is an easy task, its unforgivable. The only thing that makes it difficult is bureaucracy, nothing to do with user education since its the banks responsibility.

6_6_6

esuhl wrote: »

From what I can gather, SSLv3 encryption is insecure.

But Firefox v34 and Chrome v39 onward disable SSLv3 by default. So, if you use those browsers (from what I can gather), you don't need to worry and can go and read some more interesting threads.

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
http://threatpost.com/google-removes-sslv3-fallback-support-from-chrome/109455

SSL v.X is not the only weak protocol in use today. Fire Fox does not protect you against them, nor does any other browser.

securityguy

6_6_6 wrote: »

...while talking about prioritisation of the threat model. All this talk of opportunity cost, let’s not lose sight of what low hanging fruit cipher tuning represents.

Do you do this on mass-deployment systems for a living? Fiddling with available cipher suites is absolutely not "low hanging fruit". It has implications for processing performance (one of RC4's attractions over DES was that the former is very quick on standard hardware, while the latter isn't), for entropy collection (a server using RSA doesn't need to generate session keys, while ECDH session keys are predictable if you can attack either the client's or the server's RNG), for browser compatibility (not only for fielded browsers, but for people on the other side of Blue Coat-style intercepting proxies), etc, etc.

It bears little in the way of implementation cost both in terms of FTE and tin.

And you base this assertion on...?

getting your HTTPS implementation right represents a quick win, I mean it took me 30 minutes spent in a tuning exercise

On the deployed infrastructure of a large, performance and security sensitive service with a million users? Or on your private webserver, which sees 20 hits a day, most of them your own? I took all the suspect suites out of my private webservers as soon as POODLE was announced, and in fact I have the cipher suites reduced to a handful, all of them using AES. But then I don't have to worry about Mrs Miggins and her obscure set top box and nor, I suspect, do you.

As for the question over perceived threat vs practical, well many ‘experts’ would beg to differ and peer reviewed publications on why one cypher is preferred over another are readily available.

See my point about security research being about publishing papers. Getting a few bits of leverage on AES 128 is of no practical concern, but will get you a paper at a top conference.

From a personal standpoint I would not want to be the guy confronted by the board asking me the plain and simple question, why I hadn’t enabled the strongest available protocol and cypher suite on the server when I set it up

Are you someone who might find yourself in that situation? I am, and indeed I have done precisely those presentations.

, which might have vastly reduced the surface area of yet another 0 day HTTPS fail,

Perhaps you could tell us why you think that, say, AES256 is any more resistant to the possibility of a Heartbleed-style threat than DES56? All the threats we're talking about are implementation fails, not problems of cipher strength.

when it would have taken such marginal investment. That would be one tricky conversation.

No it wouldn't. It would be a straightforward "what is the likely cost of the failure against the cost of implementation?" It would be a debate about reputational risk, about trust in the two-factor and ultimately, what the compensation would cost. And you still haven't explained why you think AES256 + ECDH is stronger against _implementation_ fails than anything else. Which cipher suite do you think is strongest?

And how much money do you think these "HTTPS zero day fails" have cost the banks so far? My guess would be zero. Nothing. Not a penny. What's your estimate?