Details about Juniper's Firewall Backdoor

Last year, we learned about a backdoor in Juniper firewalls, one that seems to have been added into the code base.

There’s now some good research: “A Systematic Analysis of the Juniper Dual EC Incident,” by Stephen Checkoway, Shaanan Cohney, Christina Garman, Matthew Green, Nadia Heninger, Jacob Maskiewicz, Eric Rescorla, Hovav Shacham, and Ralf-Philipp Weinmann:

Abstract: In December 2015, Juniper Networks announced that unknown attackers had added unauthorized code to ScreenOS, the operating system for their NetScreen VPN routers. This code created two vulnerabilities: an authentication bypass that enabled remote administrative access, and a second vulnerability that allowed passive decryption of VPN traffic. Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker. The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator’s output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper’s countermeasures against a Dual EC attack are never executed. Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

We still don’t know who installed the back door.

Tags: , , , ,

Posted on April 19, 2016 at 5:59 AM • 35 Comments

Comments

SoWhatDidYouExpect • April 19, 2016 6:36 AM

If they know this “backdoor” is in the code, they should take it out!

z • April 19, 2016 6:59 AM

With the Apple/FBI fight currently stilll going on and legislators intorducing terrible bills in response, this should be plastered all over the place as yet another example of why backdoors are such a cancer.

Michael P • April 19, 2016 6:59 AM

I’m curious to know how the interloper(s) covered their tracks in the revision control system used for the source code. Was it knowingly committed by an authorized user? Was an authorized account (or several) compromised to commit the code? Was the RCS server compromised, and if so, how was the code added? Large commit(s) with plausible messages that didn’t get review? Small bits added via other commits, so they are not easily identified or reverted?

z • April 19, 2016 7:06 AM

By the way, we may not know who installed the back door, but the fact that Juniper was using DUAL_EC_DRBG is pretty suspicious. It’s not even a good PRNG. I don’t see any reason why one would implement it unless they were paid to do it by the NSA as RSA was, or somehow coerced or tricked into it by them. As far as I can recall, Juniper was using their own custom Q value that they never explained, which is as bad or worse than the NSA’s Q value.

William • April 19, 2016 7:23 AM

Juniper is supposed to be a security company. There constant repetition of “unknown attacker” bothers me. Either they are still compromised and know it..and are unable to stop it OR they truly do not know how they got owned and are unable to figure it out. Either way this means Juniper for me is out until they can come up with something better than unknown attacker. Are their system secure now or not? right now I have to assume not.

Dan3264 • April 19, 2016 7:30 AM

@z,
Juniper probably installed the backdoor. For some reason or other they thought it was a good idea to stick a passive decryption vulnerability in their code. All the attackers had to do was stick in their own Q. Suddenly they were the ones who could read all traffic. Juniper made it easy for them to do so. As with the Underhanded C Contest, this shows that you are in big trouble if the developers are working against you. The winning entries for the Underhanded C Contest have “bugs” that are really hard to detect.

Kai Howells • April 19, 2016 7:30 AM

I would say it’s likely that it was put there intentionally, with the knowledge of key people at Juniper. Something like this doesn’t just sneak into the code. They may be under a gag order about it, so they come up with the equally worrying story that some unknown attacker put it in there at an unknown time.

So, they either can’t be trusted because they put it in there intentionally, or they can’t be trusted because they were pwned and someone snuck it in without anyone noticing.

sleight_use • April 19, 2016 9:06 AM

Either everything about Juniper’s dev team is run like an unaudited sandbox and very little is known about the codebase or it was an “ask” by a three-letter agency.

The former is possible if coding is outsourced or it’s the typical sausage factory where devs come and go. I’m a pessimist in these matters and assume the latter.

OJ vows to find the killers • April 19, 2016 9:29 AM

“We still don’t know who installed the back door.”

This is hilarious groveling, but it’s everywhere. Every analyst quizzically scratches their chin while straining to pretend that the guys who bragged they did it didn’t do it. The FEEDTROUGH documents are an admission against interest that points blinking neon arrows at NSA.

Some people are highly credible when they play dumb but Bruce is too self-evidently smart to pull it off. It is unseemly.

r • April 19, 2016 10:16 AM

Is it safe to assume when software is perpetually backdoored like this the hardware is reasonably safe? Or is it, by not knowing which actor is involved in the tampering with the development it’s not safe to assume anything is clean?

K.S. • April 19, 2016 10:52 AM

@r

