When tech giant Juniper Networks made the startling announcement last month that it had uncovered two mysterious backdoors embedded in software running on some of its firewalls, certain people in the security community praised the company for being honest about its discovery. Rather than silently removing the backdoors in a routine software patch sent to customers, Juniper said it was distributing the patch to eliminate "unauthorized code" that someone had placed in the source code of its software. This malicious code was particularly concerning because one of the backdoors, which had gone undetected in the software since 2012, could be exploited for the purposes of decrypting protected data passing through the VPN, or virtual private network, in Juniper NetScreen firewalls.
But since that revelation, Juniper---whose customers include AT&T, Verizon, NATO and the US government---has refused to answer any questions about the backdoor, leaving everyone in the dark about a number of things. Most importantly, Juniper hasn't explained why it included an encryption algorithm in its NetScreen software that made the unauthorized party's backdoor possible. The algorithm in question is a pseudo-random number generator known as Dual_EC, which the security community had long warned was insecure and could be exploited for use as a backdoor. Whoever created the backdoor in Juniper's software did exactly this, hijacking the insecure Dual_EC algorithm to make their secret portal work.
Now new information uncovered by a researcher in Chicago makes Juniper's decision to use this algorithm even more questionable.
Juniper insisted publicly in 2013 that its use of Dual_EC was fine because its software didn't rely on the insecure algorithm alone---instead it also used a second, more secure pseudo-random number generator known as ANSI X9.31 that essentially cancelled out any problems with the first one. That latter part turned out not to be true, however, and the very fact that Dual_EC was in the software allowed the intruders to exploit it for their backdoor. Juniper has never provided a timeline of when it inserted the two algorithms into its software, but many assumed that it had either implemented them at the same time so that its software never relied solely on the insecure Dual_EC, or it had added the ANSI algorithm to the software after already using Dual_EC for a while and learning that Dual_EC was not secure.
But Stephen Checkoway, who teaches computer science at the University of Illinois at Chicago, has found that Juniper actually added the insecure algorithm to its software long after the more secure ANSI algorithm was already in it, raising questions about why the company would have knowingly undermined an already secure system.
Checkoway worked with a number of other researchers to examine 48 versions of the NetScreen firmware. He looked for the presence of Dual_EC in all of them and found that until version 6.2.0, Juniper had been using only the ANSI X9.31 algorithm. The company only added Dual_EC with the 6.2.0 version.
It's unclear exactly when Juniper first released 6.2.0. The company's website gives a "file date" for the first release of the firmware as October 27, 2008. But the release notes for the firmware have a March 2009 date. Either way, both dates were long after the security community had become aware of the security problems with Dual_EC, which were revealed at a cryptography conference in August 2007 and which many believe the NSA introduced into the algorithm for its own backdoor---vulnerabilities that Juniper's unknown attackers then hijacked and exploited to create their own backdoor. (For background information on the problems in Dual_EC, see this story from 2013. To understand how the attackers exploited the vulnerabilities in Dual_EC to make the backdoor in Juniper's software work, see our comprehensive story about it from December.)
What's more, Checkoway discovered that the company made an additional change to its software when it added Dual_EC, a change that made it even easier for the person who later installed the backdoor to decrypt Juniper's VPN traffic. This change involved altering the size or length of the so-called nonce (the random number string generated by the algorithm that the encryption scheme uses to help encrypt data). Juniper changed the size of the nonce from 20 bytes---the size it had been using for the ANSI algorithm---to 32 bytes.
The change in nonce size is significant, Checkoway says, because in order to attack an encryption scheme that uses Dual_EC, an attacker needs to see enough raw output from the generator to crack it. The increase to 32 bytes of output reduced the amount of calculation and time an attacker would need to undermine the encryption scheme and decrypt data. That new nonce, 32 bytes, is the precise size the security community had specified in 2007 would be the ideal minimal output an attacker would need to undermine Dual_EC.
"The more output you see [from the generator], the better [it is to crack the encryption]," Checkoway says. "Anything you see over 30 bytes is very helpful. Anything you see less than 30 bytes makes the attack exponentially harder. So seeing 20 bytes makes the attack basically infeasible. Seeing 28 bytes makes it doable, but it takes an amount of time, maybe hours. Seeing 32 bytes makes it take fractions of a second."
Juniper could have chosen a nonce size anywhere between 8 bytes and 256 bytes, and Checkoway notes that previous research has shown that the most common value used by developers is 20 bytes. The use of 32 bytes, therefore, is curious. "Twenty bytes, as far as I know, is just fine [for security]. And 32 bytes would be just fine as well---if that random number generator didn't have a backdoor," he says.
Juniper's decision to increase the nonce to 32 bytes is also perplexing because Dual_EC, by nature, produces just 30 bytes of output at a time, according to Checkoway. To obtain enough output for the 32-byte nonce Juniper wanted for its encryption scheme, it had the Dual_EC generate output twice to produce 60 bytes. Checkoway says it then used only 2 bytes from that second generation and discarded the rest.
Checkoway says that given the known security problems with Dual_EC, it made no sense for Juniper to add it to the NetScreen software, particularly since it was already using the more secure ANSI X9.31 algorithm. It also made no sense because Dual_EC has another problem---it's known to be much slower than other algorithms. And because the NetScreen VPN software keeps the Dual_EC generator busy by calling on it repeatedly to produce random output, he says this likely would have caused a performance degradation for customers. The security issues aside, "this is not a particularly fantastic number generator even on its own terms," he says.
All of the changes Juniper made to its software in 2008 created an ideal environment for a backdoor, Checkoway says.
"The key point here is that if any one of the four listed changes in [firmware version] 6.2.0r1 had not happened, then the VPN traffic could not be passively decrypted...," says Checkoway. "If this backdoor was not intentional, then, in my opinion, it's an amazing coincidence."
So why did Juniper use Dual_EC and change the nonce to 32 bytes instead of the 30 the algorithm normally produced in a single output? These are enduring questions that Juniper has avoided answering since it first revealed the presence of the backdoor. The company refused to even entertain inquiries from WIRED for this story. "We have nothing further to share at this time but I will follow up with you when we do," spokeswoman Danielle Hamel wrote in an email, without even asking what the questions were.
Some people in the security community have suggested that one possible reason Juniper may have added Dual_EC to its software was to get its firewalls certified for government use. In 2006, the National Institute of Standards and Technology approved Dual_EC for use in encrypting government data under FIPS (the Federal Information Processing Standards), a standard that technology vendors must meet if they want to sell their products to government agencies and government contractors. In fact, Juniper's NetScreen software did get FIPS certified, but according to a list on NIST's web site, version 6.2.0 of its ScreenOS firmware was certified for its use of the ANSI X9.31 algorithm, not for Dual_EC. There's no mention of Dual_EC on the list at all, in relation to ScreenOS, the name of the firmware running on Juniper's NetScreen firewalls.
All of this leaves the security community and the public still baffled about Juniper's choices.
In 2013, following the release of NSA documents by Edward Snowden, questions about the security of Dual_EC were reignited, six years after they had first been raised at that cryptography conference in 2007. In response to the renewed concerns about Dual_EC, Juniper posted a little-noticed message to its web site in September 2013 revealing for the first time that the software on its NetScreen firewalls uses Dual_EC. But Juniper wrote that it had designed its encryption scheme to use Dual_EC in a secure way so that the algorithm's vulnerabilities didn't matter. It did this by replacing a so-called constant---or static number---that is used with the generator and is part of what made it insecure. And it also designed its encryption scheme so that it didn't rely solely on output from Dual_EC but instead relied on output from the ANSI X9.31 generator. Essentially, it would take output generated by the Dual_EC and run it through the ANSI generator and use only the final output from the more secure ANSI generator, theoretically canceling out the vulnerabilities that were inherent in the Dual_EC output.
But a researcher discovered last month that Juniper made a grave error in how it implemented this. Willem Pinckaers, an independent security researcher in California, found a bug in Juniper's software that actually caused it to ignore the ANSI algorithm altogether and only use that initial raw output from Dual_EC. Researchers have called it a "catastrophic failure" for Juniper and big win for the attackers who inserted the backdoor in Juniper's software. It was this failure on Juniper's part that allowed the attackers' backdoor to work.
Ironically, at the time that Juniper was making those assertions in 2013 about the security of its software, the attackers' backdoor had already been in it, undetected, for a year.
Today, a month after Juniper revealed the existence of the backdoor, it has still not fixed the catastrophic bug that made it possible. The company issued a patch last month that supposedly solved the security problem with Dual_EC by eliminating the unauthorized code the attackers had placed in the software to create their Dual_EC backdoor. But Juniper did not remove Dual_EC altogether, which is what Checkoway and other security experts say it should have done. Nor did it correct the implementation bug that causes its encryption scheme to ignore the ANSI generator and rely soley on output from Dual_EC.
As long as Dual_EC remains in Juniper's software, the system that corporate and government customers are using to secure their VPN data is not secure. If an attacker can get access to Juniper's source code again and introduce malicious code for another Dual_EC backdoor, the situation will be back to where it began.
Update 1.8.16 8:30 pm PST: Juniper announced late Friday night that it plans to remove both the problematic Dual_EC algorithm as well as the ANSI algorithm from its NetScreen code. "We will replace Dual_EC and ANSI X9.31 in ScreenOS 6.3 with the same random number generation technology currently employed across our broad portfolio of Junos OS products," the company wrote in a note posted to its web site. "We intend to make these changes in a subsequent ScreenOS software release, which will be made available in the first half of 2016."