Back Door in Juniper Firewalls

Juniper has warned about a malicious back door in its firewalls that automatically decrypts VPN traffic. It’s been there for years.

Hopefully details are forthcoming, but the folks at Hacker News have pointed to this page about Juniper’s use of the DUAL_EC_DBRG random number generator. For those who don’t immediately recognize that name, it’s the pseudo-random-number generator that was backdoored by the NSA. Basically, the PRNG uses two secret parameters to create a public parameter, and anyone who knows those secret parameters can predict the output. In the standard, the NSA chose those parameters. Juniper doesn’t use those tainted parameters. Instead:

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.

This means that all anyone has to do to break the PRNG is to hack into the firewall and copy or modify those “self-generated basis points.”

Here’s a good summary of what we know. The conclusion:

Again, assuming this hypothesis is correct then, if it wasn’t the NSA who did this, we have a case where a US government backdoor effort (Dual-EC) laid the groundwork for someone else to attack US interests. Certainly this attack would be a lot easier given the presence of a backdoor-friendly RNG already in place. And I’ve not even discussed the SSH backdoor which, as Wired notes, could have been the work of a different group entirely. That backdoor certainly isn’t NOBUS—Fox-IT claim to have found the backdoor password in six hours.

More details to come, I’m sure.

EDITED TO ADD (12/21): A technical overview of the SSH backdoor.

EDITED TO ADD (12/22): Matthew Green wrote a really good technical post about this.

They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone—maybe a foreign government—was able to decrypt Juniper traffic in the U.S. and around the world. And all because Juniper had already paved the road.

Another good article.

Tags: , , , , , , ,

Posted on December 21, 2015 at 6:52 AM • 41 Comments

Comments

Clive Robinson • December 21, 2015 8:09 AM

Off the two back doors that appear to be present –so far– there are two questions that arise,

1, is there an NSA insider at Juniper.

2, Why did take so long to spot the easy backdoor, during code review processes.

As others have noted, this news quite nicely points out why even NSA et al backdoors are very very bad news for everyone. But Obama still signed on the dotted line…

Steph • December 21, 2015 8:44 AM

Wild speculation: The suits mandated use of dual-ec-drbg due to political pressure, the programmers knew it was defective by design, so they tried to salvage things by using a non-default parameters.

65535 • December 21, 2015 9:32 AM

Just great /

“The argument to the strcmp call is <<< %s(un=’%s’) = %u, which is the backdoor password, and was presumably chosen so that it would be mistaken for one of the many other debug format strings in the code. This password allows an attacker to bypass authentication through SSH and Telnet, as long as they know a valid username…” –Wired

http://it.slashdot.org/story/15/12/21/1257200/junipers-backdoor-password-disclosed-likely-added-in-late-2013

Now, the other question is where is the backdoor in Cisco’s firewalls [PIX and ASA]?

65535 • December 21, 2015 9:36 AM

should be:

[…%s(un=’%s’) = %u…]

If the above do not post the moderators are hard at work.

Mike Amling • December 21, 2015 9:59 AM

“Basically, the PRNG uses two secret parameters to create a public parameter, and anyone who knows those secret parameters can predict the output.”

Kind of. Someone who knows the secret backdoor parameter (AFAIK, there’s only one, P/Q (or maybe it’s Q/P)) and who has a block of output from Dual_EC can predict the future blocks of output from it. IIRC SSL/TLS is in particular vulnerable because it sends some of its raw RNG output on the connection before using subsequent RNG output to generate session keys. But if Juniper is using Dual_EC output only to feed into some other RNG, I would think it’s not vulnerable to the back door.

Of course, this doesn’t address the fundamental problem of RNGs, getting the seed entropy.

Dirk Praet • December 21, 2015 10:27 AM

@ Steph

The suits mandated use of dual-ec-drbg due to political pressure, the programmers knew it was defective by design, so they tried to salvage things by using a non-default parameters.

Which still left an open backdoor.

