
On the Juniper backdoor - Perceptes
http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html
======
nkurz
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.

~~~
tyho
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.

~~~
ZoFreX
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?

~~~
sangnoir
> 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.

------
fabian2k
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.

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

~~~
x5n1
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 ;)

------
tyho
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.

~~~
_yy
But the login backdoor?

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

------
myth_buster
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.

------
makecheck
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.

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

------
nly
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.

~~~
pmoriarty
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.

~~~
nly
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.

~~~
tptacek
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).

~~~
count
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...

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

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

------
arca_vorago
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.

~~~
jauer
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.

~~~
arca_vorago
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.

------
baby
* 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.

------
coldcode
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.

~~~
lovelearning
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.

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

------
tyho
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.

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

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

------
l3m0ndr0p
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.

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

~~~
crosre
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.

~~~
psykovsky
That must have been a true banana republic...

