There have been some news items floating around the Internet discussing a weakness in the ANSI X9.31 random number generator (RNG) known as DUHK (for Don’t Use Hard-coded Keys) that had affected older FortiGate devices.
Like many other devices at the time, FortiOS 4.3.x used the ANSI X9.31 pseudorandom 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.
In addition, an update was issued more than a year ago when the flaw was first announced to Fortinet, a PSIRT Advisory was issued advising all customers with devices that can’t run the newer versions of FortiOS to upgrade to 4.3.19, and for everyone else to migrate to FortiOS 5.0 and above. It is important to note that the 4.3.x FortiOS series that this flaw affects had already been designated End-of-Support when this flaw was discovered, and unlike other vendors whose EOS products were similarly affected, Fortinet went ahead and released a fix with version 4.3.19 in order to protect organizations running older hardware.
I’m not sure why this obscure flaw made the news. Even the researchers who have been talking about the DUHK attack over the past couple of days admit that it relies on a host of implementation errors occurring on aging security and VPN gateway appliances in order to trigger a vulnerability in a pseudorandom number generator that was designed in 1985. Maybe it was a slow news day.
Security tools and techniques are continually evolving, requiring vendors to issue patches and updates and for IT teams to implement patch management processes to ensure that devices running on their networks are protected.