Is the lame DUHK attack anything to go quackers about?
Here at IT Security Thing we were intrigued to see news of the Don’t Use Hard-coded Keys (DUHK) attack methodology. Not just because anything to do with cryptography gets us a little bit turned on, but also as it seems to be something of a lame DUHK as far as real world threats are concerned.
According to the researchers that uncovered the DUHK vulnerability it affects devices using an ANSI X9.31 random number generator along with a hard-coded seed key. They go on to say that it enables an attacker to recover secret keys from a vulnerable implementation, and then decrypt communications passing over VPN connections or encrypted web sessions.
This is all quite alarming, especially as the vulnerable implementations are said to have all been “historically compliant” with the Federal Information Processing Standards.
But that’s the bit that touched my cynical real world nerve; both “to have been” and “historically compliant” suggest past tense. My cynicism increased a tad when it turned out that the vulnerability was tested against FortiNet FortiGate devices running FortiOS 4.3.0 to 4.3.18. So maybe this is a lame duck after all, in threat likelihood terms?
I reached out to my contacts at FortiNet and they responded by issuing a statement which can be found in full here. The bit that is most relevant being: “Like many other devices at the time, FortiOS 4.3.x used the ANSI X9.31 pseudo-random number generator to decrypt TLS/IPSec traffic. However, it was superseded by CTR_DRBG (Counter-mode Deterministic Random Byte Generator), which was recommended in NIST SP800-90. The switch to CTR_DRBG was implemented in FortiOS 5.0, which was released in April of 2014, long before the weakness in the ANSI X9.31 RNG was discovered.”
This is, it seems, pretty old news then. What’s more, the real-world threat thing becomes even more remote when you consider the full set of requirements for a device to be vulnerable to the perhaps lame DUHK attack methodology:
1. It has to use the X9.31 random number generator
2. The seed key used by that generator has to be hard-coded into the device implementation
3. The output from that random number generator has to be used directly in order to generate the cryptographic keys
4. Some of the random number, either before or after those used to make the keys, must be transmitted without encryption.
I reached out to Duncan McAlynn, principal security engineer at Ivanti, who agreed that “while I wouldn’t state that this exploit proof of concept is a dead DUHK, it is certainly a lame DUHK one.” Duncan went on to say that “the conditional requirements for it are so exhaustive that even the few corporate or government agency environments with vulnerable devices are highly unlikely to find them exploited.” Indeed, the researchers have stated that their scans revealed that there are only about 23,000 devices with a publicly visible IPv4 address running a vulnerable version of FortiOS. “That is simply too small of a target for threat actors to fire at in today’s malware shooting gallery” Duncan concluded.
Graeme Park, a senior consultant at Mason Advisory, pointed out to me that the 23,000 device number “does not include private IP addresses, nor other implementations of X9.31 beyond FortiOS” which tempers the small target argument a little. “The fact that many of the vulnerable products were, as recently as 2015 listed in the FIPS approved catalogue,” Graeme continues, “means that not only is security assumed, but federal agencies will have implemented these products and public sector as a whole is usually slow to replace or patch systems.”
So maybe there is some real-world danger from the DUHK, no matter how daffy it might sound at first then? I got in touch with Dan Brown who wasn’t working on yet another Da Vinci Code novel; mainly as he’s a different Dan Brown, working as a security consultant for FarrPoint. “Right now there has been no sign of this vulnerability being exploited in the wild” Dan told me, adding “this attack would most likely be used for spying on an organisation and not as a vector to enter a private network.” So while there has been no sign of this attack being used so far “it’s very hard for the affected organisation to detect due to its passive nature.”
Trying hard not to sound like John Cleese in the Monty Python dead parrot sketch, it is an old vulnerability, in old products, but it has not yet ceased to be. So what should organisations be doing pro actively now, if anything?
“There are best practices that all businesses should follow with hard keys: such as regular key rotations, patching and normal upgrades away from legacy systems,” Jay Coley, senior director security services with Akamai, explained. “The real security risk with token-based VPNs is that too many companies have too many users punching through their firewalls to access the network,” Jay insists, “opening up vulnerabilities to bad actors. Businesses need to forget the traditional moats and castles approach to protecting their data and adopt a zero-trust mentality where data and applications are isolated from the network and secured.”