All due respect to the team behind the Pwnies, some of whom I know and like a great deal, but when it comes to the descriptions on this year's new crypto awards track... it's clear they have day jobs. We're just going to go ahead and fix that for them.
Note that I had nothing to do with this years selections, and didn't nominate anything.
Credit: Christina Garman, Matthew Green, Gabriel Kaptchuk, Ian Miers, Michael Rushana
Your intuition is that this is a contender just for impact. They have a decryption attack against one of the most widely-used secure messaging protocols in the world. Done and done, on to the next one. Right?
Not so fast. iMessage is the least interesting thing about this attack. Here, let me spoil it for you: iMessage doesn't properly authenticate ciphertexts. You can flip bits in encrypted iMessage messages and get responses to them. You don't need to know much crypto to know why that's a problem.
But here's the catch: iMessage messages are DEFLATE compressed.
The exploit for this flaw could best be described as "acrobatic". You've got to flip bits until you find a message that Huffman-decodes properly. But that's not good enough: a random valid Huffman symbol will break the DEFLATE CRC, so you've got to XOR-compensate the CRC. And a known-valid symbol is only useful if you've got the DEFLATE Huffman table. Spoiler: you don't. You have to infer it based on an HTTP side channel Apple managed to leave in iMessage.
This attack is hard to pull off and Apple fixed it already anyways. So what's the big deal? Only that this attack will be a template for how to exploit other broken cryptosystems in the future. Also: a great read.
Credit: Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky, Philipp Jovanovic
It's one thing to know that when you're encrypting with constructions that need a random nonce, you can't ever re-use a nonce. Everyone knows that, right? Everyone, that is, except all the people who implement TLS stacks.
It's another thing to know how to exploit crypto constructions with repeated nonces.
Sometimes it's easy. Repeat a nonce for AES-CTR in AES-CTR-HMAC and you can decrypt messages as straightforwardly as you can decrypt toy XOR encryption.
Other times it's not so easy. Accidentally repeat 8 bits of an 256-bit ECDSA nonce, for instance by leaving its 32nd byte zero in an off-by-one bug, and you've got a vulnerability that requires both lattice reductions and Fourier transforms to solve. Which is a good thing, if you find that sort of thing "fun".
Attacks on GCM are on the "fun" end of the spectrum. Binary polynomial fun. Linear algebra fun. Factoring fun. There's something in here for everyone to love. Except the people who write TLS stacks.
Real world impact? They did the TLS equivalent of popping CALC.EXE: they exploited GCM, the current state of the art in authenticated encryption, to inject XSS attacks into bank websites. Even though Antoine Joux, one of the world's most famous cryptographers, forbad them from doing that. Take that, cryptographers! This attack is Forbidden! And they did it anyways!
Credit: BlueCoat and Symantec
Symantec signed a CA=YES certificate for BlueCoat. Yes, that BlueCoat. Then they bought BlueCoat, creating a singularity of Internet trust drama.
You vote for this one if you're like, fuck crypto, this whole thing is fucked, nothing matters, burn the Pwnies down. I won't blame you.
Credit: Gunnar Alendal and Christian Kison and modg
You didn't actually think self-encrypting hard drives worked, did you? You think the world's great cryptographers go work for hard disk companies working on checkbox features? Obviously, they don't. Obviously, these things don't work.
But don't let that keep you from reading a pretty excellent paper on reversing hardware and exploiting comical encryption failures.
See something that looks like an AES key?
It was probably spooled directly off an LFSR.
Unless it wasn't. If it wasn't, it was probably encrypted by another AES key hardcoded into the firmware of the device, free from the prying eyes of anyone other than someone who can handle file formats.
It's not encrypted with a hardcoded key? You can't work it out by breaking an LFSR? Oh, don't worry: that just means it's the value of GetTickCount repeated 4 times.
It gets worse, but you should read the paper to see how.
Credit: Antonio Sanso
What doesn't go wrong with OpenSSL? When the trickster gods of software security see too much time elapse since the last exploitable memory corruption vulnerability in OpenSSL, they summon demons from the underworld to add support for new TLS options just so new memory corruption flaws can be introduced. ia! ia! OpenSSL! Leave no padding un-oracled! No Bleichen un-bachered! No buffer underflown, no carry un-un-propagated!
Even when OpenSSL gets things right, it gets things wrong, as Antonio Sanso discovered.
You and me, we look at RFC 5114 and we say to ourselves, "why are we reading RFC 5114?" and we go back to perfecting our Lucio wall-riding on Numbani in Overwatch.
Sanso looks at RFC 5114 and he thinks to himself, "why are these DH generator values so complicated compared to normal DH generator values?" And the answer, it turns out, is that they're stupid and broken!
Now, you hear "why is this DH generator value so complicated?" and you think to yourself "I'm not sure whether my life would get any better at all if I knew what a DH generator value OH FUCK fucking Junkrat just did that stupid fucking tire thing on me now what were we talking about again?"
But it turns out your life does get a little better if you know how DH parameters work and you read RFC 5114 and you take the time to implement one of the all-time classic crypto attacks and people in the world actually use OpenSSL.
Because what you can do with the broken standard DH group is, you can make lots of TLS connections to an OpenSSL server and each time, feed it a bogus DH public key, one the generator couldn't have generated, one that can only generate a small subset of all possible session keys. So small a subset, you can brute force it. And you can do that over and over again, and take all those broken session keys, and feed them to the Chinese Remainder Theorem, and GOD DAMMIT FUCKING REAPER --- sorry, I mean you can remotely recover the OpenSSL server's private DH key.
But only if OpenSSL's DH is in its default configuration. The trickster gods didn't want to make it too easy.
Credit: Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube, Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni, Emilia Käsper, Shaanan Cohney, Susanne Engels, Christof Paar, and Yuval Shavitt
This bug was nominated for "Best Branding". I know "SSLv2 Crypto attack" does have a nice ring to it (its technical name is DROWN). But I suspect the real reason it's not nominated for crypto is that if it was in there, it'd be the category killer.
DROWN is the Mark Dowd Flash Exploit of crypto attacks. It is one of the all-time great papers not just in crypto exploitation, but in exploitation period.
Start here: almost everyone working in software security knows that if you encrypt a message and then don't authenticate the resulting ciphertext, you've got problems. If you encrypt with a block cipher in CBC mode, which is how everyone encrypted until like 5 minutes ago, you have a problem with a name: a padding oracle.
Among all the viable crypto attacks you can pull off with a laptop to get a game-over serverside flaw with, there are two that you can count on a strong pentester to actually know about: hash length extension and the CBC padding oracle.
What a lot of strong pentesters don't know is that the padding oracle attack that breaks AES in CBC mode also breaks RSA. The attack is trickier, but not that much trickier, and when you pull it off you join a secret society of people who get to make dumb jokes based on the name "Bleichenbacher". We have a Slack!
So, DROWN exploits the Bleichenbacher RSA padding oracle against TLS. Easy peasy, lemon squeezy, right?
Wrong. There is neither pease nor squeeze to be found anywhere in DROWN.
To start with: the Bleichenbacher oracle doesn't work against SSL 3.0 or TLS. And SSL 3.0 or TLS is what everyone uses. But DROWN still works. Why?
Because people still have SSL 2.0 servers stood up on the Internet. They don't use them. They're not even aware that they're there. But they are, and because people are lazy, they have the same certificates and keys installed as the TLS servers do. DROWN takes advantage of that: it's a cross-protocol attack.
In the DROWN attack, attackers start a handshake with a TLS server, and then quickly shuttle the victim's TLS messages to an SSL 2 server. SSL 2 is vulnerability to RSA oracles, and can be used as a cross-protocol oracle.
But wait: there's more. SSL 2.0 is not the same protocol as TLS. It can't do anything with TLS ciphertexts. But there's an extension to the RSA padding oracle attack that takes advantage of RSA malleability. The same malleability that allows attackers to do the number-theoretic equivalent of flipping bits in a CBC ciphertext also allows attackers to tune their corrupted TLS RSA ciphertexts.
The DROWN attack takes advantage of an optimization Bardou used for fast padding oracle attacks against embedded hardware to adapt TLS messages to SSL 2.0, and then use SSL 2.0's vulnerability to padding oracles to decrypt them.
It's among the coolest attack papers I've ever read. Let's pretend, just for this one Pwnies event, that it had better branding than Badlock.
If that's the prize, we at least deserve a teaser. Give us one dumb joke.