New Discovery Around Juniper Backdoor Raises More Questions About the Company

13

New Discovery Around Juniper Backdoor Raises More Questions About the Company ☶ networking security wired.com
via noelle 2 years ago | cached | 2 comments

2

Story So Far:

Juniper recently released a patch to remove “unauthorized code” that would make decrypting VPN traffic from one of their firewalls extremely simple. The JunOS vulnerability was created by using Dual_EC_DRBG as the secure random number generator. Dual EC is known to be predictable, and if you can predict the PRNG (Pseudo Random Number Generator) used to encrypt data over the network, you can decrypt the data pretty easily. Supposedly it was being used with an ANSI X9.31 number generator (which is secure, ie theoretically impossible to predict numbers given previous numbers), but the backdoor was due to the fact that only Dual EC was being used. It wasn’t known if Dual EC existed for a while and they messed up replacing it with the ANSI RNG, or if they were added at the same time, etc.

New Info:

Juniper added Dual_EC_DRBG as a random number generator for it’s VPN encryption in version 6.2.0 (October 2008) despite already having ANSI X9.31. Additionally, by 2008 Dual_EC_DRBG was known to be broken (given a reasonably small amount of info, you could predict future numbers) and they also increased the Internet Key Exchange (IKE) nonce from 20 bytes to 32 bytes at the same time. The nonce change makes attacks that crack your RNG easier to pull off because they get more information about the state of the generator as they are just random data. They talk about it in the article, but a 32 byte nonce is the generally accepted minimum length needed to efficiently crack a Dual_EC_DRBG.

Conclusion

Juniper’s recent backdoor is looking less and less like an accident, and more like it was added on purpose. Whether this was on purpose by the company or the work of an engineer who slipped it in, it still is very worrying that someone most likely built a backdoor to JunOS VPN traffic that has been live for 7 years or so.

Why Backdoor and not Vulnerability: The fact that they changed the curve (what was the weak part) used by the Dual EC just means that it would only be easily exploitable by someone who knew the new curve, meaning it’s pretty much a backdoor, given the ‘key’ that is the correct curve.

Edit: Fixed Dual_EC_DRBG showing as DualECDRBG because markdown

1

tedu edited 2 years ago | link

Now removing EC RNG: http://forums.juniper.net/t5/Security-Incident-Response/Advancing-the-Security-of-Juniper-Products/ba-p/286383

Oh, also, summary above is inaccurate. The bug was in screenos, not junos.
1. 1
  
  noelle 2 years ago | link
  
  Yeah I realized my mistake too late to edit D: . I don’t really like that they have this nonsense at the end of that update though:
  
  Q: Pending the planned replacement of the Dual_EC, do Screen OS devices have sufficient cryptology?
  
  Yes. We believe that the existing code using Dual_EC with self-generated basis points provides sufficient cryptology notwithstanding issues with the second ANSI X.9.31 random number generator. We will replace both Dual_EC and ANSI X9.31 in ScreenOS 6.3.
  
  “Sufficient Cryptology” is literally gibberish.