Many of the nation’s top banks, investment firms and credit providers are vulnerable to a newly-discovered twist on a known security flaw that exposes Web site traffic to eavesdropping. The discovery has prompted renewed warnings from the U.S. Department of Homeland Security advising vulnerable Web site owners to address the flaw as quickly as possible.
In mid-October, the world learned about “POODLE,” an innocuous acronym for a serious security flaw in a specific version (version 3.0) of Secure Sockets Layer (SSL), the technology that most commercial Web sites use to protect the privacy and security of communications with customers.
When you visit a site that begins with “https://” you can be sure that the data that gets transmitted between that site and your browser cannot be read by anyone else. That is, unless those sites are still allowing traffic over SSL 3.0, in which case an attacker could exploit the POODLE bug to decrypt and extract information from inside an encrypted transaction — including passwords, cookies and other data that can be used to impersonate the legitimate user.
On Dec. 8, researchers found that the POODLE flaw also extends to certain versions of a widely used SSL-like encryption standard known as TLS (short for Transport Layer Security).
“The impact of this problem is similar to that of POODLE, with the attack being slightly easier to execute,” wrote Ivan Ristic, director of engineering at security firm Qualys, which made available online a free scanning tool that evaluates Web sites for the presence of the POODLE vulnerability, among other problems. “The main target are browsers, because the attacker must inject malicious JavaScript to initiate the attack.”
A cursory review using Qualys’s SSL/TLS scanning tool indicates that the Web sites for some of the world’s largest financial institutions are vulnerable to the new POODLE bug, including Bank of America, Chase.com, Citibank, HSBC, Suntrust — as well as retirement and investment giants Fidelity.com and Vanguard (click links to see report). Dozens of sites offering consumer credit protection and other services run by Experian also are vulnerable, according to SSL Labs. Qualys estimates that about 10 percent of Web servers are vulnerable to the POODLE attack against TLS.
According to an advisory from the U.S. Computer Emergency Readiness Team (US-CERT), a partnership run in conjunction with the U.S. Department of Homeland Security, although there is currently no fix for the vulnerability SSL 3.0 itself, disabling SSL 3.0 support in Web applications is the most viable solution currently available. US-CERT notes that some of the same researchers who discovered the Poodle vulnerability also developed a fix for the TLS-related issues.
Until vulnerable sites patch the issue, there isn’t a lot that regular users can do to protect themselves from this bug, aside from exercising some restraint when faced with the desire to log in to banking and other sensitive sites over untrusted networks, such as public Wi-Fi hotspots.
haha:
“disabling SSL 3.0 support in Web applications is the most viable solution currently available”
if you do that, then some InterNauts cant use certain sites to schedule their Conference attendance, and when that happens they tend to get all excited and cry. but then again those web apps will have to be re-designed too!
ah, business is good
hehe, i said InterNauts
its amazing – there are a TON of third party services that do risk mitigation and risk analysis. For banks to protect the coffers, one would think financial institutions – of any type, would be on the bleeding edge of security.
They simply need to set the computers up as rings of trust, in any environment. Air gap what is critical and keep thins separate. Sure, it makes IT functions harder, but thats what whitelists and blacklists are for.
Additionally, there is software out there that can be purchased to freeze a system, and upon reboot, any changes that were made won’t save. Set up kiosks for those that need internet access with a similar product and keep the mindless clicking at a minimum.
As for “online” banking, make it a pain in the arse. make them do online banking from a certain number of machines, and those IP’s/mac addresses are the only ones on the whitelist for that individual will work.
There is a ton of good ways to do all of this. The problem is, people want easy, and with that, the crooks can enjoy the coinage as well.
I wonder how long the crooks have been actively using this before the good guys found the issue?
But that would cost money, which in turn would be bad for the stock options of the CEOs of those banks
Bingo. Security like any other maintenance is expensive, and a quick way to save money, don’t do it until you have to, and if you must, pass the cost on to the consumer.
heh. Thats pretty close. But think of it this way. The people who ante up for all the fraud that happens, and compensating the end user…. They probably can buy the best, most expensive security suite, and a team of experienced individuals to run it. NAH, lets just do it the old school way. Once they start seeing Red they might go to the drawing board, or simply increase the cost per swipe.
Unless it was used by the NSA for years in that case are they the good guys or the bad guys? They certainly try to wear the good guy hat, but they’re hoarding zero days knowing that they might not be the only ones who have them. So what does that make the NSA?
I’m confused. Two years ago, anyone claiming the gov’t was recording their calls would have been labeled nuts. Today they’re telling the truth.
Whitelist mac addresses ? for online banking? If only the server would get to see them. Even so its just no scalabe enough and oyu can spoof mac addresses anyway. With all due respect, if you really don’t know what you are talking about. Please don’t fill up this with nonsense.
Websites can’t get your mac address. Mac is only used to identify devices over a local network.
Tell that to my IPS’s. I see MAC’s from all over the world.
And if you can read what is typed, vice what you want to see, It clearly states IP/Mac…. Work the technology to your favor, not against it.
Tying customer logons to specific machines is the easiest way to upgrade security and is something customers can understand. Why all banks don’t do this is a mystery.
Not just tying to a specific PC, but to a specific geographical location and specific times of day and specific transaction types and specific transaction amounts.
That’s being done right now by banks that care. Also two-factor.
If you trip something anomalous, they just ask for additional identifying information or start sending SMS messages to the mobile phone attached to the account with confirmation codes you have to enter.
If you travel around it can be a pain, but it works and it is worth it.
“As for “online” banking, make it a pain in the arse. make them do online banking from a certain number of machines”
This is the cheapest way to provide banking services so the banks go out of their way to push customers toward online banking, paperless statements, the works. You are living in fantasy land if you think banks would try to make this channel harder to use.
A wise man once said, “The bad guys only have to succeed once to rob you blind, but the good guys must be good each and every time. The one time they slip up they get robbed.”
Security is a full-time, never-ending job and approach. No rest for the weary.
As the security manager for a smaller financial institution, I can tell you the move to online, mobile banking, and Remote Deposit Capture (RDC) is being driven by the stampede of customers who insist with their wallets on having those services.
If we made online banking a “pain in the arse” we would very quickly have no accounts to be a pain to.
Then, I would think (?) the thought process is, as long as the situation at hand still brings fistfuls of cash, even though it is broken, lets run this into the ground. Forget about thinking out of the box, if some one encouters fraud, some one will foor the bill. making it “harder” doesn’t mean make it absurdly impossible. With ease – there is lax security and a fly by the seat of thy pants mentality.
Looks like Vanguard has a mixed bag of grades when I ran it myself. Some IP’s have “B”, some “F”.
With message: “Warning: Inconsistent server configuration”
Krebs states it does extend to certain *versions* of the TLS protocol. That is technically not correct. It extends to certain *implementations* of the TLS protocol, but on those implementations likely all versions (1.0, 1.1 and 1.2). So the protocol itself is fine, just certain software implements it incorrect.
To be more exact, the TLS protocol protects against POODLE as it has requirements how padding bytes should look like. The POODLE attack involves fiddling with these padding bytes. In the SSL protocol there is no means of detecting this. In the successor protol TLS there is due to these requirements and a server would reject the attackers packets.
Now it turns out two mayor vendors (F5 and A10) don’t actually check for these requirements. As such an attacker can just change the padding and perform the POODLE attack anyway.
It’s even more amazing the amount of sites that **ONLY** allow SSLv3, even quite a few within Alexa Top Million sites, where users have no secure option
Interesting info can be found in https://poodle.io
Steve Gibson had a good podcast on poodle describing why this attack vector is not really viable. In order to pull it off, you must have malicious code running on the client. You can’t accomplish this attack with a passive MITM. If you already have that access, there are much easier ways to achieve the desired nefarious outcome. So, if accurate, then this is an attack that will never happen.
You can do both POODLE and this new attack with regular MITM access. No malware needed on the client machine. I respect Steve Gibson a lot, but if he truely stated this, he is wrong here. The malware on the client is just one way of doing it. MITM or using a modified website to force a client to make connections to a targetted website using his/her credentials is also possible.
Now I’ll admit the chance of it happening to a regular person is very small indeed, so o reason to panic. But the key problem is that many services use encrypted tokens that allow a user to not having to log in every session again. It are these tokens that can be intercepted and replayed. And unlike some other attacks on tokens, the amount of tries to decode one byte is very small compared to other attacks.
This new attack is even simpler than the regular POODLE, as it doesn’t require a SSL 3.0 connection but works with any TLS as well. But on the flip, it does only work with these machines that don’t check the padding.
@Peter is correct – the new finding relates to bad implementations of TLS rather than a problem with the TLS spec itself. See https://www.imperialviolet.org/2014/12/08/poodleagain.html for more details.
Well if our good friend Mr. Steve Gibson has said that it’s not a threat it truly must not be given that he’s known for predicting “the end of the internet” and so on 😀
So if I were to log in to my online banking account over a secure and private Wi-Fi connection would my information be at risk? Or is it only if you log on via unsecure Wi-Fi?
You’d be typically safe indeed, as nobody is there to save and modify/replay the data. The POODLE atatcks require an attacker to catch and modify the data.
(Except perhaps nation state attackers that can hack deep into the backbones. But e.g. our own government can get our bankaccount data if it wants to much easier other ways 🙂 )
Also if your bank has multi-factor authentication you’d be even safer as the login-data transmitted alone is not enough to break in.
I just spoke to the Vanguard technical support team, and I was told they have no vulnerability to the “Poodle” bug.
I’m inclined to believe Krebs over Vanguard.
Jeff I just ran a scan on vanguard and they haven’t fix it yet..
Seems some of their servers are patched and nothers are not.
When they say they are not vunerable, they might be referring to the fact they are using socalled RC4 stream cipher for encryption instead of a block cipher. Stream ciphers are not affected by POODLE as they have no padding, which is the attack vector. (RC4 is a weak cipher however but that is a different issue.)
Or they have some other defense mechanisms behind their frontends that prevent attacks. Remember that the SSL Labs test can only check the front-end, and banks do tend to have pretty solid SSL/TLS back-end protections, despite front-ends often using only older protocols and ciphers.
Or of course you could also just have talked to someone who didn’t know what you were talking about, and behind the scenes they are working on it… 🙂
Seems that as of today all servers are now patched. At least their log-in servers, which are the ones that matter here.
So seems indeed the representative you talked to just didn’t know what he/she talked about, but their IT guys were already hard at work.
I ran the test against http://www.freecreditscore.com and it has a “B” grade so not sure when this was written but it appears they have already corrected the issue with SSL v3.
Great Read Krebs
You can alos use our analyzer as well for sites that are affected?
and yes chase.com is one….
Enter your website URL at: https://sslanalyzer.comodoca.com. Sites with SSL 3.0 will be reported as ‘Vulnerable to the POODLE attack’
All the more reason to use cellular if you have decent signal. If you have to use public wifi look in to setting up an OpenVPN connection. I use the free OpenVPN iPhone app with the free pFSense router platform. 4096 bit DH keys AES-256-CBC or CAMELLIA-256-CBC encryption tunneling all traffic over UDP. Just about everything is configurable. You only need a public facing spot to put your pfsense machine. Using dynamic dns and a port forward at your home is a good place to start. Stay Safe 😀
Part of the reason that banks are not on the bleeding edge of security is because of security standards. If they deviate from them they can be liable. If they follow them even if they are flawed then it makes it harder for them to be sued as they followed the banking industry’s “best practices”
Why was I not surprised to see Experian listed as a website that is vulnerable?
If everyone kept their browser and patches updated, used NoScript and AdBlock Plus, only whitelisting trusted domains, the amount of potential exploits would drop by upwards of 99%.
Screw JavaScript, and don’t bother with sites that show 15 different tracking/ad domains on NoScript. Krebs’ site is actually good, nothing but google-analytics.
This goes for the darknet too. If you use Tor, DISABLE JAVASCRIPT in “about:config”.
If you don’t allow Javascript a huge percentage of sites are unuseable these days.
A happy medium is use the plugins you describe but only allow servers that are required for a site to run it (on a temporary basis if you wish however this is far to inconvenient for me on any site I use reguarly).
This is becoming less of a issues now since most modern browsers are moving away from using S.S.L. version 3.0
So. There are two related vulnerabilities.
One is POODLE which works against servers that support SSL3.
Another uses similar techniques but works against roughly 10% of the TLS only services.
The list of vulnerable servers seemed to be mostly intermediaries as opposed to traditional Web servers. Unfortunately, bigger entities are more likely to use them.
This site gets a ‘B’ from Qualys. The grade is capped because the site only supports TLS 1.0, not 1.2, and uses the RC4 cipher. There are some other notes in there about SHA1 with RSA used in certificates.
Still, a ‘B’ isn’t too bad. And the site isn’t vulnerable to Heartbeat or POODLE.
What does it mean when a site like Fidelity and Vanguard return different scores for different servers and how do you get to the more secure one with a browser?
In short, it means that their IT hasn’t done their job in fixing all of their properties — not a good sign.
If you manage to talk to a server in a forest of servers and your conversation can’t be intercepted, but someone with administrative privileges talks to another server in the same forest, and their connection is manipulated such that their credentials are recovered by an attacker, and the attacker then uses the credentials to further manipulate the server forest, you’re not in a great position. Perhaps the attacker struck first and inserted an equivalent of an XSS into the content that you retrieved.
If you have evidence that some of the servers in the forest are insecure, complain loudly — use Twitter, use Facebook.
Then call your provider and insist on banking by phone — explain carefully and calmly and slowly that you’re doing so because their websites are apparently insecure and you don’t trust them. Then after explaining, do your banking on the same call.
It costs the banks money to handle telephone banking. So, by doing it, you’re voting / voicing your opinion with their wallet. And by complaining using Twitter / Facebook, you’re raising their negative brand image — something else that they don’t want.
Continue banking by phone until it’s fixed.
You can also call and just ask them for a status upcoming weekly…
If you are paranoid to the Nth degree about this and suggesting to call in for all of your banking needs then I have to ask why you are trusting the person on the other end along with thinking that VoIP is being encrypted and not sniffed.
Some people use landlines and mobile still. I know, I know …
Fidelity and Vanguard return different scores because it are different servers. If you look closer you’ll see one of them is the http://www.Fidelity.com and the other is just Fidelity.com
The first is their main server which is just the regular webpage and contains no customer data. Once you login, I bet you will get redirected to someling like login.Fidelity.com or so. This is a separate set of servers which often runs completely different software. SSL Labs detects this and hence returns scores for boths.
Many companies use setups like this.
FYI: Regular users with some basic knowledge can protect themselves by disabling the use of SSLv3 within their web browser: see https://zmap.io/sslv3/browsers.html. They can then test if it’s effective by going to: https://dev.ssllabs.com/ssltest/viewMyClient.html
Not really. Regular users should update their browsers — most updated browsers have disabled SSL3.0.
But that only protects against the October POODLE vulnerability disclosure.
It doesn’t protect against the December POODLE 2.0 vulnerabilities in some TLS server implementations.
This, like Heartbleed is first and foremost a server side bug, and the only fix is for the servers to be fixed; for you to not talk to them until they are; and for you to consider that it’s possible for your credentials to have been compromised if you spoke to the server before they deployed the fix.
The fact that these big banks have long windows of exposure to these encryption vulnerabilities (POODLE, Heartbleed, more) tells me that remediation of these vulnerabilities is a nightmare. We as an industry need to get better at remediating encryption weaknesses, faster and completely. Exploiting these vulnerabilities has the potential to undermine the greater security program… bad for privacy, bad for all.
Actually banks were in most cases NOT vunerable to Heartbleed at all. And they are often also not vunerable to *regular* POODLE, as they use RC4 as default cipher.
What this article is about is a variant of POODLE, which affects only some very specific software. Unfortunately these specific vendors are very popular in the financial industry, and hence why now so many banks are hit.
In general I cannot agree with a statement banks are careless in their SSL/TLS, as in fact they are often very careful.
Well said. Banks and other financial institutions have customers who still use IE6 and Windows XP. They would be closing their doors to those customers if they stopped supporting SSL3 connections.
I’m not sure why banks are singled out. F5 load balancers are used widely for a variety of industries. Just search your cookies for BigIP and you’ll see them everywhere.
That aside, there seem to be a lot of the Reader’s Digest set making uninformed comments on this site. Managing a fleet of load balancers for a global enterprise is no small challenge. Try patching a few hundred of them at the drop of a hat without disrupting operations and then come back with brainless comments about how banks are slow-moving and old fashioned. Also, it’s not like F5s customers knew of the possibility of the exploit to TLS much less how F5 modified their implementation of it. Most technology vendors don’t open up their key product to public scrutiny and their customers will typically not know of these issues until somebody wants to make news off the back of a big name (as opposed to waiting until it’s patched before throwing the turd into the fan). Notice how everybody is making a big stink about the banks; try looking around a little more and you’ll see that there are plenty of smaller organizations with the same issues–they’re just not as interesting news subjects. Nobody cares if a tiny credit union has this problem, but throw some big names in the story and you have a a lot more clicks coming your way. Let us not forget that news is a business. While I’m grateful for this and other sites that will report on critical issues, they all have to compete for a share of the audience and there will always be a slice of hype to go with the news.
Anyone have a definitive answer to: does the new TLS vulnerability (not the original Poodle vuln.) affect common web applications such as Apache/Tomcat/IIS/nginx/etc. ?
Or is this a hardware/appliance related problem for the most part?
Unfortunately I have no hosts on the internet I can use any of the scanners against, everything is behind firewalls and not reachable.
It does not.
It only affects specific software. At this moment only three are identified: F5, A10 and old (= early 2010) NSS-based software. For all three, upgrading to the latest versions will solve it.
Specifically, Microsoft IIS, ngix and Apache are not vunerable at all.
Of course larger organisations often use a combination of products and devices. So you could have a F5 load balancer in front of a different server. Also they may use different systems for the regular webserver and the ones specifcially handling login traffic.
When in doubt you can always use http://www.ssllabs.com and enter a domain. It will test for this among other things. (Although in your case as I understand that is not possible.)
Honestly, this article should have been titled “Vendor Releases Patch”. It must’ve been a slow news day in the IT security blogging business. For all of you soap-boxers out there (Paul, Eng, et al.) please at least indicate you read the accompanying links before you join Brian’s “bash the banks” crusade. This vulnerability was released on 12/8. Get a grip. For those of you whose “network” consists of an ATT residential gateway, please recognize that the “big bank” systems you wax on about are a bit more complicated. Give it a day or two.
By all accounts, this should’ve been included in the cut-and-paste monthly MS and Adobe patch blog Brian creates. I understand that bloggers need content, but honestly there’s a bit of sensationalism going on here.
@JvH – Give it a day or two – absolutely. However, that would be about the limit. If a financial institution can’t patch their services in that time frame their commitment to security needs to be improved.
Chase “we are fully committed to security” Financial Services still hasn’t implemented a fix – and it’s now been five days since the vulnerability was published.
I was astounded to find that Chase doesn’t provide a means for customers to report vulnerabilities. In addition, even now they still haven’t informed their Customer Service staff about the POODLE TLS vulnerability.
Then again, the requirements set forth by the Payment Card Industry (PCI) itself are rather lax. According to the PCI-DSS (6.1) merchants have a full month to apply “critical security patches”.
From a security perspective that’s simply insufficient.
By they way, Chase uses F5’s BIG-IP equipment. F5 released a patch on 12/8. It literally takes longer to log into the ADC than it takes to apply the fix. Assuming that they are using some kind of sync process I can’t think of a legitimate reason for the failure to patch the systems right away. Unless, of course, one regards the PCI-DSS to be a legitimate reason.
In that case they have until January 8 to fix the problem…
Good companies will also be good providers of such service.
The Springfield area Carrier dealer is Knight Heating
and Air in Nixa. In the same sense you should not let your home dry out either.
I am conflicted about to do. My wife runs a small business and we depend critically on a service provider that runs a host-based appointment booking/business management web application. Critically to us this application provides our web portal for sales of the gift certificates. Their commerce website passes with flying colors 4 of the 5 tests in the Qualys Labs scanner but they pull an F because they are allowing the broken TLS implementation. I want to email them about their use of the bad software but I worry that they my be more worried about hiding the problem than fixing it. The company running the site is a large concern based on the east coast with a huge customer base so they surely must know about this issue but each day I check their site and they have not upgraded the defective software. What would you do in my place? Ask them what gives and when a fix will be in place? If they get nasty at me and cut off access of my wife’s company to the we site that would cost me more money than I can afford to lose…
It’s not difficult to patch your F5 equipment, especially if you bought Enterprise Manager or BigIQ. Like the above poster said, the patch came out right away. So it’s hard to believe that a lot of companies haven’t applied it yet.