Since the VPN backdoor predates Snowden, the 64k question here is who knew for a fact in 2012-2013 that DUAL-EC-DRBG was rigged and how to exploit it. IMHO, that’s either the NSA or another 5-Eyes party that information was shared with. Which leaves quite some possible attribution scenarios:

1) Juniper is in bed with the NSA, knew about the backdoor and someone within the company during a code review inadvertently sounded a general alarm that could not be contained. The FBI is now investigating how this could happen.
2) Juniper is not in bed with the NSA, but the backdoors were done by an NSA or 5-Eyes implant.
3) Neither backdoor was done by the NSA or its partners, but by a 3rd party nation state actor who knew about DUAL-EC-DRBG.

Which leads to either of the following:

1) Juniper are rat bstrds who don’t take their customers’ security serious and deserve to go out of business.
2) Juniper doesn’t take version control and code review processes seriously. But by coming clean, they at least acknowledge there is a problem and that they’ll be working on it.
3) If it wasn’t the NSA, NOBUS has once again been shown to be a fairy tale.

I’m quite curious to see which countries will be putting Juniper products on their blacklist in the time to come. If both the Russians and the Chinese do so, then we can be reasonably certain it was the NSA quite alright.

Sasparilla • December 21, 2015 10:29 AM

The Wired article is the best overview article I’ve read so far. Appears there are 2 back doors.

The first backdoor Juniper found would give an attacker administrative-level or root privileges over the firewalls.

The second backdoor would effectively allow an attacker who has already intercepted VPN traffic passing through the Juniper firewalls to decrypt the traffic without knowing the decryption keys.

The 1st backdoor password was easy to guess and the analyst in the Wired article was thinking it was too sloppy to be the NSA, but didn’t think that of the 2nd one.

Nick P • December 21, 2015 10:30 AM

@ Steph

“Wild speculation: The suits mandated use of dual-ec-drbg due to political pressure, the programmers knew it was defective by design, so they tried to salvage things by using a non-default parameters.”

Interesting idea. I’m surprised we haven’t seen that scenario happen already.

david • December 21, 2015 10:45 AM

It’s not clear that the change was the backdoor keypair of Dual EC.

And it’s also not clear if there is an exploit since Juniper says that they only use in parts of their product that can’t be exploited with the known backdoor

(more info on how dual EC works, and how it is a backdoor: https://www.youtube.com/watch?v=OkiVN6z60lg )

Clive Robinson • December 21, 2015 11:46 AM

@ Steph,

Wild speculation: The suits mandated use of…

How about a different “wild” scenario,

The DUAL-EC random generator backdoor was found by an insider, or they overheard some one on the inside talk about it… They then decided if “it’s policy” to add an easy to use backdoor of their own… No doubt the FBI will find “the easy backdoor” suspect and work them over so they cop to both to save managment blushes or the real implants job…

One thing that might be worth doing is to see which US Gov Depts had the effected routers and which did not, it might tell an interesting story in it’s own right.

However that does not change my points from the other day, in that importantly this shows the problems with,

1, Insider / Implant agents.
2, Backdoors of any kind.
3, Not using proper “end to end” encryption.
4, Trusting proprietary solution providers.
5, Closed sorce “code review” processes.

And one or two others besides…

The only solution to this type of issue is “To instrument and mittigate” and don’t forget you don’t realy control your hardware unless you take proper segregation steps…

herman • December 21, 2015 11:56 AM

Nothing beats staring at the logs every day.

The trouble with supposedly secure endpoint devices is that the logs need to be forwarded to another machine, else nobody will ever look at them.

blame_shifter • December 21, 2015 12:30 PM

I love how Juniper is claiming “unauthorized code” to shift the blame away from whatever actually happened.

It’s still a horrible excuse. If it were actually “unauthorized code” then that says far more about the state of security in an org that derives value from providing security. Cisco, I’m certain, is no better.

I just hope pfsense (bsds) are marginally better in this regard.

Jesse Thompson • December 21, 2015 2:44 PM

@Dirk Praet

the 64k question here is who knew for a fact in 2012-2013 that DUAL-EC-DRBG was rigged and how to exploit it.

Well, I learned it was rigged in 2012 for one. 2012 is when I began to study Bitcoin, and discovered that Satoshi chose Secp256k1 due to insufficient base point entropy to suggest the presence of any back doors, unlike the NIST recommendations of the time.

Dirk Praet • December 21, 2015 3:28 PM

@ Jesse Thompson

Well, I learned it was rigged in 2012 for one.

DUAL-EC-DRBG was suspected to be backdoored as early as 2004-2005, amongst others by our esteemed host. But it was not until 2013 that it was kinda confirmed as being part of NSA’s BULLRUN efforts. In April 2014, NIST eventually withdrew it from its draft guidance on random number generators. Both events were a clear heads-up to ANY vendor to remove it from ANY security product. Which Juniper obviously ignored, again leaving the following options:

1) Juniper are a bunch of incompetent and irresponsible *ss clowns.
2) Someone coerced them to leave it in.

