Can we trust Juniper?

Did Juniper purposely install backdoor code in ScreenOS at the behest of the US National Security Agency or was it simply the victim of an as-yet unidentified third-party attacker?

Doubts have been raised as to whether the security giant can now be trusted to protect our enterprises, given every scenario this story offers has Juniper looking either incompetent or something much, much worse.

ScreenOS is the underlying software that powers Juniper’s widely acclaimed range of firewalls, known as NetScreen.

Following an internal code review last December, Juniper announced two critical vulnerabilities (CVE-2015-7755 and CVE-2015-7756), which it quickly released patches for.

However, as the security community began the painstaking work of investigating the impact of these vulnerabilities, a number of disturbing facts came to light related to CVE-2015-7756.

According to Juniper’s advisory: “[CVE-2015-7756] may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic.

“There is no way to detect that this vulnerability was exploited.”

Alarmingly, Juniper didn’t supply any real detail, just an inference to this cryptosystem problem and the subsequent patch.

As usual, this lack of detail spurred the security community to look under the hood to see what was really going on; this is where it gets interesting.

For many years, ScreenOS has used a random number generator, called Dual-EC-DRBG, which was originally standardised by via NIST, but originated from the NSA.

There have always been doubts over the use of Dual-EC-DRBG, as many cryptography experts believe the NSA built this random number generator to be fallible to the agency's own offensive espionage department.

For an encryption system to be effective, a couple of things are critical to it keeping your data secret: the protection and randomness of the keys. Without randomness, keys can be determined and the cryptosystem can be broken.

Juniper knew about the potential for this NSA backdoor, even suggesting it wasn’t an issue, since its implementation included another FIPS-140 approved random number generator, called ANSI X9.17, operating in serial after the Dual-EC-DRGB generator.

Dual-EC-DRGB fed its output into ANSI X9.17, hence the random number used in Juniper's cryptosystem was seeded by the output of both random number generators, meaning it could not be determined.

That was great news - however, a mistake in the software meant that ANSI X9.17 never worked and the randomness came from Dual-EC-DRGB only. This means the NSA or Juniper could backdoor the cryptosystem, leaving it open to misuse.

What came next was even more interesting. In 2012, an unknown third-party infiltrated Juniper’s development systems and compromised ScreenOS’s codebase, reseeding the Dual-EC-DRGB random number generator with a starting point that they knew (meaning the NSA would not have been able to access its backdoor after this date).

This unknown third party could now compromise any NetScreen VPN remotely with just 32-bytes of raw data.  

Juniper spotted this error after three years and fixed the problem. However, researchers discovered that Juniper simply reset the seed back to its previous number, leaving ANSI X9.17 not engaged in the generation of randomness.

Can Congress uncover the truth?

It was heartening to see last week’s announcement of the imminent US congressional investigation into this matter, as it will hopefully help us decide whether or not we can trust Juniper to protect our systems and networks.

But we are still left with a bad taste in our mouths.

It will be telling to see if Will Hurd, the Texas Republican leading the investigation, takes his team beyond its initially stated goal of determining whether US government agencies are at risk.

We need to know the whole truth, as there is a lot more at stake than just the reputation of one company.

Tough questions need to be asked of Juniper regarding its internal control over systems engineering and quality control, and customers need to know how exposed they are to this insidious backdoor that’s been in the hands of an unknown third-party since 2012.