I think it is safe to assume that both software and hardware are perpetually backdoored, and by choosing vendor’s country of origin you can guess what agencies would be able to gain access to your infrastructure via these backdoors.

Jeff Johnson • April 19, 2016 10:53 AM

NetScreen was a Chinese company operating from the US. Fortinet founded by same group. NetScreen acquired by Juniper 2004 becoming Juniper’s Security Products Group. The Security Products Group moved to China 2005 after “surprise” award of major portion of “Great China Firewall” (CN2). MPS and PLA closely involved in Juniper SPG from that moment forward. Full development lifecycle. NetScreen founders, Deng Feng and Yan Ke found NLVC to focus on China ventures. Sigma R-T is funded by NLVC and becomes Juniper’s contracted software test partner. Sigma R-T also founded by former NetScreen leads. Dual EC selected by Juniper SPG even after white paper published describing weaknesses. “Snowden Effect” does not impact Juniper? Why? Juniper continues to win large deals in China and receives no negative press or threats like Cisco, Apple, etc. Why? Fortinet leap frogs over Juniper two years ago. Juniper no longer required. China Fortinet up to #3 position behind Cisco and CheckPoint. To gain market share, best to take share from Juniper, Cisco and Checkpoint. Hillstone, also NLVC company with former NetScreenets also needs market share. Who do you think out the backdoors in? Who owned the development life-cycle? Who owned test? Who gained? Same for the other backdoors discovered since at other companies. Missing the trees and the forest on this one while disecting a single symptom.

z • April 19, 2016 1:42 PM

@ OJ vows to find the killers

It’s not that simple.

It is quite possible that there are multiple backdoors from different sources. The NSA is not the only agency with the capability or desire to do this kind of thing. If Juniper’s odd use of DUAL_EC_DRBG was at the request/threat of the NSA (I believe it was), I I find it implausible that the NSA would then surreptitiously break in to install another backdoor.

However, some other agency could very well have recognized the presence of DUAL_EC_DRBG and realized they could piggyback off of it for their own uses.

z • April 19, 2016 1:44 PM

Clarification of the above: by “agency” I do not mean another US gov agency. I mean any nation-state or competent criminal group with the ability to do this.

OJ is hot on the trail of his dead wife's killers • April 19, 2016 3:59 PM

@zkeptical “it’s not that simple,” to wit,

‘Sure NSA said they did it, but, uh, maybe somebody else did it too, because ah, NSA, having shot Juniper’s platform fulla holes, maybe didn’t notice that somebody else sabotaged it, Or!, um, maybe they figured, shrug, shrug, you know, none of my business, (Cyberdefense? meh.) …live & let live!…?’

Plausible Deniability FAIL. That is the stupidest thing I ever heard. Have you actually found humans dumb enough to swallow that? Does it work pretty good on anencephalic Zika babies, or what? Try that on the UNCITRAL panel when Juniper claims compensation and restitution for wrecking a $12B company. Try it on the ICJ when half the G-77 suspend treaties as a countermeasure for duplicitous proceedings in breach of the VCLT. Try it on the special procedures and the HRC complaint procedure. You’ll never know what hit you.

Face it, you Bozos fatally stepped on your crank. CIA is going to take you over and treat you like the fatass deskbound pussies that you are. They’re going to put you to work recording icky pedo honeytraps of federal judges, and you’re going to have to transcribe it all blow-by-blow. Couldn’t happen to a nicer bunch of voyeurs.

Arnold • April 19, 2016 8:14 PM

Interesting posts, as Bruce had been following this up with series of blog entries. This is probably just an outdated tech from you-know-where that gets spun off and picked up by a “foreign government”. As we all know, the folks up there deem it “fair game” when applicable to the masses. Now, more from the sci-fi writer to follow..

MarkH • April 20, 2016 9:32 AM

This post describes Juniper in a configuration with a substituted Q value in Dual EC.

What is the logic of attributing this configuration to NSA?

We know that the standard Q for Dual EC is already compromised, but ONLY to the NSA (or another party who somehow learned from NSA the index of Q in the group).

We know this on two bases: first, Dual EC is such a lousy PRBG that the only reasonable motivation for it is to weaken security (but only to NSA and nobody else); and second, from the Snowden revelations.

Accordingly, substituting a different Q would NOT increase NSA’s ability to decrypt traffic. However, if the substitution were made by another actor (not NSA), that actor would gain the ability to decrypt traffic, and at the same time deprive NSA of that specific backdoor.

