ScreenOS

ScreenOS

Developer	Juniper Networks
Working state	Current
Source model	Closed source
Latest release	6.3.0r21 / December 2015 (2015-12)
License	Proprietary

ScreenOS is a real-time embedded operating system for the NetScreen range of hardware firewall devices from Juniper Networks.

Features

Beside transport level security ScreenOS also integrates these flow management applications:

• IP gateway VPN management - ICSA-certified IPSec
• IP packet inspection (low level) for protection against TCP/IP attacks
• Virtualization for network segmentation

Possible NSA backdoor and 2015 “Unauthorized Code” Incident

An intentional or unintentional possible backdoor, which would allow an attacker knowing a secret key to passively decrypt VPN traffic, has been present in ScreenOS for a long time, Matthew Green writes probably since before before Juniper acquired NetScreen Technologies in 2004. ScreenOS uses a strange construction of having one known broken CSPRNG (Dual_EC_DRBG) seed another CSPRNG (ANSI X9.17), which seemed strangely redundant as just using just the ANSI X9.17 CSPRNG should be perfectly secure. And Dual_EC_DRBG had been regarded as broken since at least 2007, so it was strange that ScreenOS chose to use it; Bruce Schneier wrote in 2007 that I don't understand why the NSA was so insistent about including Dual_EC_DRBG in [NIST SP 800-90A]. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it turned out that an intentional or unintentional bug in the code meant that Dual_EC_DRBG output was leaked directly, which was required to enable the Dual_EC_DRBG backdoor. As Matthew Green wrote it's not clear what value Dual EC is really adding to the system in the first place – except, of course, its usefulness as a potential backdoor. If this backdoor was intentional, then the only party to profit would have been the holder(s) of the secret key associated with the Q used in Dual_EC_DRBG in ScreenOS, and it is possible that nobody knows the secret key if Q has been chosen randomly.

I don’t want to say that Juniper did this on purpose. But if you wanted to create a deliberate backdoor based on Dual_EC and make it look safe, while also having it be vulnerable, this is the way you’d do it. The best backdoor is a backdoor that looks like a bug, where you look at the thing and say, ‘Whoops, someone forgot a line of code or got a symbol wrong.’ … It makes it deniable. But this bug happens to be sitting there right next to this incredibly dangerous NSA-designed random number generator, and it makes that generator actually dangerous where it might not have been otherwise.

— Matthew Green

Following the Snowden leaks, it became almost confirmed that NSA had a kleptographic backdoor via the constants P and Q NSA had picked for Dual_EC_DRBG, by knowing d such that d*P=Q. At an unknown point, possibly before using Dual_EC_DRBG in ScreenOS, Juniper changed NSA's P and Q to their own P_Juniper and Q_Juniper. Juniper gave no explanation of how their new P_Juniper and Q_Juniper had been chosen, which as Matthew Green pointed out in 2015 meant that Juniper might possibly have a backdoor d_Juniper into the P_Juniper and Q_Juniper used in ScreenOS.

As discovered by Juniper in 2015, somebody (most speculation guessing a nation state attacker other than NSA) surreptitiously modified the ScreenOS code in 2012 to change Q_Juniper to Q_attacker, presumably so that that attacker knew a secret key d_attacker such that d_attacker*P_Juniper=Q_attacker, and therefore could use the backdoors in Dual_EC_DRBG and ScreenOS to decrypt ScreenOS traffic. Juniper itself did not describe the exact backdoor mechanism in their press release, but independent security researchers such as Ralf-Philipp Weinmann very quickly disassembled the updated firmware and analysed the differences from the compromised versions.

Following this discovery by Juniper, Juniper released new firmware which reverted Q_attacker back to Q_Juniper, but left the rest of the Dual_EC_DRBG backdoor infrastructure infrastructure in ScreenOS intact. Notably this means that Juniper might still posses the secret key d_Juniper to their P_Juniper and Q_Juniper, which would allow Juniper itself (and anybody Juniper gave the key to) to decrypt ScreenOS traffic. Ralf-Philipp Weinmann has noted that one line of code could disable the backdoor for good, and wondered why Juniper had not done this when reverting Q_attacker to Q_Juniper.

Juniper has not explained how the original intentional or unintentional possible backdoor in ScreenOS came to be. The vulnerability added to the public debate about the installation of backdoors in cryptographic systems, since it seems possible that NSA backdoor infrastructure (at least the standardization of Dual_EC_DRBG) was used by attackers hostile to USA to attack US targets.

In addition to the Dual_EC_DRBG-based passive traffic decryption backdoor, Juniper also found a simple root password backdoor in ScreenOS at the same time in 2015. It was not clear whether this backdoor was inserted by the same adversary who inserted Q_attacker.

NSA and GCHQ

A 2011 leaked NSA document says that GCHQ had current exploit capability against the following ScreenOS devices: NS5gt, N25, NS50, NS500, NS204, NS208, NS5200, NS5000, SSG5, SSG20, SSG140, ISG 1000, ISG 2000. The exploit capabilities seem consistent with the program codenamed FEEDTROUGH.

Versions

ScreenOS version	Release date	End of Support	End of life
6.3.0r21	December 2015
6.0	19 April 2007	19 April 2010	19 April 2011
5.4	24 July 2006	24 July 2009	24 July 2010
5.3	24 October 2005	24 October 2008	24 October 2009
5.2	11 May 2005	11 May 2008	11 May 2009
5.1	22 October 2004	22 October 2007	22 October 2008
5.0	18 December 2003	18 December 2006	18 December 2007
4.0	1 August 2002	31 October 2006	31 October 2007

Weblinks

ScreenOS Software Documentation