Juniper Networks announced late Friday it was removing the suspicious Dual_EC_DRBG random number generator from its ScreenOS operating system.
And while that’s heralded as a positive move considering Dual_EC’s dubious origins, there remain important and unanswered questions about Juniper’s decision to include what is considered to be a backdoored random number generator in its NetScreen VPNs, and why a number of strange coding and engineering decisions were made that could have facilitated the decryption of secure traffic.
The networking giant said it was not only removing Dual_EC, but also the ANSI X9.31 algorithm from ScreenOS starting with an upcoming release sometime in the first half of this year. The announcement comes just shy of a month after Juniper said it had found unauthorized code in ScreenOS that allowed for the decryption of NetScreen firewall traffic and a second issue that allowed for remote unauthorized access to NetScreen appliances via SSH or telnet.
Juniper said it brought in third-party help to investigate its code and determined that no other “unauthorized code” lives in either ScreenOS or Junos OS.
“The process examined Junos OS source code in ‘hot spots’ where one may expect to find code similar to the code found in ScreenOS,” Juniper said in its advisory on Friday. “The hot spots include VPN code, encryption code, and authentication code. We also inspected our build environments for any evidence of tampering or unauthorized access.”
In the meantime, at last week’s Real World Crypto conference at Stanford University, a team of crypto experts presented a number of revelations, including the news that Juniper’s use of Dual_EC dates to 2009, perhaps 2008, at least a year after Dan Shumow and Neils Ferguson’s landmark presentation at the CRYPTO conference that first cast suspicion on Dual_EC being backdoored by the NSA. Shumow’s and Ferguson’s work showed that not only was Dual_EC slow compared to other pseudo random number generators, but it also contained a bias. The bias means that the random numbers generated by the algorithm aren’t so random and likely have a relationship with a second set of numbers that enable whomever knows that second set of numbers to predict the output of the PRNG after collecting a minimal amount of output (32 bytes).
Stephen Checkoway, assistant professor of computer science at the University of Illinois at Chicago, told Threatpost that he and his colleagues on this investigation looked at dozens of versions of NetScreen and learned that ANSI X9.31 was used exclusively until ScreenOS 6.2 when Juniper added Dual_EC. It also changed the size of the nonce used with ANSI X9.31 from 20 bytes to 32 bytes for Dual_EC, giving an attacker the necessary output to predict the PRNG output.
“And at the same time, Juniper introduced what was just a bizarre bug that caused the ANSI generator to never be used and instead just use the output of Dual_EC. They made all of these changes in the same version update.”
Checkoway said that Juniper’s introduction of the bug, which was discovered by researcher Willem Pinckaers, broke the way that the code had worked in ScreenOS 6.1 and earlier.
“It’s very bizarre. I’ve never seen anything like that before where gone from something that was working and written in a standard manner to something as strange as this,” he said. It’s that bug that enabled another attacker to replace the Dual_EC constant—thought to belong to the NSA—with their own constant.
“The very presence of Dual_EC enabled a third party to simply change a constant and make it so they were able to decrypt VPN traffic,” Checkoway said, adding that Juniper’s patch reverted the constant back from the attacker-supplied one, to a Juniper-supplied constant. “I take it that Juniper thought the previous code there was intended functionality.”
While Juniper’s decision to use Dual_EC enabled this second attack, Checkoway said there’s no justifiable security or engineering reason to have done so in the first place.
“Basically, whoever changed the code needed to change just a small portion of Juniper code, a tiny fraction of their code. Whereas had Juniper not used Dual_EC, they would have had to do something much bigger,” Checkoway said. “Juniper’s use of this bad random number generator really enabled the subsequent attack.”
Juniper, in the meantime, quickly patched the two vulnerabilities by removing the so-called “unauthorized code;” Juniper representative Danielle Hamel refused to comment further and pointed Threatpost to the company’s various blog posts explaining the situation.
The scenario harkens back to the documents leaked by NSA whistleblower Edward Snowden, in particular the NSA’s Project BULLRUN, which explains the NSA’s subversion of Dual_EC and eventually the revelation that RSA Security was allegedly paid $10 million by the NSA to use the algorithm in its products.
“One of the interesting things about using Dual_EC as a backdoor mechanism versus the unauthorized access SSH backdoor, is that with Dual_EC, it’s just a series of what looks like mistakes or bad engineering choices that coincidentally leads to their software being vulnerable,” Checkoway said. “There are so many coincidences: the introduction of Dual_EC, the bug, the change in the nonce from 20 bytes to 32, which is really the ideal size for running this attack.”