There is good reason to believe (won’t rehash this today) that critical secrets like the index of Q are safeguarded by NSA at an extremely high level of protection. They are NOT thrown around on networked servers like the stuff Snowden grabbed.

The only motivation for NSA to substitute a different Q, would be worry that the index of the original Q has leaked.

Is it more likely that NSA doesn’t trust their “Ring 0” of secret safeguards, or that another actor made the substitution of Q?

Is there something special about the user community that gives extraordinary value to Juniper traffic?

Who is likely to take the risk of the described hack, with such a high likelihood of detection?

Doik doik • April 20, 2016 9:34 AM

NSA’s psyops clowns can knock themselves out simulating reasonable doubt but they’re busted and they’re already facing the consequences. The blowback from US government treachery is helping NATO disintegrate faster. Germany PNGed Ralph Goff and suspended WHARPDRIVE cooperation. The EU is leaning on CIA cutouts Facebook and Google amid demarches from the European Parliament and NATO members. Governia is shunting fiber around Sweden to stop Swedish complicity in NSA spying. Leaks and whistleblower protections pressure colluding third-party spy agencies.

Worst of all for NSA, the allies are tightening up international law (pdf). The ‘codex’ would make make criminals of NSA – not just in municipal jurisdictions as they are now, but in conventional international law. The codex doesn’t wait on the Council of Europe. The treaty body has incorporated two of the four main codex provisions into US ICCPR compliance issues where it will slowly bleed what remains of US influence and legitimacy.

z80 • April 20, 2016 10:09 AM

@MarkH

Is there something special about the user community that gives extraordinary value to Juniper traffic?

A few of the better known Juniper customers: Vodafone, Siemens, TeliaSonera, Level 3, Deutsche Telekom, Google

JNPR Apr. 29 puts, the deal of the century! • April 20, 2016 3:20 PM

The next shoe to drop: Juniper liability for assisting the torture of Gulet Mohamed?

Cisco’s up against it now, trying to escape torture liability, and they haven’t shown Juniper’s winking complicity with spies. NSA helped target Gulet Mohamed for torture but they enjoy domestic impunity. So Juniper will pay.

John Michael • April 21, 2016 2:10 AM

Vulnerabilities created by source code allow only unauthenticated device by firewall, an kind of software that allow the operator to control a system so that the vendor can access the host system from another computer. By installing parameter there is a possibility to decrypt a single IKE without any other network VPN can associate itself.

Oox7aeki • April 21, 2016 2:54 AM

Why a different Q:

(ancient): original Q0=c974… selected
2008: Juniper introduce a vulnerable RNG with Q1=2c55…
2012: unknown adversary sets Q2=9585…
2015: vulnerability uncovered

If Q2=Q0 then it would be obvious that the adversary was the originator of Q0. Since it isn’t, we have learned nothing about the identity of the adversary.

MarkH • April 21, 2016 11:57 AM

If Oox7aeki’s chronology is accurate, and I understand it correctly, then Juniper (at least after 2008) did NOT use NIST standard Dual EC DRBG parameters.

Accordingly, Juniper’s implementation would not have been vulnerable to the NSA unless either (a) the alternative base point was chosen in collusion with NSA, or (b) the alternative base point was chosen incorrectly in a manner that weakened security.

So, if Dual EC is secure when used without backdoored base points (as seems likely to be true), and Juniper’s alternative Q was chosen correctly and without collusion, then their pseudo-random generation was presumably NSA-proof up to the 2012 substitution.

Curioser and curiouser …

Bumble Bee • April 22, 2016 1:11 AM

Same old same old. You can’t lock your car anymore because bellboys, valets, tow truck drivers, and parking lot attendants all have to have a master key. “The NSA” my ass.

Bumble Bee • April 22, 2016 1:28 AM

And your blog hasn’t gone on daylight savings time yet or else it’s the wrong time zone or the IP address geolocator isn’t working or I’m on some sort of crappy slow VPN…and the GPS crapped out on my phone and mostly I shut it off anyway to save battery so nobody really knows where I am. Riiight…

Oox7aeki • April 22, 2016 2:56 AM

I would welcome corrections to the chronology, the above is just based on some googling.

The paper linked at the top has the other design choices & bugs making the vulnerability exploitable also happening in 2008. Unless we accept that was all a big unfortunate coincidence then the implication is that Q1=2c55… is also backdoored.

As far as I know Juniper haven’t made any public statements about the origins of the design.

