This article is more than 1 year old
Holy DUHK! Boffins name bug that could crack crypto wide open
Hard-coded keys and pseudorandom numbers flay Fortinet first, other vendors probably also in play
Crypto researchers from the University of Pennsylvania, working with Johns Hopkins cryptographer Matthew Green, have discovered a serious security blunder and branded it DUHK, which stands for Don't Use Hardcoded Keys.
The vulnerability – described in depth at this “silly logo” website here – lies within an ancient pseudo-random number generator (PRNG) design, deprecated in many products, but still present in plenty including about 25,000 devices made by Fortinet.
The generator in question is ANSI X9.31, which lingers from the 1990s. Until 2016 it was approved by the US government's FIPS Cryptographic Module Program, and uses a fixed key as one of the inputs to generate pseudorandom numbers.
This means encryption built on this number generator – such as encrypted VPN links – can be decrypted by network eavesdroppers.
For several years, continuing to today, Fortinet VPNs effectively sent their encryption keys in plaintext over the wire. By default.
— Matthew Green (@matthew_d_green) October 27, 2017
Green explained:
If an attacker were to obtain K (one of the pseudorandom number generator's (PRG's) input values somehow, and then was able to learn only a single 16-byte raw output block (Ri) from a working PRG, she could do the following: (1) guess the timestamp T, (2) work backwards (decrypting using K) in order to recover the corresponding state value V, and now (3) run the generator forwards or backwards (with guesses for T) to obtain every previous and subsequent output of the generator.
Thus, if an application uses the ANSI generator to produce something like a random nonce (something that is typically sent in a protocol in cleartext), and also uses the generator to produce secret keys, this means an attacker could potentially recover those secret keys and completely break the protocol.
Patches are available to address the vulnerability in Fortinet's products, and you know what to do. Thew weakness in the kit was uncovered by combing US government certifications to identify possibly vulnerable vendors, and poring over documentation to work out how the PRNG was configured.
Other vendors identified as formerly supporting X9.31 included:
- Those who have offered updates: BeCrypt, Cisco (Aironet products), MRV Communications' LX-4000T/LX-8020S, Neopost Technologies, and Vocera Communications;
- The group was unable to confirm fixes for products from Deltacrypt Technologies, Neoscale Systems, Renesas Technology, TechGuard Security, Tendyron, or ViaSat.
While the paper – and many headlines – draw attention to Fortinet, there's a good reason for that: of the twelve devices the researchers identified as potentially vulnerable, they could only access Fortinet's firmware for analysis.
This raises the possibility that other unpatched systems are still out there, which use crypto modules that implement the dodgy X9.31 design.
A handy example is processor vendor Xilinx. The company licenses Helion Technology crypto modules for use in its devices; if a downstream OEM designed a product with a fixed K, Green confirmed to The Register the product would be vulnerable.
As he writes in his post: “It’s almost certain that this small Fortinet vulnerability is just the tip of the iceberg.”
Returning to the Fortinet example: the group was able to get through what ranks as a Holy Grail of decryption, successfully recovering data sent over VPN sessions.
The co-authors on the paper are Shaanan Cohney and Nadia Heninger of the University of Pennsylvania. ®
Biting the hand that feeds IT