We know from Snowden that Juniper’s NetScreen was a target of the NSA’s FEEDTHROUGH program ( DNT’s BANANAGLEE and CES’s ZESTYLEAK).
So either the now revealed backdoors were indeed done under this program, or – if not – are something else by another state actor. Which for all practical purposes would make them a Swiss cheese subverted by multiple state actors and whose security certifications should be revoked immediately until they come up with an acceptable story.

I am at this point recommending all of my customers to ditch all Juniper firewall/VPN appliances, including those running JunOS. This company can no longer be trusted. It’s only by hitting them where it hurts the most that they will learn to take their stuff seriously and/or say no to the NSA and its ilk.

3y8f64jt • December 21, 2015 6:10 PM

Everyone keeps calling that NSA program “FEEDTHROUGH” but it’s actually “FEEDTROUGH”.

No Such Agency • December 21, 2015 8:55 PM

That Cisco FAQ is a joke. Read it very carefully; it is so specific, it allows backdoors to exist.

hugo • December 22, 2015 12:41 AM

What’s the chance that the backdoor was installed while the product was under control of NetScreen Technologies, before Juniper’s acquisition?

hugo • December 22, 2015 12:56 AM

To answer my own question, the Rapid7 blog post states:

This is interesting because although the first affected version was released in 2012, the authentication backdoor did not seem to get added until a release in late 2013

According to Wikipedia the NetScreen acquisition was 2004.

Vesselin Bontchev • December 22, 2015 2:48 AM

There are indeed 2 backdoor. The one disclosed by Rapid7 has been put there by some lamer. First of all, it is in cleartext in the code (instead of using some hash of it, for instance). Second, they managed to do it only the last year:

https://twitter.com/thegrugq/status/679028059907887104

The other one has been in there for much longer. The reason why Juniper Networks sounded so confident after the Snowden disclosure that the NSA had backdoored DUAL_EC_DRBG was because they used it with parameters different from the ones suggested by NIST. It’s like changing the locks on the backdoor.

However, it is not immediately clear how this second backdoor could be used for breaking the VPN traffic. See this for a technical discussion of the issue:

https://rpw.sh/blog/2015/12/21/the-backdoored-backdoor/

DetunizedGravity • December 22, 2015 3:03 AM

As for Juniper not alloting enough resources to things like code review, etc. I’d like to bring your attention to the fact that it happened during the very last years of the lifetime of NetScreen. Most commercial and technical resources at that time were dedicated to polishing and selling the security aspects of JunOS and the SRX devices. Juniper was missing its customers very very hard towards its next gen products back then. I remember how hard it could be to obtain support for, and changes in, NetScreen at that time. This probably participated in what we discover today.

Gerard van Vooren • December 22, 2015 4:06 AM

@ DetunizedGravity,

As for Juniper not alloting enough resources to things like code review, etc. I’d like to bring your attention to the fact that it happened during the very last years of the lifetime of NetScreen.

Here is a quote from the article:

ScreenOS does make use of the Dual_EC_DRBG standard…

It has been said before that Dual_EC_DRBG is questionable but after the Snowden revelations alarm bells should have rang. There is no excuse for this.

