Network Security

Stack Ranking SSL Vulnerabilities: DUHK and ROCA

Even with catchy branding and cute mascot and a theme song, these two SSL/TLS vulnerabilities nearly went unnoticed last week. The WPA2 Key Reinstallation Attack (KRACK) overshadowed them both, vacuuming up the tech media attention.

<p class="MsoTitle"><span><span>Even with catchy branding and cute mascot and a <a href="https://www.youtube.com/watch?v=ZKcZ2BHuVkA">theme song</a>, these two SSL/TLS vulnerabilities nearly went unnoticed last week. The WPA2 Key Reinstallation Attack (KRACK) overshadowed them both, vacuuming up the tech media attention.</span></span></p>

Even with catchy branding and cute mascot and a theme song, these two SSL/TLS vulnerabilities nearly went unnoticed last week. The WPA2 Key Reinstallation Attack (KRACK) overshadowed them both, vacuuming up the tech media attention.

DUHK and ROCA are both implementation-specific vulnerabilities concerning one of my favorite topics, random number generators.

The “Don’t Use Hardcoded Keys” (DUHK) vulnerability is sponsored by that amazing team of researchers Nadia Heninger and Matthew Green, though they are honest and explicitly say that their graduate student, Shaanan Cohney, did all the grunt work. Heninger has been behind a ton of interesting crypto attacks, including the DROWN attack, and my personal favorite, the cracking of 1% of SSL keys due to bad random numbers, Mining your Ps and Qs. 

General purpose computers have a difficult time generating random numbers without a true random source. Many computers use a pseudo-random number generator (PRNG); typically, a deterministic algorithm that attempts to expand a small amount of random data into larger amount. But that process was known to be fraught with error even before the invention of computers themselves.

Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.” – John Von Neumann, 1951.

The Green/Heninger/Cohney team didn’t invent anything new with DUHK; the ANSI X.931 PRNG used in some ancient versions of FortiOS VPNs and firewalls has been known to be garbage for years because of its use of a static key. Fortinet patched the problem over three years ago, and if someone is still running software that old, they probably have easier vulnerabilities to target. 

But keeping true to my original premise of ranking SSL-related vulnerabilities against each other, let me compute a score for DUHK. A PRNG compromise may not yield the system’s private key to an attacker, but it would let them passively crack sessions and decrypt network traffic, which could contain sensitive data like admin credentials.

DUHK stack rank score = 3

Advertisement. Scroll to continue reading.

– Impact = session key derivation = 3

– Exploitability = (low exposure) = 1

Meanwhile, in the non-academic world, many are rolling their eyes at another branded SSL vulnerability. Check out the comments on Green’s excellent write-up of DUHK. Even Green admits that DUHK is a “fairly absurd” vulnerability. His conclusion that government crypto specifications are worthless, based on a few examples, is a tad too dismissive. Standards prevent vendors from using ancient or insecure ciphers like RC2, or designing their own crypto algorithms (which is such a bad idea that it is called “Schneier’s Law”). The answer to a bad or outdated standard is to design a new one, which is what happened with ANSI X9.31 (it was deprecated by NIST in 2011).

But look at it this way; graduate student Cohney got a whole vulnerability and his name in the papers, and good for him. I’d have done the same thing for him if I were Green and Heninger. But for the rest of the world, if you haven’t patched your Fortinet systems since the summer of 2014, man, you had better take another look at your life decisions.

Everything Old Is New Again

The Return of Coppersmith’s Attack (ROCA) is also an ancient problem. And, like DUHK, ROCA is specific to a particular implementation—in this case, Infineon chipsets that are often used in smart cards and embedded, high-security (trusted computing) environments. The authors of ROCA claim these chipsets are found in FIPS 140-2 and CC EAL 5+ certified hardware, both of which are solutions you pay tens of thousands of dollars for to keep your private keys, well, private.

The majority of keys vulnerable to ROCA are associated with smartcards (which are actually not smart at all, having very little in the way of computation power and thus need tricks like “fast prime” for generating keys). But researchers have found a handful of vulnerable TLS and Github keys.

With ROCA, an attacker could factor a 2048-bit private key with $20,000 to $40,000 in CPU time. Factoring a 1024-bit key is only about $50 (peanuts)! ECC keys are probably not vulnerable to ROCA, though DH keys might be. What’s really interesting is that you can easily tell by examining the public key whether or not the private one is crackable.

The actual paper for ROCA will be released later this week at the ACM Conference on Computer and Communications Security. But if we assume the early details are correct, when we plug ROCA into my stack-rank table for SSL vulnerabilities, it gets a score of 20, much higher than DUHK.

ROCA stack rank score = 20

– Impact = recover private key = 10

– Exploitability = non-trivial = 2 

Keep in mind that both DUHK and ROCA are limited to a handful of SSL/TLS sites, which is what we’re evaluating these vulnerabilities against.

If you are an administrator for a medium to large enterprise, there is little chance that ROCA is going to be a fire drill for you. Sure, the larger your organization, the higher the chance that somewher
e
you have a device vulnerable to DUHK or ROCA. And very likely your biggest headache is that of inventory. And if you haven’t solved the inventory problem, at least you’re in very common company as it is becoming the hardest problem to solve. 

For crypto implementors, don’t rely only on deterministic inputs like timestamps and static keys. Seed your PRNG with a small bit of real random numbers instead. You can get a Quantum RNG for practically nothing these days. Here’s one that someone sent me; it’s the size of a typical USB.

Disclosure: I have no ties to that particular vendor, and am not endorsing it, I just thought it was cool that they sent me a sample. QRNG as an input into a PRNG would be much more secure than timestamps. Intel’s Ivy Bridge has been leveraging quantum effects in its onboard RNG, using it since 2011. 

Even though they’re both old and vendor-specific, I’m glad to be writing about DUHK and ROCA, because anything that sheds light on the difficulty of generating real random numbers is a good thing. More people should be trying to solve the RNG problem, because it is so fundamental to cryptography, as DUHK and ROCA both show. 

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version