Freak Attack - Surprised? No. Worried? A little.
There has been some press surrounding the SSL issue published recently dubbed Freak. It was reported in the Washington post1 and other sites, but what does it really mean?
The issue relates to the use of Export Ciphers (the crypto equivalent of keeping the good biscuit yourself and giving the smaller broken one to your little brother or sister). The Export Ciphers were used as the "allowed" ciphers for non US use. The ciphers are part of OpenSSL and the researchers2 have identified a method of forcing the exchange between a client and server to use these weak ciphers, even if the cipher suite is not "officially" supported3.
On first reading, like many, I thought so what, especially since you have to do a man-in-the-middle (MITM) attack. When you do a MITM attack you have full control over the connection anyway, so why bother decrypting anything? However, if I'm reading and interpreting the examples correctly (kind of hoping I'm wrong), it looks like this particular attack solves one challenge that a MITM has. For HTTPS intercept you usually generate a new certificate with the information of the site and resign the certificate before presenting it to the client. Whenever you present this newly signed certificate the client receives an error message stating that the certificate does not match the expected certificate for the site. From the vids2 it looks like this attack could "fix" that particular problem. So now when you perform a MITM attack you retain the original certificate and the user is none the wiser. This could open up a whole new avenue of attacks against clients and potentially simplify something that was quite difficult to do.
What is the impact to organisations? Well it is quite possible that your sites will be impersonated and there won't be much that can be done about it and you may not even know that your customers are being attacked. To prevent your site from being used in this attack you'll need to patch openSLL4 (yes again). This issue will remain until systems have been patched and updated, not just servers, but also client software. Client software should be updated soon (hopefully), but there will no doubt be devices that will be vulnerable to this attack for years to come (looking at you Android).
Matthew Green in his blog3 describes the attack well and he raises a very valid point. Backdoors will always come back to bite.
The researchers have set up a site with more info5.
Cheers
Mark H - Shearwater
(Thanks Ugo for bringing it to our attention).
Links:
1 - http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-undermines-security-for-apple-and-google-users-researchers-discover/
2 - https://www.smacktls.com/#freak
3 - http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
4 - https://www.openssl.org/news/secadv_20150108.txt
5 - https://freakattack.com/
Comments
#1 The bug that was fixed in January was a client only bug (CVE-2015-0204) and wasn't a server code bug. Client side of connection will allow downgrade to a cipher suite (EXPORT ones) even when client is configured not to.
#2 There is no bug to patch on the server side, the servers in question that make the attack possible are just horribly misconfigured to allow insecure ciphers. One line config fix in apache/nginx/etc
#3 If server was properly configured, it wouldn't matter that client isn't patched yet while talking to that server.
The MITM exploit will only work if the server supports one of the EXPORT cipher suites in the negotiation. MITM attack tells server that ONLY cipher client supports in an EXPORT cipher. Server would look at its list and if it supports EXPORT as well then will start the connection. A properly configured server wouldn't support such an insecure cipher, so connection drops. (have tested this with a POC)
Which means if you are a proper sysadmin and have been mitigating against poodle, beast, and all the other things over the last couple of years then the EXPORT ciphers wouldn't be in your config in the first place and your servers wouldn't be exposing users. The key statement is in the freak description: "Thus, if a server is willing to negotiate an export ciphersuite, a man-in-the-middle may trick a browser" If server is configured properly it's not willing because weak ciphers are disabled.
If you look at the list of servers that they say need "patching" they are really just misconfigured. They cipher suite list is configured so they are offering the secure suites but also are offering:
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8)
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)
TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)
To fix that is just a configuration line change in the offered cipher suites in the server config. In an age where everyone is telling you to disable that even RC4 isn't secure anymore why would the horrible export ones still be enabled? There are articles going back 5 or more years telling people to disable these TLS/SSL cipher suites. I am amazed that this is still so pervasive.
Required reading for any sysadmin with a web server: https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf
The only difference between this attack and any other standard MITM TLS/SSL downgrade attack is the bug in the client. As most modern browsers ditched the EXPORT level ciphers a long time ago and wouldn't negotiate them per their configs....or so we thought. The bug in openssl meant that many browsers weren't honoring the config and doing it anyway. Which makes this particular type of downgrade attack possible.
Or am I missing something here?
Anonymous
Mar 4th 2015
9 years ago
Our theory is that the way a company runs their Internet sites and systems is akin to driving through a neighborhood. Most houses are fairly nice, a few are superb and sometimes there's one or two with refrigerators on the porch, junk cars in the yard, overgrown vegetation, broken windows and doors, you get the picture.
If someone is taking good care of the outside of their home, chances are good that the inside is maintained pretty well. If the outside is a mess, chances are really good the inside is even worse because that's where they spend most of their time.
Networks and data center operations seem to follow the same logic. If the Internet systems are great, the internal network is likely to be reasonable. If the Internet sites have massive problems, the internal systems are usually worse.
Having those ciphers enabled on Internet-facing systems halfway through the second decade of the 21st century is just negligence. It tells me that even basic configuration management isn't occurring. Default installations of "Next -> Next -> Install -> Finish. It works!" are how its done.
It tells me that if they have any type of security department, they're either untrained or being restrained. Or "Security is part of everyone's job." meaning it's no one's job.
It is extremely common for us to find serious misconfigurations on "cloud" hosting providers. The big names are among the worst for doing default installations of web servers, DNS servers and SMTP servers. That tells me that the cloud providers really are throwing default installations over the wall to customers and walking away from them via the contract. Companies are driving the equivalent of junker cars with active recalls and don't even know it because, hey, it's not our car! Why should we take care of it? We're paying them good money!
Searching that list for "bank" shows too many names and there are too many large retail sites on it. How could any of those sites have passed their PCI compliance? It's easy. Being under the jurisdiction of PCI and having major fails like this tells me that the company is compliance check-the-box focused. If PCI doesn't say its bad, they're not going to do anything. Target would have been on that list right after their breach.
Having problems like this marks a site as an easy target in the eyes of the criminals, just like having problems with the outside of your home marks you as not caring.
Being subject to compliance mandates like PCI and doing the bare minimum to check the box tells the attacker just how easy you are to breach. Just go after everything else.
Anonymous
Mar 4th 2015
9 years ago
See https://blogs.akamai.com/2015/03/cve-2015-0204-getting-out-of-the-export-business.html
Anonymous
Mar 4th 2015
9 years ago
Some things needs to be adjusted here. Being under PCI Compliance does not mean following every single word, to the letter. It starts by understanding and addressing the risks.
A website is just a poster, right ? I think it's xkcd that put it best. The bank's website can be lame, that doesnt mean their payment solution is lame. Going back to the neigborhood analogy, remember that while you're driving down the WWW street, the house may have a bad front yard, but when you step on the doormat, you're not in Kansas anymore... Web site redirection can mess things up, always look at the FQDN first
Something else to remember, the payment industry is about payment, not security. That's bad, you might say but it means a business has to be profitable for it to remain. And this is where risk management should/must/does come in to play.
I run a shop where SSLv3 is still used because our clients still use it. And while we're pressing them to change to our newest services, we have to manage the risk. If we were to comply to NIST/PCI blindly, we would simply go under...
Also, SSLv3, POODLE, and FREAK, and everything else we see, is about web browsing. The payment industry is also about payment terminal, or IP Terminals. Those are dedicated micro-processors with firmware and they don't change easily. Most of them use SSLv3 or TLSv1 (and probably don't understand TLS_FALLBACK_SCSV). But they also do not use HTTPS, they run Serial over IP with SSL/TLS. And none of that has been proven weak, thus far. When I read people claiming RC4 128 is bad, I go back to the papers being cited and I don't see an issue *outside of web browsing*.
What is happening here is that people are reading the headlines, not reading the articles and then proclaiming the world is about to end.
The last straw, to me, is this announcement, being repeated: https://www.darasecurity.com/article.php?id=33
What's wrong you might ask ? The NIST document was issued last May. Some people repeat this as if it was headline news...
Anonymous
Mar 4th 2015
9 years ago
Yeah, it's usually worse. Ever wonder why your bank limits your online banking user name and password to eight alphanumeric characters only? It's called an old mainframe. Yes, I currently manage the information security function for a large bank and have for several years. I've lived through about every excuse ever made.
"And this is where risk management should/must/does come in to play."
The worst two words ever concocted for the protection of information are "risk management". Because risks are theoretical until they happen to you so people rationalize away dealing with risk. Lived through too much of that also.
"I run a shop where SSLv3 is still used because our clients still use it. And while we're pressing them to change to our newest services, we have to manage the risk. If we were to comply to NIST/PCI blindly, we would simply go under..."
If you're required to be PCI compliant, the forthcoming PCI-DSS 3.1 revision is about to declare all versions of SSL as unacceptable. Other standards will soon follow. You may be firing some of your customers because they are presenting a risk to your business. Unacceptable in PCI-speak means no compensating control is acceptable.
"Also, SSLv3, POODLE, and FREAK, and everything else we see, is about web browsing."
Uh, no, it's not. Think of FTPS (FTP over SSL) and TLS SMTP. It's also about susceptible web services. Think Heartbleed and OpenSSL.
"Those are dedicated micro-processors with firmware and they don't change easily. Most of them use SSLv3 or TLSv1 (and probably don't understand TLS_FALLBACK_SCSV). But they also do not use HTTPS, they run Serial over IP with SSL/TLS."
Irrelevant. You need to protect the data. That can and is done in these situations by segmenting the devices off (which they should be anyway) and then front-ending them with reverse proxies, load balancers or other SSL-terminating devices. That way you run the secure protocol across the network where it's exposed and let it run insecure protocols back to the devices.
Or you practice "risk management" and accept the risk without doing anything.
Anonymous
Mar 5th 2015
9 years ago