A vulnerability has been discovered in some security devices that allow hackers to recover secret keys from Fortinet devices.
The flaw affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key, according to researchers at John Hopkins University.
In a blog post, researchers Nadia Heninger, Shaanan Cohney and Matthew Green said the the attack, called DUHK (Don't Use Hard-coded Keys), allows attackers to recover secret encryption keys from vulnerable implementations and decrypt and read communications passing over VPN connections or encrypted web sessions. They added the encrypted data could include sensitive business data, login credentials, credit card data and other confidential content.
“The affected implementations were all historically compliant with FIPS, the Federal Information Processing Standards,” said researchers. They added that traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic. Other key recovery attacks on different protocols may also be possible. Over 25,000 Fortinet devices are vulnerable to the DUHK attack.
“We also found eleven other historically FIPS-certified implementations that document hard-coded X9.31 RNG seed keys in their products,” said researchers.
According to a research paper, a device is vulnerable to DUHK if It uses the X9.31 random number generator and the seed key used by the generator is hard-coded into the implementation and the output from the random number generator is directly used to generate cryptographic keys plus at least some of the random numbers before or after those used to make the keys are transmitted unencrypted. This is typically the case for SSL/TLS and IPsec.
They said that the ANSI X9.31 PRNG is a pseudorandom number generator algorithm design that was included in various forms on cryptographic standards and listed as an approved RNG for FIPS certification for decades.
“This PRNG has a vulnerability that was described by Kelsey, Schneier and Hall as early as 1998. The RNG uses block cipher encryption with a "seed key" to update a state value from a timestamp. When this "seed key" is known to an attacker, she can recover all previous and future outputs of the generator from 16 bytes of output and a guess for the timestamp,” said researchers.
The general DUHK attack is a state recovery attack against implementations of the X9.31 RNG. It allows an attacker who knows the AES or DES key used by the implementation to recover the secret internal state of the random number generator after observing some output, they added.
Researchers warned developers of cryptographic software should stop using the X9.31 generator. It was removed from the list of FIPS-approved random number generation algorithms in January 2016. “If you must use a block cipher-based RNG, don't use a hard-coded key, and regenerate the key frequently,” they said.
End users of cryptography should regularly apply software updates. “It's good practice and will protect you against flaws that are of greater risk to you than this one.” They said.
Adam Brown, manager for security solutions at Synopsys, told SC Media UK that organisations need to be aware of what is in their applications and devices, “a simple scan of firmwares or apps will reveal known vulnerabilities inside of them, as DUHK manifests in CVE's scanners can look for it, CVE's already exists for certain implementations with the DUHK flaw.”
“Vendors should review their codebases for use of hard coded ANSI X9.31 seed keys. The X9.31 RNG was removed from FIPS 140-2 in January 2016,” he added.
Liviu Arsene, senior e-threat analyst at Bitdefender, told SC Media UK that the most common way of exploiting hard-coded keys is to eavesdrop on traffic, hence man-in-the-middle attacks. “Attackers would be able to impersonate one of the two parties that think they're communicating privately, and trick users into talking to the attacker instead of a legitimate server. This could lead to threat actors extracting passwords, usernames, and other authentication tokens.”
Tony Rowan, chief security consultant at SentinelOne, told SC Media UK that hard coded credentials, master keys, seed values and other encryption related data do appear in products from time to time. ”I think that the security related products should all have to go through security audits where things like his would be uncovered before they became an issue. Security assurance of designs and code should be the norm. Testing is not enough.”