z • April 22, 2016 9:03 AM

@ Oox7aeki, MarkH

As far as I can tell, this chronology is correct. Also, it is correct that Juniper never did explain their choice of Q. I do not believe it was done to improve security or trust. If that was their goal, why use Dual EC in the first place? It isn’t even very good, and unless passive decryption is your goal, there is no reason to use it. If trust and transparency was the goal, why keep Q1 a secret?

A couple theories to consider:

1.) Juniper was using a backdoored Q for the NSA’s decryption. This doesn’t make much sense given that they could just use the original Q0, but I’ll acept that there could be a possibility that there are multiple backdoored Q values and the new one was also from the NSA. Why they would not use Q0, I do not know. In 2008, nothing about Dual EC was publicly leaked yet, though the academic community had already figured it out.

2.) Juniper was using a backdoored Q at the request of someone else. Consider a situation where GCHQ wants the decrypted traffic but doesn’t want to have to ask the NSA for it. The NSA isn’t going to give them the index of Q0, so GCHQ generates Q1 and bribes/threatens Juniper into using it. Substitute “GCHQ” with any other intelligence agency from any country if you wish.

3.) Juniper did it for themselves. They could benefit from analysis of the traffic in plaintext,such as by stealing corporate secrets and selling them, but they stand to lose a lot. They’re in the business of securing communications. If they deliberately sabotage that, they lose a lot of trust. At least if they are ordered to do it by a gov, they can throw up their hands and claim they had no choice.

None of this addresses the question of who broke in and changed Q. That could be a lot of different actors, ranging from rival nation-states to criminal groups. Whoever it was didn’t have the ability to exert pressure on Juniper to do it themselves, so I don’t think it was a 5 Eyes government.

John Campbell • April 22, 2016 3:47 PM

So, you go along with a TLA (“Three Letter Agency”) and implement what they requested given their threat to have the tax authorities audit you, your friends, your relatives and your dead ancestors.

On top of that you are informed of draconian punishments should you even MENTION that you’ve plugged in a back door for these TLAs.

So, when an independent– one not subject to being told “Never Say Anything” when an exploit is detected– announces the discovery of backdoor code, you have NO CHOICE but to say “We don’t know how this exploit was engineered in” given you are not allowed to admit to collaborating with a TLA.

The truth? Some TLA has announced that none of us can HANDLE the truth.

James Sutherland • April 24, 2016 12:08 PM

Assuming the “wrong” Q value doesn’t have a legitimate explanation (like “it’s a prime-based RNG, but we were suspicious of the NSA’s choice so picked our own”) it seems clear (a) it’s a backdoor (b) it’s NOT the NSA’s one (since that was the original Q value anyway!)

So, who could (a) either compromise Juniper’s internal codebase or infiltrate their staff, and (b) develop their own backdoor comparable to NSA’s or infiltrate the NSA to the extent of finding out about it that way (just as Snowden did)?

Someone pointed out above that Snowden was able to get the information that Q was a backdoor, but not the actual keying material to exploit it, since that would be much more tightly secured. If Snowden got that, I’d be quite certain others with less benign motivation got it for their own agencies as well – but, like Snowden, not high enough access to be able to exploit the existing backdoor, only to create one of their own and infiltrate it in target systems.

An entity like the PRC seems to me to fit perfectly. NSA and close allies, I think we can rule out – they’d either already have the real key themselves, or have more to lose if caught duplicating the back door – and who else could have had that level of both crypto knowledge and access?

(What might be interesting is to monitor for traffic that could exploit the DualEC backdoor, i.e. attempts to get some random numbers, like an SSL connection to the same appliance or a failed VPN connection attempt. Anyone tried monitoring for that kind of thing lately?)

David Grantham • June 6, 2016 6:43 AM

If you have over 64,000 connections going through the firewall into a single IP, you can have multiple IP addresses in the pool and the SRX will alternate between the IP addresses defined in the pool.

Fatima • November 17, 2017 8:00 PM

I don’t know if this is the right blog where to post this question.
We recently deployed a pair of Juniper MX960 routers to perform multiple network functions and among them the L3 statefull firewall function. on both sides of trusted and untrusted interfaces we are receiving MP-BGP VPNv4 routes. I do understand the IP flows discontinuity (flows are permitted or blocked) but I don’t understand why its not possible to advertise the MP-BGP routes from the trusted to untrusted and vice-versa.

Thanks for help in advance.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.