SuperFREAK!

TOTW 6th March 2015 Thumbnail.Two related threats have piqued our interest this week – the Lenovo/Superfish idiocy and the FREAK attack. Not just because it gives an excuse to write this article to a background track of some SuperFreaky 80s music, but also because the two issues are intertwined and together illustrate how there can be unintended consequences when you start messing around with cryptographic trust.

Let’s take SuperFish first. Lenovo got paid $250,000 to abuse the trust of their customers by side-loading this ‘SuperFish’ application onto a bunch of laptops. Stupid Lenovo. The SuperFish app is designed to run silently on a users machine replacing normal advertising banners with those of SuperFish’s partners. Annoying, sure, its just a fairly typical example of bloat-verging-on-malware. What made this particular version poisonous was the inclusion of some tech from a sketchy outfit called Komodia, that performed a man-in-the-middle attack on SSL sessions in order to replace the advertising on ‘secure’ sites. All without asking you, and doing so in such a badly designed way that it left affected users wide open to any in-line attacker being able to spoof any website of their choosing.

What’s notable, beyond the stupidity of multiple people within Lenovo, is that this went unnoticed for longer than it should have, largely because the ‘attack’ used exactly the same approach that a lot of enterprises use to implement the SSL decryption needed for things like firewall based malware detection and data loss protection to work (side loading a privately signed Root CA). Clever browsers, using protocols like HSTS and HPKP should really have flagged to the users that the SSL certificate was being issued by an imposter. However it failed to do so because HSTS and HPKP have had to be neutered in the name of allowing ‘next gen’ firewalls and Starbucks Wifi to work smoothly…(they look for spoofed commercially issued certs indicative of CA compromise but have to ignore private root CAs).

The second example of the law of unintended crypto consequences is FREAK (Factoring attack on RSA-Export Keys), announced late this week. Taking advantage of a hangover from the late 90s ‘Crypto Wars’, when the USA considered strong encryption a weapon; it turns out that attackers can, when both a server is misconfigured and a client vulnerable, downgrade an SSL connection to an extremely weak ‘Export Grade’ encryption algorithm. This is now weak enough that it can be cracked using an Amazon Cluster in a few hours – this weakness is then further compounded by the fact that most vulnerable servers only generate a single ‘export grade’ key at boot – so cracking the keys once is enough to spoof every session thereafter for any given website. The end result being that an in-line attacker can spoof websites of their choosing (as detailed and shown to amusing effect in the video at: https://www.smacktls.com/)

Over the coming days and weeks, you should scan and fix your estate for FREAK by disabling export grade suites on webservers and patching clients when those patches are available. Confirm the vulnerability of HTTPS based VPN appliances, and anything else where users may enter credentials, in particular. There’s absolutely no need to have these export grade algorithms supported by anything any more. Patching servers to drop support for these ciphers is easy and extremely low risk.

One thing that’s been noted by our friends over at SkyHigh networks is that an awful lot of Cloud services are not only vulnerable but have also been slow to respond with patching. This is quite disappointing. Disabling these ancient ciphers is quick, easy and low risk – haven’t we had enough SSL vulnerabilities for providers to figure out a way of expediting these changes yet?

Oh, and after that round of patching is done, we really need to start talking about SSL more widely. The protocol has structural flaws that on one hand, we’re having to patch when abused, but then on the other, are abusing ourselves when it suits – be that in the name of delivering advertising or fighting malware. So just how can we fix SSL and make certificate issuance more transparent, more trustworthy? It’s hard, but we need to figure it out. Initiatives like the .trust specification are a good start – let’s build on them and make sure we really understand the consequences of breaking SSL, even when it is done with good intentions.

As ever, if you need some help with assessing your organisational exposure to FREAK, be that across your server estate or indeed across the cloud services that you use, then get in touch via the normal: [email protected] / 020 7517 3900. They’ll happily chat to you about elliptic curves, too.