Woo • December 22, 2015 6:19 AM

I don’t really get it.. if someone managed “to hack into the firewall and copy or modify those “self-generated basis points.””, isn’t he in there already and could siphon the traffic out by an easier means?

Clive Robinson • December 22, 2015 8:57 AM

@ Woo,

… isn’t he in there already and could siphon the traffic out by an easier means?

With easy comes high visability.

That is the attacker has no way of knowing how the target is “instrumented” to detect intrusion and exfiltration of data.

However with the points and other problems in the protocol, you get to know what the random number is generating and thus with a little work have the all important keys.

Thus if you are one of the FiveEyes with a “collect it all” mentality and the ability to hover it all up well upstream of the site under attack. No matter what instrumentation the person under attack has they won’t see anything as the attack is now being carried out outside of what they can see.

Worse if the attacker has previously copied all the traffic, then they can see traffic from before the point the points were exfiltrated.

It’s the reason people like Nicholas Weaver are directly attributing it to a nation state. Such as the US UK Israel etc.

L. W. Smiley • December 22, 2015 1:26 PM

According to Wired http://www.wired.com/2015/12/researchers-solve-the-juniper-mystery-and-they-say-its-partially-the-nsas-fault/ the second rng, ANSI X.9.31, is never used, just dual_ec. Further the current patch hasn’t fixed this just replacing the Q point to what it was leaving the possibility that Juniper could generate a corresponding secret key e to go with Q giving Juniper a backdoor. The researchers in the Wired article suggest that all this coul be fixed with a single line of code which they haven’t done yet.

Scrattæe • December 22, 2015 6:26 PM

A lot of sources seem to imply that the orignal (and now restored) Q chosen by Juniper was probably generated maliciously as well, to allow someone (Juniper or a client) to monitor the traffic.

But, assuming that someone was actually using an e based on the Q chosen by Juniper to collect and decrypt VPN traffic, shouldn’t that same someone notice the “unauthorized” change of Q, since their e would no longer allow them to decrypt traffic? Why, then, did it take so long for Juniper to detect that the Q had been changed?

steven • December 22, 2015 7:22 PM

@Scrattæe, who really bothers to patch these things after deploying them? As that slowwwly growing portion of users applies patches, it would still take time, to realise why that ‘backdoor zero’ no longer works against specific targets (as you may not even know what firmware version they’re running); to get some Juniper insider to fix it for you (perhaps covertly); and find some compelling reason for everyone to apply the patch restoring the original Q. The SSH backdoor gives that compelling reason everyone must patch now, and in the very same update Juniper restored the original Q. As a customer, you may either run an insecure device or restore the original Q.

To save face, Juniper really must get rid of Dual EC DRBG now.

I speculate (actually, wish) that whoever changed the Q – ‘unauthorised’ – may have done so with the intention of locking the NSA out, rather than letting someone else in. I can’t think of a better protest against a government-mandated backdoor, than by sneakily closing it, and leading people to discover and expose it.

Coyne Tibbets • December 24, 2015 2:31 AM

One of the problems with that “accidentally disabled” loop that has been raised, is the question of how this could pass code review (much less debugging).

It occurs to me that perhaps the loop is window dressing…that it was never intended to work. It presumably was added in response to someone who raised a concern about Dual_EC, and so Juniper would need to show that party that the problem was addressed.

A very obvious loop that addresses the concern…disabled by a very well hidden modification to a local scope field…would be the perfect window dressing to convince a concerned customer that, “See? Everything is fine now.” While actually doing nothing, so that the same Dual_EC back door continues to be present.

Who? • December 24, 2015 5:03 AM

More on Juniper’s hack: https://theintercept.com/2015/12/23/juniper-firewalls-successfully-targeted-by-nsa-and-gchq/

The author of the 2011 GCHQ document, an NSA employee who was working with GCHQ as part of an “Access Strategy Team,” takes a similarly adversarial view of encryption, referring to Juniper as a “threat” and a “target” because it provides technology to protect data from eavesdropping.

