Heartbleed Defense-in-Depth: SSL Is Not to Be Trusted, Part #2
This post is the second of a blog mini-series (see part #1 here) around the Heartbleed vulnerability and some of defense-in-depth techniques we've had in place for years that helped mitigate its impact. Stay tuned for additional posts throughout the week!
No one can predict the variety or impact of Internet-ending cyber-pompeii vulnerabilities. Whether it's the Kaminsky DNS poisoning, Mark Dowd owning your Sendmail MTAs, or fun Apache remotes, the Internet is guaranteed to come to a screeching halt every couple years. You will know when this happens, since your relatives will post on your Facebook wall to ask you if it's safe to shop online or send family pictures from their AOL account and will, for the first time, take an interest in what you do in your security profession.
But still, if we had done a "Security Family Feud" about the next big vulnerability, survey says zero people would have expected an Internet-scale infoleak compromising confidential data, passwords, private key material, session identifiers, and address space information (why is no one talking about those nginx remotes that suddenly became 100% reliable?) of all OpenSSL-based SSL/TLS services.
So everyone scrambles reactively to patch their servers, rotate passwords and keys, post buggy patches to mailing lists, and blast notifications to their users to promote themselves as a vendor that really cares about security. Because hitting that send button in your marketing automation platform faster than everyone else is the one true metric of security.
At Duo, we like to boast that we've designed our two-factor service with security in mind from day one. But we're often boasting to ourselves (or to my cats) and don't broadly externalize those design decisions or our philosophies around defense-in-depth. However, while the Heartbleed vulnerability is generally a "Bad Thing" for the Internet as a whole (hey, a lot more TLS 1.2 will be in use now, eh?), it has provided good motivation for me to fire up
vim and externalize some of our defensive mechanisms that helped mitigate the impact of Heartbleed for Duo customers.
##Man, SSL has had a rough few years
NOTE: We'll be using SSL and TLS interchangeably through this post.
SSL has been broken many times before, often in incredibly creative ways. However, just saying SSL is "broken" isn't very useful or specific, as it involves a large ecosystem of software, cryptography, and organizations that have all experienced issues over the years.
What I mean by "broken" is that some of the assumptions of confidentiality and integrity in the popular HTTPS use case of SSL have been violated, sometimes more egregiously than others. Between faulty client-side libraries, weak server-side configs, vulnerable protocol constructions, cryptographic weaknesses, side-channel attacks, CA compromises, and more, there's an Internet full of fingers and many targets to point them at.
Here's a (maybe-not-so) brief rundown of some of the high-profile "breaks" of SSL in the past few years:
2008 - MD5 considered harmful - Researchers used 200 Playstation 3's in order to construct a chosen-prefix collision against the MD5-based RapidSSL CA, resulting in a certificate signed by RapidSSL but with the CA bit of the basic constraints field set to true. Applied math (and console gaming) at its finest.
2009 - Null-prefix attack - Moxie Marlinspike discovered that SSL implementations had taken a page from @SecureTips and royally screwed up their the C-based parsing and comparisons of the CN field in certificates. For example, a CA might issue
www.paypal.com\0.thoughtcrime.orgto Moxie, but your browser would consider that a valid cert for PayPal.
2009 - OCSP "tryLater" - After Moxie realized he could create fraudulent certs with NULL bytes, he went after the next logical target: the revocation mechanisms. Moxie was able to defeat OCSP by simply returning a 0x3 byte when MITM'ing, indicating a error code of
tryLater. In response, browsers said, "Welp, I've tried hard enough, let's just go ahead and validate this certificate". THANKS BROWSERS.
2011 - Comodo and DigiNotar breaches - Breaches at Comodo and DigiNotar resulted in a bunch of fraudulently-issued certificates, allowing (reportedly) Iranian attackers to MITM traffic to boring sites like
mail.google.com. An amateur hacker named ComodoHacker claimed responsibility for both. The attacks underscored the fragility and vulnerability of the CA ecosystem.
2011 - iOS Basic Constraints - Similar to the vulnerability Moxie found in Internet Explorer in 2002, researchers at Recurity and Trustwave found that iOS did not validate the basic constraints bits of a certificate, which means that an attacker can sign *.google.com with his CA-signed foobar.com certificate and your eyePhone will happily accept it.
2011 - BEAST - Thai Duong and Juliano Rizzo presented this fine research at Ekoparty, bringing into practice a largely-theoretical attack against CBC-based SSL ciphers known since 2004. Lots of math, but the key extension of the attack was leveraging new browser features like WebSockets and native plugins to obtain the required blockwise chosen-boundary conditions.
2012 - CRIME - The unstoppable BEASTs of SSL-breaking, Juliano and Thai, continued their rampage the next year by introducing the CRIME attack. With CRIME, an attacker who can influence partial plaintext of your browser's SSL requests and eavesdrop on the resulting ciphertext can extract information about the rest of the plaintext by observing the size of the compressed ciphertext. In other words, that guy next to you drinking the green tea latte at Starbucks just snatched your online banking session.
2013 - BREACH - Very similar to CRIME, but leveraging the HTTP-layer gzip/DEFLATE compression instead of TLS compression as the side-channel. Unlike CRIME, there is no generic protocol-level mitigation and applications must jump through a bunch of hacky hoops, or disable HTTP compression all-together.
2013 - Attacks on RC4 - I'm not a math major like the illustrious Dr. Charles Miller, and I'm no RC4 expert (although I did write the Linux kernel RC4 implementation while on spring break in Mexico...that's only slightly terrifying), so you'll have to read the paper for the dirty details. Never a good sign that the recommend countermeasure is to "stop using RC4 in TLS".
2013 - Lucky 13 - Man, the guys at Royal Holloway just won't give up. Using a similar attack scenario as BEAST/CRIME/BREACH, they discovered it was possible to decrypt CBC-mode TLS communications by exploiting a timing attack in the CBC decryption procedure to achieve padding oracle-like conditions.
2014 - Apple's "goto fail" - The infamous CVE-2014-1266 that affected iOS and OS X endpoints. Yes, the hilariously extraneous "goto fail" statement in Apple's SecureTransport library allowed active MITM attackers to snoop on SSL connections. The disclosure of the vuln via an iOS patch when no OS X patch was in sight was the icing on the cake.
2014 - Heartbleed - Does it get any worse than Heartbleed for SSL? A remotely- and trivially-exploitable infoleak that hands over the keys (literally) to the SSL kingdom. The long-term impact of Heartbleed will be tough to gauge due to the low detectability of attack (especially retroactively), but the entire Internet is busy re-keying as we speak.
The list above isn't meant to be exhaustive, but it covers most of the high-profile attacks that have affected popular SSL use cases. There are plenty of additional attacks on SSL (the renegotiation vulnerability, the Triple Handshake attack, servers using null/weak ciphers, client-side libraries and mobile apps not validating certs, etc) that didn't make the cut since my fingers will fall off typing them all out.
##Don't Trust SSL
So, wow, much SSL breakage.
It's easy to say "well, just don't trust SSL!" But what does that mean? How can one operate an application or service that can operate securely even when it's assumed that the integrity of SSL is violated? Let's take an example from Duo's two-factor service.
Our flagship authentication method is called Duo Push. If you haven't heard about it before, you better ask somebody. Or, better yet, you can read our previous blog post or see it in action in this quick video. Seriously, it's only 21 seconds:
Duo Push is vastly different than traditional OTP-based two-factor authentication. No hardware or software tokens, no passcodes to transcribe, no symmetric secrets laying around that get you RSA'ed.
Duo Push is an out-of-band authentication mechanism over a mutually-authenticated secure transport and is resilient against even the most sophisticated credential-stealing attacks. Login requests are signed with an asymmetric key pair, which provides a stronger identity assertion than passcodes and prevents "RSA-style" breaches. Cryptographically-signed transaction details are displayed to the user for verification, preventing even the most sophisticated man-in-the-browser (MITB) attacks. Authenticating with Duo Push is as easy as tapping a button on your phone. No phone calls to wait for or passcodes to type in.
In other words, it's both more secure and more usability, a rare combination in our world of crazy security controls.
So what's happening under the covers that makes it so we don't need to trust SSL? There's a private key embedded on the end user's mobile device that the Duo Mobile app uses to attest to the user's identity. So when you go to log in to your Juniper VPN, Outlook Web Access, Salesforce, or Tinder Enterprise Edition, and click the "Approve" button on your Duo Push notification, the Duo Mobile app produces a signature using the private key that the server can verify with your public key to approve your second factor of authentication.
Side note: This private key is handled opportunistically depending on device capabilities, so it often times can be generated in a hardware-backed credential store, which is pretty snazzy in my not-so-humble opinion.
The RSASSA-PKCS1-v1_5-SHA1 signature (yes, @tqbf and @matthew_d_green, RSASSA-PSS-SHA512 is supported and rolling out to mobile devices near you soon) is computed over the following plaintext elements:
The user's response to the Duo Push request: approved, denied, or reported fraud.
A random 256-bit identifier/nonce that binds the response to an particular transaction.
Some additional parameters of the response, including a unique identifier for the approving device.
The signed Duo Push response is transmitted to our service for verification over SSL/TLS. So, assuming that the integrity of the SSL/TLS is violated, what can the attacker achieve? Thankfully, not much since there are no passwords, keys, or other secrets contained in the message. Replay attacks are effectively thwarted due to the random nonce. The worst impact is a loss of confidentiality of the initial push request (eg. username, IP address, what they're logging in to), although we're working towards end-to-end confidentiality. But, the attacker cannot forge authentication responses, nor tamper with the request in any way that would violate the integrity of the authentication process.
You may recognize this distinction as transport- vs. message-level security. When you properly implement message-level security, the transport (SSL in this case) is no longer vital to maintain integrity and authenticity of communications.
Just one of the many ways we've designed our two-factor service with defense-in-depth in mind! Looking at the timeline of SSL breaks, it's pretty apparent that not trusting SSL whenever possible is not a bad idea.
Keep an eye out for more of our Heartbleed defense-in-depth series for the rest of the week!