Hacker News new | comments | ask | show | jobs | submit login
On the Juniper backdoor (cryptographyengineering.com)
262 points by Perceptes on Dec 22, 2015 | hide | past | web | favorite | 48 comments

An aspect I haven't seen discussed yet:

Many people seem to presume that the custom value of Q used by Juniper was done so that either they or some confederate could passively decrypt communications. The existence of a pre-intrustion bug that leaked the required bytes to allow this would seem to point in this direction as well.

But if someone was already making use of this backdoor, wouldn't they have quickly noticed if they lost access? And if this someone was Juniper (or someone allied with them) wouldn't they have been able to (perhaps silently) report and revert the change to regain access? It would seem that no one who knew the secret value objected to the change.

And now Juniper is fixing the problem by reverting to the original non-standard value, avoiding the presumed NSA-compromised recommended value. But what's special about that original value that they go out of their way to return to it? If their goal was truly security, why not hash something "provably" secure, as suggested in the article?

What's an interpretation of events where all these things make sense? The one that makes the most sense to me is to assume that the entity that made the "unsolicited" change to Q was the same as the one who knew the secret of the original, and they change was made because they wanted to restrict someone else's access. But this doesn't fit with the change back to the original, rather than to a new value.

Perhaps an agency had a backdoor and then changed the lock to let another agency in without giving access to prior intercepts or even acknowledging that they had prior access?

Say NSA had a backdoor and then replaced it with one shared with GCHQ. In that scenario, the NSA has not lost any capability while GCHQ has gained capability and NSA has plausible deniability that they did have prior capability.

Perhaps the backdoor v2, was not found in an internal code review as claimed. It might have been found after some three letter agency tried to use their dormant back door only to find it didn't work.

But then surely they would have fixed it much more quietly? If this had been snuck into a regular patch with no fanfare, would we even be talking about it?

> If this had been snuck into a regular patch with no fanfare, would we even be talking about it?

Oh, yes - we would be talking about it, at some point in time. This was going to come out one way or the other (dissecting firmware updates is a veritable cottage industry). Juniper had to announce this in order to control the messaging and maintain trust, when it comes to security, trust is the foundation.

the change back to the original value is just easy because they just need to revert a commit. There is nothing else to see here...

Because changing a single line of code is hard?

reverting a commit = _ULTRA_ easy

generating a new P and Q correctly = how to elliptic curve?

Am I understanding this correctly, Juniper is simply setting the Dual-EC DRBG constants back to the values they chose themselves? So if they originally chose values that would create a backdoor, this backdoor would be accessible again?

Ripping out Dual EC DRBG entirely seems to be the only sensible choice here.

Definitely. But this was a quick fix due to its nature. It's possible that they know their original values are good, and this is therefore the smallest change to quickly get this out of the hands of... whoever had it. Of course, I think we'd all like to see it ripped out entirely, but that is a larger change that would need some time and care taken over it. Hopefully this is what's going on...

Only from the perspective of somebody who wants a secure Internet. Apparently Juniper do not fit in that category.

There are probably users of this bug that would not be happy if Juniper all the sudden cut support to their paying customers utilizing the bug.

It's a feature not a bug ;)

You are understanding it correctly, yes.

Here is a wild theory. The constant Q was changed not by a hacker but by a good samaritan within Juniper to a safe value. Juniper responded with a patch that actually reintroduces the problem.

That would be amazing. Has anyone checked that the new Q is not simply the SHA-256 of "Hack the Planet"?

But the login backdoor?

Could have been planted by a different party. It's wildly different in terms of sophistication.

planted at a different time, maybe by a different attacker.


I think this is probably the best case to point out the reason for avoiding backdoors in the system. The author put it more eloquently...

  The problem with cryptographic backdoors is not that they're the only way that
  an attacker can break intro our cryptographic systems. It's merely that _they're
  one of the best_. They take care of the hard work, the laying of plumbing and
  electrical wiring, so attackers can simply walk in and change the drapes.

The description of P and Q values as mere 32-bit constants makes it sound like any value would be feasible and that these would be easily selected. They actually hold the two chosen points on the elliptic curve.

Also, since these are part of the public-domain knowledge of the system, it is reasonable to expect that the values might even be built into hardware in the field, etc. and not easily changed. It might be much more feasible to revert to an earlier value if the original value was already stored somewhere.

The real problem with DualEC-PRNG is that if P and Q were somehow related, you wouldn't know this by looking at them and knowledge of the relationship would be restricted to the issuers (in the case of the "recommended" P and Q values, the NSA; in the case of Juniper, their own employees). The hidden relationship could be used to deduce the output of the generator and therefore deduce any keys based on the now-predictable values.

32 bytes, i.e. 256 bits, which is why the curve is called P256.

TL;DR: It now looks possible that Juniper had a backdoor in place all along, before the 'unauthorized code' was even put in place, and, even if they didn't, their code quality and auditing process seems to have been in the toilet for years.

The ball is in Junipers court now: to prove they are merely incompetent and not outright malicious.

> and not outright malicious.

That ship may have already sailed. They could've pulled a decent "honestly, we had no idea!" excuse pre-2013, when only most of the cryptography community assumed the Dual EC was both backdoored and useless for its intended purpose, but not after it was confirmed by Snowden's documents that the NSA backdoored Dual EC, and yet they continued to use it.

And now, when they found out a(nother) nation state was using it, their "fix" is to change the parameters again instead of burning it with fire. That's strike three.

From what I understand, ScreenOS wasn't even made by Juniper, but rather by a company which they bought.

So I'm not convinced that the blame for this backdoor can be placed on Juniper's shoulders.

