Ruh roh.
Remember the POODLE vulnerability (aka “the poodle bug”)?
Discovered last October, it’s a means by which attackers could intercept supposedly secure SSL communications between your computer and a website. For instance, if you were logging into a secure website (such as an online bank) using WiFi in a coffeeshop, a hacker sitting close by could sniff your confidential credentials as they whizz through the air.
Of course, every responsible website sprung into action – making sure that they weren’t putting their users at risk.
Unfortunately, as The Register reports, it doesn’t seem that banks like Barclays, Halifax, Tesco and others received the memo.
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
This server is vulnerable to the POODLE attack against TLS servers. Patching required. Grade set to F.
Six months after the world was warned about the POODLE bug, that’s pretty shocking.
Hey, banks. Do you think you could do us all a favour and take security a wee bit more seriously? Thanks.
You can learn more about the POODLE vulnerability in the following video I made:
Further reading:
- The POODLE bug internet vulnerability! Watch this video then check your browser
- This POODLE bites: exploiting the SSL 3.0 fallback, Google.
- POODLE attacks on SSLv3, Adam Langley.
- Everything you need to know about the POODLE SSL bug, Troy Hunt.
Surprising?
Not particularly.
Shameful? Disgraceful? Pathetic? Criminal? All the above and more?
Absolutely.
Not quite true. The error known as POODLE on TLS is not the same as the SSLv3 vuln. This is an issue with padding it is mis-named POODLE.
The result might be a false positive if a response from their load balancer is ambiguous. (F5)
If they are running older ACE modules they may be waiting to replace them with more modern units.
Using POODLE to get credentials is hard, and may well be impossible in practice for most vulnerably sites. What is possible is to get session tokens (as they appear at a much more predictable location in the session headers). So your fellow Starbucks WiFi user could hijack your banking session. Which is bad, but frankly, if someone could do serious damage (e.g. transfer money) by simply having access to your account, your bank has much bigger problems.
I'm not aware of any successful POODLE attacks. There may not be any ever. It's nice for pentesters to include in their reports and websites should patch, just in case, but it's not really a big deal.
"It's nice for pentesters to include in their reports and websites should patch, just in case, but it's not really a big deal."
Yes, it should be patched (as you point out) – like all security vulns (and all bugs unrelated to security!). And yes it is a big deal. It is a big deal especially when you consider that ssl has a long history of problems (and I'm ignoring the technicality of ssl versus tls). Whether there's any successful attacks or not is irrelevant; the issue is the hole exists. The severity is another matter but regardless of severity, to not patch it is severe when there is a patch – to not patch it is ignoring security outright.
"Which is bad, but frankly, if someone could do serious damage (e.g. transfer money) by simply having access to your account, your bank has much bigger problems."
Indeed. Perfect timing of course is: http://www.hotforsecurity.com/blog/hackers-steal-5-million-from-ryanairs-bank-account-11744.html
I've thought about this some more and I'm actually pretty certain that being on the same WiFI network is not sufficient. The attacker should really be able to force the victim to make certain requests – which they can do by hiding these requests inside HTML pages that are downloaded over unencrypted HTTP.
Funnily enough, I just (some minutes ago) saw your (I assume it is you) article https://www.virusbtn.com/blog/2015/04_30.xml?rss and just now recognising the name (from the past). But I really like your point here:
—
But just as the presence of brown M&Ms may be indicative of a larger problem, the fact that those sites are vulnerable to POODLE makes one wonder how well their administrators patch other vulnerabilities — ones that do matter. Will those banks be vulnerable to the next Heartbleed?
And of course, there is always a chance that someone will find a much more serious way of exploiting POODLE, just as there is always a chance that a food allergy is the reason behind the odd the brown M&Ms requirement. Which is another reason one shouldn't take risks.
Security in general, and patching in particular, is a process. Patches should, of course, be tested properly, but the aim should always be to apply the patch. Making a decision based on the calculated risk of exploitation is rarely, if ever, a good idea.
—
I was trying to (earlier) make a similar point but you worded it much better (and the anecdote makes it even better).
Yes, that was me – and thanks! :-)
Well it was a very good way to discuss a very important, oft ignored issue! Anecdotes are very useful and could – should – be more frequently used. But besides the anecdote, the way you word those issues is significant: it IS a process, it is a mentality, and there cannot be lapses because the moment you let your guard down there will be a problem (or the potential for problems is highest at this time). Society on a whole responds to an attack – an atrocity, say – by uniting, increasing the strength of the castle – for a while. When things seem better, it happens again because they dismiss the risks or they aren't as aware as they should be (or technology changes, a mutation of something old or otherwise something allows for new and different attacks). That is a process itself and a lot of it is history repeating itself. In the end, it is a constantly evolving war (wars really) with evolving enemies and weapons/armours and even those that do know this are still human and make mistakes. But too many don't know this.
In short: it was a very good write up and should be respected as such (and I certainly do respect it).
I thought when doing secure business one was transferred to a secure url – so the issue should be are the secure urls secure – tif this is correct then is this like describing the london bridge as being insecure when attacking the tower of london.?
Whether you're 'transferred' or not is going to depend on the site in question. One would be concerned if it wasn't but that doesn't mean it is; there is no requirement!
Furthermore, if you're going to encrypt it needs to be 100% and that means all content should be encrypted. To allow non-critical information to be plaintext (i.e. unencrypted) while encrypting other content is a risk (now if you're going to textfiles.com and you truly don't care if someone knows what text files you look at… well, then fine; but that's different). In other words, to only encrypt when necessary is something that should be avoided (which is to say if you log in to a site to buy something – for example – then the connection should be encrypted regardless of whether you're logged in or not).
More critically, the issue with POODLE – and it certainly isn't the only example – is that of the encryption being downgraded! That has more serious implications and actually (potentially, if it is executed then remove potentially) negates the idea of the host encrypting the content in the first place!
People who do online banking on free Wifi at a coffee shop are a special kind of silly.
But you do get what you pay for, do you not ? Not that it makes the issue any better here, but I do think your way of putting it – free Wifi – is relevant to some degree.
I also tested one of Barclays sites this week and noticed they were using IIS6 on Windows 2003.