It's been a month since Juniper admitted that its firewalls had back-doors in them, possibly inserted by (or to aid) US intelligence agencies. In the month since, Juniper has failed to comprehensively seal those doors, and more suspicious information has come to light.
U Illinois researcher Stephen Checkoway has revealed that Juniper's backdoor was only possible because the company added a known-insecure random number generator, Dual_EC, years after the company had started using a more-secure alternative, ANSI X9.31, deliberately introducing a vulnerability into its product.
More suspicious is the way in which Dual_EC was implemented in Juniper products, with one important value (the length of the "nonce") set to precisely the optimal length for easy cracking. The 32-byte nonce is unheard of in practice — the standard is the more-secure 20 bytes — and appears prominently in a paper that explained how a 32-byte nonce would allow attackers to decrypt messages in "seconds."
Dual_EC is slower and less efficient than ANSI X9.31, but it is one of the valid options for companies seeking to have their products certified for use in the US government under the Federal Information Processing Standards, but Juniper's products were certified under FIPS because they used ANSI X9.31, not Dual_EC (the company's use of Dual_EC is not mentioned in their FIPS certification).
As if this wasn't bad enough, Juniper made a "catastrophic" programming error in its Dual_EC implementation, which was exploited by the backdoor's author.
Juniper claims to have removed the backdoors from its products, but independent analysis reveals that they are still present, and that the "catastrophic" bug in its Dual_EC implementation hasn't been fixed. The company won't comment on this, nor on why it wouldn't simply remove the known-insecure, slow, computation-hungry, suspect Dual_EC code altogether.
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.
New Discovery Around Juniper Backdoor Raises More Questions About the Company [Kim Zetter/Wired]
(Images: Juniper Networks, Fairy door at Red Shoes Ann Arbor Michigan close-up, Dwight Burdette, CC-BY)