Was that part of the acquisition of NetScreen in 2004? Juniper acquired NetScreen in February...but Dual EC wasn't published as a draft until June of that year. This is new code.

Even if it weren't, why would it be reasonable to allow critical cryptographic components to go unaudited for 8 years? If the analysis so far is correct, then a single independent test vector for the RNG should have caught this bug. One. Lousy. Test. Furthermore, the fact they discussed their use of DualEC in 2013, and then claimed their construct was secure, is proof they were aware of the danger and yet, apparently, they hadn't done anything to verify this.

Hanlon's razor is going to condemn them one way or another here. Unless they can demonstrate extraordinary circumstances, then Juniper security products should be considered toxic.

The likelihood of them ever having the cryptographic components of ScreenOS competently audited is very low.

Most firms didn't even start getting basic software security assessments done until ~5 years ago, and almost nobody gets crypto reviews done (crypto reviews are nosebleed expensive, because only a tiny fraction of software security people can do them competently).

This might be a stupid question, but if they're using their own values, wouldn't this have triggered issues during a FIPS assessment?

ScreenOS has been FIPS-140 validated a couple of times in the last 10 years...

No, you're allowed to use your own values.

Also: FIPS validation isn't particularly meaningful. It's not like a serious crypto assessment.

The article says:

> The attacker also replaced some test vectors.

What else do people expect on routers, firewalls and switches with closed source. Once again, the power of open-source is shown to be superior (a challenge and not always easy yes). I recently did a big network upgrade and I got so tired of hearing "Cisco/Juniper/$BIGNAME never got anyone fired."

I spent a long time looking at all the options, the main issue with the open source ones is a lack of performance usually due to lack of asics/fpgas for encryption offloading.

When it came down to it, I went with Ubiquiti and their fork of VyOS called EdgeOS. Runners up router OS's were VyOS, PFSense, IPfire, routing engines being Quagga, XORP, and Bird Internet routing daemon.

The point is that open-source isn't an instant solution for these kinds of issues (code obfuscation, code review complexity, weakenesses in many-eyes theory) but it's still better than proprietary because at least you can fix it yourself if you please or at least someone else can.

I am a huge proponent of open-sourcing as much as possible, even given it's higher resource investment (hiring *nix-beards) because it gives a company freedom to be more agile than standard proprietary systems and their licensing-by-a-thousand-cuts and lock-in style.

Sometimes it doesn't make sense, and even as a FOSS proponent and a heavy GPLv3 supporter, I have to recognize sometimes that's not the best option either. I tend to still use Cisco on industrial controls, but it's mostly because of the service & support options, not because of Cisco's security. I just assume that just about every manufacturer based in the US has been NSL'ed and has backdoors in software & hardware... in the meantime, the solution for people like us is to push people like Juniper away from their old business model and force them into competing with FOSS. We can fix the software, but the hardware will be much more difficult. I have heard some interesting ideas on hardware checksumming lately though.

Just my two cents at least.

edit: Forgot to mention I am very fascinated by the networking features in DragonflyBSD, especially ipfw3, so if you haven't looked at it it's worth a peek. Also HAMMER2 is going to be awesome and is already on par with BTRFS and ZFS.

A caution re: EdgeOS. The control plane is largely open source but the data plane uses closed-source kernel modules and closed/proprietary APIs to drive the Cavium Octeon network processor. They seem to be adopting more closed control plane in newer versions because there aren't any mature FOSS stacks for service provider oriented protocols (e.g. MPLS+VPLS+RSVP-TE+LDP+...). On the closed side there are a handful of vendors that provide control plane stacks for all that.

Yeah, I am aware of that, and frankly their track record for GPL compliance is shitty too, but it was a comprimise of sorts. It seems really sad to me that it's 2015 and we still don't have an allprotocol router/firewall thats enterprise ready and open source... maybe that's just my naively idealistic side speaking though.

Really tired of seeing this point raised every time there's a security flaw, proprietary platform takes an action people don't like, etc

It's an accurate point that needs to be made imho.

* It seems like there was already a backdoor in place with the Dual EC in place. That Jupiner could use.

* Or maybe they had to use Dual EC because of government pressure but they changed the EC keypair to fuck with the NSA. NSA is not happy and changed it back.

* Or ...

In any case, what is clear is that a backdoored PRNG (Dual EC) was implemented behind a "fake" PRNG.

Someone knew that, and thus changed the EC keypair of the backdoored PRNG.

This is very shady.

After this revelation you wonder why anyone would use Juniper's products, given how inept they seem to be given how the code was written/tested. I bet people will go right on using them as if nothing happened. Sad.

Juniper must be regretting their decision to reveal this vulnerability publicly instead of quietly combining the patch with other feature updates. It's turning out to be a PR disaster for them.

Which is sad because this is exactly what we need, more transparency from these kind of companies.

No way out of this, really. Damned if you do and damned if you don't.

At least they took the high road and admitted the backdoor right away.

Yes, that would be my question as well.

There is effectively no point applying the patch. All it does is take the backdoor away from unknown party A and give it back to unknown party B.

Well, it also fixes the other backdoor, which is accessible to parties A, B, and everyone else.

This is why all the networking equipment I have is littered with chinese backdoors, rather than the NSA/GCHQ ones.

Higher Management @juniper are well aware of these back doors. They will deny it, which is what they have been told to do by our government. There are many more devices that have this type of back door.

Why are you sure this was "our" government? (For any particular value of "our".)

Are you suggesting a foreign government fed banana glee and zesty leak to the NSA through Juniper instead? It's a fruity country obviously. That'd be even more perplexing.

That must have been a true banana republic...

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact