Tuesday, 3 March 2015

Cryptography Engineering: Attack of the week

This is the story of how a handful of cryptographers 'hacked' the NSA. It's also a story of encryption backdoors, and why they never quite work out the way you want them to.
But I think I'm getting ahead of myself a bit here.
Today's Washington Post has the story of a nasty bug in some TLS/SSL servers and clients, one that has the potential to downgrade the security of your TLS connections to something that isn't really secure at all. In this post I'm going to talk about the technical aspects of the attack, why it matters, and how bad it is.
If you don't want to read a long blog post, let me give you a TL;DR:
A group of cryptographers at INRIA, Microsoft Research and IMDEA have discovered some serious vulnerabilities in OpenSSL (e.g., Android) clients and Apple TLS/SSL clients (e.g., Safari) that allow a 'man in the middle attacker' to downgrade connections from 'strong' RSA to 'export-grade' RSA. These attacks are real and exploitable against a shocking number of websites -- including government websites. Patch soon and be careful. 
You can find a detailed description of the work by the researchers -- Beurdouche, Bhargavan, Delignat-Lavaud, Fournet, Kohlweiss, Pironti, Strub, Zinzindohoue, Zanella-B├ęguelin -- at their site SmackTLS.com. You should go visit that site and read about the exploits directly. The proof of concept implementation also involved contributions from Nadia Heninger at U. Penn.
I'm going to explain the rest of it in the 'fun' question and answer format I save for this kind of attack.
What is SSL/TLS and what are ‘EXPORT cipher suites’ anyway?
In case you’re not familiar with SSL and its successor TLS, what you should know is that they're the most important security protocols on the Internet. In a world full of untrusted networks, SSL and TLS are what makes modern communication possible.
Or rather, that’s the theory. In practice, SSL and TLS have been a more like a work in progress. In part this is because they were developed during an era when modern cryptographic best practices weren't nailed down yet. But more to the point: it's because even when the crypto is right, many software implementations still get things wrong.
With all that in mind, there’s a third aspect of SSL/TLS that doesn't get nearly as much attention. That is: the SSL protocol itself was deliberately designed to be broken
Let me explain what I mean by that.
Back in the early 1990s when SSL was first invented at Netscape Corporation, the United States maintained a rigorous regime of export controls for encryption systems. In order to distribute crypto outside of the U.S., companies were required to deliberately 'weaken' the strength of encryption keys. For RSA encryption, this implied a maximum allowed key length of 512 bits.*
The 512-bit export grade encryption was a compromise between dumb and dumber. In theory it was designed to ensure that the NSA would have the ability to 'access' communications, while allegedly providing crypto that was still 'good enough' for commercial use. Or if you prefer modern terms, think of it as the original "golden master key".
The need to support export-grade ciphers led to some technical challenges. Since U.S. servers needed to support both strong and weak crypto, the SSL designers used a 'cipher suite' negotiation mechanism to identify the best cipher both parties could support. In theory this would allow 'strong'
EXP-RC4-MD5.
clients to negotiate 'strong' ciphersuites with servers that supported them, while still providing compatibility to the broken foreign clients.
This story has a happy ending, after a fashion. The U.S eventually lifted the most onerous of its export policies. Unfortunately, the EXPORT ciphersuites didn't go away. Today they live on like zombies -- just waiting to eat our flesh.
If EXPORT ciphers are known to be broken, what's the news here?
We don't usually worry about export-grade cipher suites very much, because supposedly they aren't very relevant to the modern Internet. There are three general reasons we don't think they matter anymore:
  1. Most 'modern' clients (e.g., web browsers) won't offer export grade ciphersuites as part of the negotiation process. In theory this means that even if the server supports export-grade crypto, your session will use strong crypto.
  2. Almost no servers, it was believed, even offer export-grade ciphersuites anymore.
  3. Even if you do accidentally negotiate an export-grade RSA ciphersuite, a meaningful attack still requires the attacker to factor a 512-bit RSA key (or break a 40-bit symmetric cipher). This is doable, but it's generally considered too onerous if you have to do it for every single connection.
This was the theory anyway. It turns out that theory is almost always different than practice. Which brings us to the recent work by Beurdouche et al. from INRIA, Microsoft Research and IMDEA.
What these researchers did was develop a fairly beautiful piece of formal analysis tooling that allows them to 'fuzz' the state machines of most modern SSL/TLS implementations. They found a bunch of wonderful things in the course of doing this -- some of them quite nasty. I'm not going to cover all of them in this post, but the one we care about here is quite simple.
You see, it turns out that some modern TLS clients -- including Apple's SecureTransport and OpenSSL -- have a bug in them. This bug causes them to accept RSA export-grade keys even when the client didn't ask for export-grade RSA. The impact of this bug can be quite nasty: it admits a 'man in the middle' attack whereby an active attacker can force down the quality of a connection, provided that the client is vulnerable and the server supports export RSA.

The MITM attack works as follows:
  1. In the client's Hello message, it asks for a standard 'RSA' ciphersuite.
  2. The MITM attacker changes this message to ask for 'export RSA'.
  3. The server responds with a 512-bit export RSA key, signed with its long-term key.
  4. The client accepts this weak key due to the OpenSSL/SecureTransport bug.
  5. The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
  6. When the client encrypts the 'pre-master secret' to the server, the attacker can now decrypt it to recover the TLS 'master secret'.
  7. From here on out, the attacker sees plaintext and can inject anything it wants.
So that's bad news and it definitely breaks our assumption in point (1) above. But at least in theory we should still be safe based on points (2) and (3).
Right?
How common are export-enabled TLS servers?
No matter how bad you think the Internet is, it can always surprise you. The surprise in this case is that export-grade RSA is by no means as extinct as we thought it was.
Based on some recent scans by Alex Halderman, Zakir Durumeric and David Adrian at University of Michigan, it seems that export-RSA is supported by as many as 5.2% 36.7% (!!!!) of the 14 million sites serving browser-trusted certs. The vast majority of these sites appear to be content distribution networks (CDN) like Akamai. Those CDNs are now in the process of removing export grade suites.
While the numbers are impressive, the identity of those sites is a bit more worrying. They include U.S. government sites like www.nsa.gov (Oy vey), www.whitehouse.gov and www.irs.gov. It turns out that the FBI tip reporting site (tips.fbi.gov) was also vulnerable.
Vulnerable sites also included connect.facebook.net, which is the source of the famous Facebook 'Like' button which shows up on secure web pages all over the Internet. Attacks on these connections could lead to content injection on a huge number of web pages.
(Facebook have updated their configuration as a result of this work.)
Factoring an RSA key seems pretty expensive for breaking one session.
This brings us to the most awful part of this attack. You don't have to be that fast.
You see, it turns out that generating fresh RSA keys is a bit costly. So modern web servers don't do it for every single connection. In fact, Apache mod_ssl by default will generate a single export-grade RSA key when the server starts up, and will simply re-use that key for the lifetime of that server.
What this means is that you can obtain that RSA key once, factor it, and break every session you can get your 'man in the middle' mitts on until the server goes down. And that's the ballgame.
PoC or GTFO.
This is what happens to EC2 spot pricing
when Nadia runs 75 'large' instances
to factor a 512-bit key.
Just because someone says an implementation is vulnerable doesn't mean it actually is. You should ask for proof. 
Fortunately, a proof of concept for this attack requires only a few ingredients. First, you need some tooling to actually run the MITM attack. Then you need the ability to (quickly) factor 512-bit RSA keys. From there it's just a question of finding a vulnerable client and server.
The guts of the PoC were put together by Karthik Bhargavan and Antoine Delignat-Lavaud at INRIA. They assembled an MITM proxy that can intercept connections and re-write them to use export-RSA against a willing website.
To factor the 512-bit export keys, the project enlisted the help of Nadia Heninger at U. Penn, who has been working on "Factoring as a Service" for exactly this purpose. Her platform uses cado-nfs on a cluster of EC2 virtual servers, and (with Nadia doing quite a bit of handholding to deal with crashes) was able to factor a bunch of 512-bit keys -- each in about 7.5 hours for $104 in EC2 time.
From there all you need is a vulnerable website. 
Since the NSA was the organization that demanded export-grade crypto, it's only fitting that they should be the first site affected by this vulnerability. There's great video on the SmackTLS site. After a few hours of factoring, one can take the original site (which looked like this):

And change it into this:

Attack images courtesy Karthik, Antoine INRIA.

Very dramatic.