It seems Juniper Networks has been a target for a long time… wish to know if OpenBSD is classified the same way.

me • December 24, 2015 12:18 PM

Appelbaum dropped this one today.. “Juniper appears to use Oakley group 1 for SSH (!) – so passive decrypt for that is done.”

Previously he dropped that “caprios” is the name of the SSH decrypt db.

SSH on any of these vendor supplied products is a joke. If they don’t get you on the key-exchange, they’ll get you on key generation, DHE with known moduli or AES-CBC. muahaha.

Why • December 24, 2015 4:38 PM

Of course $1 is a target, everything is a target. the #Eyes themselves are also a target as is their (subordinate) governments. A target for themselves I mean, not only for others.

Everything being a target is not the end-game, it is the preconditional assumption of all mass surveillance: the conceptual beginning, the dream/nightmare of omniscience & omnipotence. It cannot be any other way but people want to deny the obvious in desperate vain hope of avoiding the realization that future decades or centuries of waste and destruction will be for nothing, for no gains at all, not even insight or learning or history’s lessons (because look how fast we forget those each time, not that anyone ever seems to learn much in the first place).

For the NSA or whatever other brand of the powers-that-be to not spy on “themselves” never mind other departments etc. would be a logical fallacy.

When there is no trust trusting yourself is also a fallacy. Some obviously already know and the rest will have to learn the hard way.

If we’re lucky this will “stop” due to some “magical” reason (take your pick; $deity, aliens, AI, civil rights movements, laws (LOL) etc.) when the world (and primarily the previous 1st world) is the 21st or 22nd century equivalent of 1945 Dresden and Hiroshima. If we’re unlucky the technology and science has improved and will continue to improve enough to survive that and it won’t ever stop.

That’s about as far down the rabbit hole as I can see, I can only speculate on what’s further down below (there could be something there but I’m never going to write about that possibilities in detail: contexts that makes the insanity of it all “make sense” as unavoidable necessities, in which case the only way to win is to lose faster).

abbadabba • December 29, 2015 9:14 AM

We need to keep in mind that what we shouldn’t do unto ourselves will be done for NSA, FBI and our county sheriffs by GCHQ, right Watson? Vise for vise, Versa. What could be worsa? We’re British, again. Roll over, VanWinkle, and wake me when the thunder bolts, like anyone can sleep through that hellfire, A-10.

Sasparilla • January 12, 2016 9:52 AM

Two things on reflection. Notice the lack of Official protest and “foul” being cried here? Nothing from the top of Juniper and nothing from the Administration saying the U.S. was blahblahblah’d by whomever? Weird, Eh? This makes it all look as if it was almost surely done by Juniper leadership in willing partnership with the NSA and the beans got spilled (accidentally perhaps?.

Wired had a follow up article that was fabulous so I had to add it here. They added a timeline for things. Duel_EC was demonstrated as compromised in 2007 at a cryptography conference. Juniper added it to the firmware at the end of 2008 / early 2009 & started using it even though their existing code was secure. Now just adding Duel_EC wouldn’t be enough they needed to make 3 other changes the most damming of which was the change from a 20 byte nonce (infeasible to attack the encryption with Duel_EC) to a 32 byte one (required to attack the encryption in fractions of a second), but as Duel_EC only outputs 30 bytes at a time, they had to rewrite their code to run Duel_EC twice to get the 32 bytes of output). Here’s the article:

http://www.wired.com/2016/01/new-discovery-around-juniper-backdoor-raises-more-questions-about-the-company/

From the article: ““The key point here is that if any one of the four listed changes in [firmware version] 6.2.0r1 had not happened, then the VPN traffic could not be passively decrypted…,” says Checkoway. “If this backdoor was not intentional, then, in my opinion, it’s an amazing coincidence.””

Seems like a 3 party audit of ScreenOS and Junos OS is warranted at this point as who knows what else is in there? Same for Cisco. Juniper and Cisco should move to Open Source OS and firmware models before the NSA destroys their businesses (if too much long term damage hasn’t already been done).

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.