SoylentNews

Researchers Solve Juniper Backdoor Mystery; Signs Point to NSA

posted by martyb on Sunday January 03 2016, @07:26AM   
from the key-point-is-to-mind-your-Ps-and-Qs dept.

An Anonymous Coward writes:

Wired reports:

Security researchers believe they have finally solved the mystery around how a sophisticated backdoor embedded in Juniper firewalls works. Juniper Networks, a tech giant that produces networking equipment used by an array of corporate and government systems, announced on Thursday that it had discovered two unauthorized backdoors in its firewalls, including one that allows the attackers to decrypt protected traffic passing through Juniper's devices.

The researchers' findings suggest that the NSA may be responsible for that backdoor, at least indirectly. Even if the NSA did not plant the backdoor in the company's source code, the spy agency may in fact be indirectly responsible for it by having created weaknesses the attackers exploited.

Evidence uncovered by Ralf-Philipp Weinmann, founder and CEO of Comsecuris, a security consultancy in Germany, suggests that the Juniper culprits repurposed an encryption backdoor previously believed to have been engineered by the NSA, and tweaked it to use for their own spying purposes. Weinmann reported his findings in an extensive post published late Monday.

Previously on SN: "Unauthorized Code" in Juniper Firewalls Decrypts Encrypted VPN Traffic.

---

Original Submission

• Re:NSA? (Score: 2) by martyb on Sunday January 03 2016, @01:25PM

  by martyb (76) on Sunday January 03 2016, @01:25PM (#284055) Journal

  Parent comment stated:

  I'm still trying to determine if the UPDATE at the top of the article totally shoots down their theory (and if so, why leave the article up).

  NOTE: The update referenced in the parent comment comes from: Some Analysis of the Backdoored Backdoor [rpw.sh] "The Article"; to wit:

  Update: Shortly after reading my post, Willem Pinckaers [twitter.com] pointed out that the reseed_system_prng function sets the global variable system_prng_bufpos to 32. This means that after the first invocation of this function, the for loop right after the reseed call in system_prng_gen_block never executes. Hence, the ANSI X9.31 PRNG code is completely non-functional.

  There are two pseudo-random number generators under discussion here: the Dual_EC DRBG and the ANSI X9.31 PRNG. The story claims that the Dual_EC one was backdoored.

  The Article references Juniper's knowledge base article KB28205 [juniper.net] which states:

  ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations.

  So, even if Dual_EC were backdoored, its being used to feed into the ANSI one would render the backdoor ineffective: the output would be random based on the output of the ANSI code.

  The Update suggests that this is NOT the case, that after the first iteration through the loop, a global variable is set which renders the ANSI code ineffectual. In other words, a backdoor in the Dual_EC code WOULD manifest; the ANSI code would not be an effective mitigation.

  The forgoing is based entirely on what I read in the linked articles. IANAC (I Am Not A Cryptographer). Feedback and corrections welcome.

  --
  Wit is intellect, dancing.

  Parent

  Starting Score:	1		point
  Karma-Bonus Modifier		+1
  Total Score:		2