Some will point out that an MITM attack on the NSA is not really an 'MITM attack on the NSA' because NSA outsources its web presence to the Akamai CDN (see obligatory XKCD at right). These people may be right, but they also lack poetry in their souls.
Is it patched?
The most recent of OpenSSL does have a patch. This was announced (though not very loudly) in January of this year.

Apple is working on a patch.

Akamai and other CDNs are also rolling out a patch to solve these problems. Over the next two weeks we will hopefully see export ciphersuites extinguished from the Internet. In the mean time, try to be safe.
What does it all mean?
You might think this is all a bit absurd and doesn’t affect you very much. In a strictly technical sense you’re probably right. The client bugs will soon be patched (update your devices! unless you have Android in which case you're screwed). With good luck, servers supporting export-grade RSA cipher suites will soon be rare curiosity.
Still, to take this as the main lesson of the work would, I think, be missing the forest for the trees. There’s a much more important moral to this story.
The export-grade RSA ciphers are the remains of a 1980s-vintage effort to weaken cryptography so that intelligence agencies would be able to monitor foreign traffic. This was done badly. So badly, that while the policies were ultimately scrapped, they’re still hurting us today.
This might be an academic point if it was only a history lesson. However, for the past several months, U.S. and European politicians have been publicly mooting the notion of a new set of cryptographic backdoors in systems we use today. While the proposals aren't explicit, they would presumably involve deliberately weakening encryption tech so that governments can intercept and read our conversations. While officials carefully avoid the term “back door” — or any suggestion of weakening our encryption systems against real attackers — this is wishful thinking. These systems are already so complex that even normal issues stress them to the breaking point. There's just no room for new backdoors.
To be blunt about it, the moral is pretty simple:
Encryption backdoors will always turn around and bite you in the ass. They are never worth it.

Gulshan Rai becomes first chief of cyber security; post created to tackle growing e-threats

BENGALURU: The Narendra Modi government has created a cyber-security chief's position under the Prime Minister's Office and has appointed Gulshan Rai, said a top official in the IT ministry.

Rai, who has been heading the computer emergency response team at the department of electronics and information technology (DeitY), will now take charge as special secretary for cyber security, people familiar with the development told ET.

Rai has been working since 1998 in the area of evevolving legal framework to address issues arising out of cyberspace. He is also expected to head the national cyber coordination centre (NCCC) that the government is also setting up with a budget of Rs 1,000 crore. He was for a long time tipped to become the first national cyber security coordinator. Rai couldn't be reached for comments. DeitY has already posted a vacancy for the post of director general for Indian computer emergency response team.

Cyber security is fast becoming a nightmare for the government even as its Digital India initiative will increase the relevance of the internet and expose the country to large cyber-attacks.
BENGALURU: The Narendra Modi government has created a cyber-security chief's position under the Prime Minister's Office and has appointed Gulshan Rai, said a top official in the IT ministry.

Rai, who has been heading the computer emergency response team at the department of electronics and information technology (DeitY), will now take charge as special secretary for cyber security, people familiar with the development told ET.

Rai has been working since 1998 in the area of ev ..

BENGALURU: The Narendra Modi government has created a cyber-security chief's position under the Prime Minister's Office and has appointed Gulshan Rai, said a top official in the IT ministry.

Rai, who has been heading the computer emergency response team at the department of electronics and information technology (DeitY), will now take charge as special secretary for cyber security, people familiar with the development told ET.

Rai has been working since 1998 in the area of ev ..

GCHQ opens applications for cyber security summer school

gchq.jpg
UK intelligence agency GCHQ is inviting applications to a 10-week cyber security summer school in an initiative to keep the UK safe and identify prospective recruits.

According to the Cisco 2014 Annual Security Report, more than one million positions for information security professionals remain unfilled around the world.
gchq.jpg

The course is set to run from 6 July 2015 and is aimed at providing first- or second-year computer science students with cyber security insights from specialists at GCHQ and leading technology companies.

GCHQ is constantly developing innovative ways to combat a range of threats in cyber space from cyber criminals, terrorists, hackers, fraudsters and paedophiles.

The agency also works to protect UK forces around the world and, through its information security arm CESG, provides policy and assistance on the security of government communications and data.

To qualify for the course in Cheltenham, candidates need the ability to solve a variety of complex problems and advanced coding skills in at least one of the following: Perl, Python, JavaScript and C.

They will also need to show that they can work well both in a team and independently, said GCHQ.

On the course, they will work with a wide range of technologies, from legacy systems that have been in use for a number of years to the most up-to-date mobile technology.

Students will be taught technical skills in areas such as cyber security, ethical hacking, penetration testing and security networks. They will also learn about GCHQ’s role in defending the UK against cyber threats.

The course will culminate in a "live" exercise where students will be able to put into practice the skills that they have learned.

GCHQ will pay students £2,500 to attend the course and will provide accommodation in the Cheltenham area. On successful completion of the programme, students will receive a GCHQ certificate.

The Cyber Insiders Summer School is open to all UK nationals studying computer science at university who have the required skills.

“The unique Cyber Insiders Summer School offers computer science students a fantastic opportunity to enhance their cyber skills and discover how GCHQ use a variety of technologies to protect the UK,” said a GCHQ spokesman.

“They’ll not only enhance their cyber knowledge, but completing the programme will also look good on their CV and, if they prove their abilities, we may even offer them a job interview,” he said.

Prospective candidates are invited to apply through GCHQ’s careers website. Applications close on 9 March 2015.

The spy who leaked me: Ex-CIA boss Petraeus 'fesses up to blabbing intel to his mistress

The US Department of Justice has reached a settlement with General David Petraeus allowing the former military leader and ex-head of the CIA to avoid prison for handing over classified information to his lover.
Petraeus has agreed to plead guilty to a misdemeanor charge: one count of unauthorized removal and retention of classified material, with a possible sentence of one year in prison, $100,000 fine, and five years of probation. He also admitted misleading federal investigators.
Under the terms of the deal, federal prosecutors will ask for a two-year suspended sentence and a $40,000 fine. The misdemeanor charge will draw a line under the sordid affair that ended the public career of a man once touted as presidential material.
Petraeus spent 37 years in the US Army, ending up as head of theater in Iraq and Afghanistan. While on duty he recorded his daily schedule and notes on classified and unclassified information in military-issue five-by-eight inch Black Books.
In a deposition Petraeus admitted handing over these notebooks to his biographer and mistress Paula Broadwell, and leaving them with her for four days. Broadwell later wrote her book All in: The education of David Petraeus, but investigators said classified material did not make it into the biography.
David Petraeus and Paula BroadwellDavid Petraeus and Paula Broadwell in happier times
In April 2011 Petraeus was nominated to become head of the CIA, and resigned from the army to take up the role in September that year. The married spyboss was forced to resign barely a year later when his affair with Broadwell became public following an FBI probe into cyberbullying.
In the summer of 2012, Jill Kelley, a friend of Petraeus, received threatening emails warning her to stay away from the four-star general. Kelley asked the Feds to investigate, and the email trail led back to Broadwell, at which point her intimate connection with Petraeus was discovered.
When questioned by the FBI, Petraeus denied giving classified information to Broadwell, but her emails mentioned borrowing the Black Books. Federal prosecutors recommended felony charges.
A court must approve the plea deal. According to the court filings [PDF] Petraeus is being reprimanded for abuse of trust and obstruction of justice, but is credited with admitting his crime.
The misdemeanor charge won't interfere with his role as partner in the New York private equity fund Kohlberg Kravis Roberts, or his visiting professorship at the UK's University of Exeter.

Outbreak! Fake Amazon voucher offer seeds mobile malware attack

Flytrap
Spoofed Amazon vouchers are being used to spearhead a campaign to contaminate Android mobiles with malware, messaging security firm AdaptiveMobile warns.
The attack, dubbed "Gazon", sends messages to victims’ mobile phone contacts linking to supposed offers for (non-existent) Amazon vouchers fictitiously promising a gift of $200. The messages, if opened on an Android, actually attempt to install malware that restarts the infection cycle and launches a fresh wave of mobile malware scam messages.
The attack has generated more than 16,000 click-throughs across multiple channels, including Facebook and email, infecting thousands of mobile devices in more than 30 countries, since it first surfaced on 25 February. SMS remains the primary channel for distribution, accounting for more than 99 per cent of the malicious messages, according to AdaptiveMobile.
The assault has spread far and wide reaching Australia, the UK, Canada, France, India, Korea, Mexico and the Philippines after initially appearing in the US late last month.
More details on the attack – including screenshots of the dodgy messages – can be found on the AdaptiveMobile blog here.