
Secret Code Found in Juniper's Firewalls Shows Risk of Government Backdoors - r721
http://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/
======
tptacek
Just a quick note that 'lawnchair_larry has me dead to rights on this one.

I conceded awhile ago that Dual EC was a crypto backdoor (before BULLRUN and
the antics that were uncovered with RSA and with the European standards, I had
suggested, as some other crypto people had, that Dual EC was too hamfisted and
obvious to be a crypto backdoor).

But I've maintained since then that virtually nobody uses Dual EC, so its
impact --- while clearly malign! --- is probably limited.

Nope. ScreenOS apparently (I'm not 100% sure, but that seems to be the way the
wind is blowing) uses it to key VPN connections!

FULLY CONCEDED. The immediate known practical impact of Dual EC is, if that's
true, enormous.

The weird thing about this particular backdoor is that the adversary seems to
have modified the Dual EC parameters. Dual EC is an RNG with an embedded
public key, where an adversary with the private key can "decrypt" the random
bytes it generates to recover its state and rewind/fast forward it. This
backdoor appears to swap out the public key, which is something NSA has no
interest in doing.

My money is that this is the work of GCHQ, the world's most unhinged signals
intelligence agency, and our partners in peace.

~~~
hackuser
Could someone provide background on the the Dual EC issue, and why this
announcement is probably more important for the Dual EC implications than for
Juniper's backdoor, as tptacek says below?

While I wish I was an uber-crypto-nerd, unfortunately I only have time to be
an occasional crypto geek.

EDIT: Here's a start, from another front page HN article: "Dual-EC was an NSA
effort to introduce a backdoored random number generator (RNG) that, given
knowledge of a secret key, allowed an attacker to observe output from the RNG
and then predict its future output."

~~~
periodontal
Basically, Dual EC is never something you'll choose willingly, given
alternatives (it's quite slow and has had a slight bias demonstrated). So no
one* did in practice. This made the backdoor almost a non-issue (so no
heartbleed-like panic to patch, etc.).

However, having it in the standard (since removed) is perfect for fallback-
like attacks or surreptitious changes (in the best case, your target has
already implemented and deployed your exploit code and all you have to do is
throw the switch to enable it!). That's what this is demonstrating (though
some of the details are still speculative).

* Exception being those paid or required to do so by NSA.

------
blisterpeanuts
_" I am shocked—shocked—to find that gambling is going on in here!"_

\--from "Casablanca"

I'd be shocked to learn that there are no back doors in routing equipment.
Having that kind of control is just too appealing to the most powerful players
-- the NSA, China, perhaps Russia.

One hopes that people who care about the privacy of their communications are
not relying on the routers for encryption. I would encrypt end-to-end. Even if
the spooks are capturing the data, let them work for their cleartext.

Of course, we have to use algorithms that aren't compromised, either.

Annoying and disturbing. And they can't claim it's needed to stop terrorism,
either. The U.S. anti-terrorism apparatus didn't spot an obviously dangerous
couple in San Bernardino, even after one of them posted jihadist goals on her
stream. They didn't stop the Tsarnaev brothers from bombing the Boston
Marathon even after the Russians phoned to warn us about them. Idiots.

~~~
pyvpx
I read from a reliable source I cannot immediately recall that she in fact did
not post anything jihadist or even inflammatory on any social media account of
hers.

are you repeating a convenient falsehood or am I? in other words -- do you
have a source that verified she in fact posted jihadist anything, anywhere?

~~~
jdp23
Excellent point. The whole episode is very instructive.

On Sunday the New York Times quoted "law enforcement sources" as saying that
she had made postings on her stream. The story got a huge amount of coverage
and even came up during Tuesday's Republican debate.

On Wednesday, FBI Director Comey described the reporting as "grabled" and
clarified that no, it was just private messages -- and the Times (and others)
rewrote their stories to reflect it. But you can't unring a bell; most
people's opinion, and even more importantly their emotional responses, are
based on the original story.

Erik Wemple covers this well in the Washington Post [1]

Times' "public editor" Margeret Sullivan's looks at it as well [2], noting
that two of the reporters also incorrectly reported that Hillary Clinton was
the target of a criminal investigation.

[1] [https://www.washingtonpost.com/blogs/erik-
wemple/wp/2015/12/...](https://www.washingtonpost.com/blogs/erik-
wemple/wp/2015/12/16/the-fbi-just-blasted-reporting-on-the-san-bernardino-
killings/)

[2] [http://publiceditor.blogs.nytimes.com/2015/12/18/new-york-
ti...](http://publiceditor.blogs.nytimes.com/2015/12/18/new-york-times-san-
bernardino-correction-margaret-sullivan-public-editor/)

~~~
kbenson
I wish we had something that tracked news articles and noted when they changed
without either an inline note about the change or an update at the end. It
would be like the snopes of news journalism, and we could get some really
interesting statistics from that with regard to the journalistic integrity of
different sources. There's a large population of people that could do with
some good evidence to force them to be more critical of certain news sources.

~~~
r721
This exists: [http://newsdiffs.org/](http://newsdiffs.org/)

~~~
kbenson
Awesome, thank you!

------
peterkelly
I like CNN's take on the story:

[http://edition.cnn.com/2015/12/18/politics/juniper-
networks-...](http://edition.cnn.com/2015/12/18/politics/juniper-networks-us-
government-security-hack/)

Obviously it must be either Russia or China - NSA couldn't _possibly_ be
responsible ;)

~~~
level09
It can't be NSA agents who caught intercepting network gear from Cisco Systems
as it was being shipped to a customer (as revealed by snowden) it is highly
unlikely they infected juniper networks as well.

</sarcasm>

~~~
rtpg
I don't disagree that they might have the intent to, but it's possible they
didn't have the capability to.

Much like the difference between forcing sites to hand over SSL certs and
breaking SSL, there's a gulf between compromising hardware that you have
physical access to and compromising the software stack at the source.

In this case I wouldn't be surprised if that turned out to be the narrative,
but the "NSA can accomplish anything" position is a narrative that plays into
their favor.

~~~
coldtea
> _Much like the difference between forcing sites to hand over SSL certs and
> breaking SSL, there 's a gulf between compromising hardware that you have
> physical access to and compromising the software stack at the source._

You know that they could have their own programmers working there, or just
approach, bribe or blackmail, an existing programmer to compromise the
software (e.g. one found with child porn on his HD).

------
kabdib
I'll bet you ten dollars there are more backdoors, better hidden than the ones
they found. Say, with Underhanded C style coding. An additional ten bucks says
that Cisco and the top handful of consumer appliances also contain such
backdoors.

I hope the folks at Juniper are checking their toolchains, build machines and
repositories for signs of similar attack. Of course, enough time has elapsed
that they may need to establish a cleanroom for their code. Hoo boy.

~~~
jacquesm
> I hope the folks at Juniper are checking their toolchains, build machines
> and repositories for signs of similar attack.

I hope they figure out who planted it there and that they change their
hiring/code review policies to make sure that such a thing can not happen
again. Firewalls should be tamper-proof to the point where they simply refuse
to operate at all if the code has been messed with after it leaves the
premises, the absence of such tamper proofing is already a problem and should
be taken quite serious.

~~~
kbenson
Which is DRM, right? Which is fine, but it needs to be DRM in control of the
owner, not the supplying company. There's all sorts of evils in the world to
worry about, so we shouldn't be too quick to get away from one that we run
into the arms of another. There are, not coincidentally, parallels with
terrorism and the security state.

~~~
kabdib
I would love an attestation system. For instance, the firewalls around a
store's credit card info (even if this data isn't stored, but tokenized, it's
still damned useful) should sing like a canary if their configuration or
firmware are hacked.

Attestation is sort of like DRM with policies that _you_ decide.

Note that many of these devices have significant complexity in hardware. Lots
of things that state-level actors can do to your hardware, on the order of:

\- see packet starting with a known signature

\- over-write the rest of that packet with interesting stuff, and transmit

Something at this level would be really hard to find.

------
hyperdunc
The honeymoon is over. The Internet is now a hostile environment. We cannot
assume good conduct from any party of reasonable size and should assume
deception from anything that isn't fully open source and vocal about it. It
sucks to assume the worst...

~~~
ageek123
It would appear that the "party of reasonable size" here is China or Russia,
not a corporation.

~~~
lifty
Can you please explain how you reached that conclusion? What made you exclude
US and UK?

~~~
dandrews
Parent is probably taking the CNN article at face value.

------
acd
This also highlights why it would be better to use opensource firewalls such
as Openbsd instead of proprietary ones!

If you care about your security then you need to be able to inspect the code
that protects your assets.

Distributed open source firewall vs propritary firewall with backdoors.

~~~
raesene9
Of course the idea that open source software in general, and firewalls in
specific are better than closed source ones relies on people actually having
the skills and time necessary to conduct a decent audit.

Some of the very large security bugs found in open source software which were
present in that code for years, indicate that this is not commonly done.

And that was just bugs as opposed to actual backdoors which would likely be
harder to find if inserted competently.

So whilst in theory you are correct, I'm not so sure you are in practice.

~~~
JeremyNT
Indeed, for those of us not taking the time (or lacking the expertise) to
audit code ourselves, this is all ultimately appeal to authority.

If anything, the advantages of open source here are more about open
_development_ processes and being able to know just who is the gate keeper. As
an example, if you use OpenBSD, you have reasonable assurances that Theo will
do a good job, because he has earned his reputation.

Juniper? Who really knows what goes on internally? How are people allocated
and shuffled around? It's a black box.

Ultimately I'd put more trust in OpenBSD than in Juniper because of this, but
I'm still making a leap of faith. And OpenBSD is an extreme example of how
much trust a project can earn; a vast majority of open source code is not held
to such scrutiny.

------
stickfigure
I'm confused. Are these accidental vulnerabilities or deliberate backdoors? If
deliberate, why is there speculation about who might have installed this
"secret code"? Do they have version control? Is there a specific human
attached to the relevant commits? Serious question.

~~~
andreyf
And a good one. They were definitely deliberate, but the other details are not
public.

~~~
jubes
If this wasn't an intentional backdoor it raises the question, what source
control methods were being used and are they secure? Has Juniper been
compromised on a larger scale?

~~~
andreyf
That's a good question, too. I'm sure people are asking it and many others
like it internally, a well.

On the outside, I think this is yet another reason to use git, which, if I
recall correctly, is designed to make attacks on commit history significantly
more difficult than they are with SVN and CVS.

------
huuu
It's sad but events like this one make me turn away from Internet.

I started using Signal because I don't want people seeing the messages I post.
But in the end it's only trust that makes me think Signal is safe to use.

A lot of people also trusted Juniper. But that trust is gone. And not only for
Juniper. What about other brands? We don't know.

~~~
mjs
You're still secure if you use https. If neither your computer nor the host
you're connecting to has been tampered with, then you're safe irrespective of
what's happening between.

~~~
toyg
Yeah, because illegitimate / spoofed certificates will never happen...

~~~
Ao7bei3s
With certificate transparency, at least we'll know about it - afterwards, at
least.

~~~
marcosdumay
Well, afterwards, if the attack stops (software does not need to stop) in a
timeframe short enough for your computer to no clear its history.

------
Buge
Wow that nation state is stupid.

They embedded the backdoor password right into it. Clearly they should have
embedded the hash of the password instead. Then it would be unbreakable and no
other party would be able to use the backdoor.

Hashing passwords is extremely basic security practice.

~~~
coldtea
> _They embedded the backdoor password right into it_

Or you know, that's just one obvious backdoor they put in, to divert from the
other 2-3 non-obvious they have.

~~~
Buge
But one thing the NSA likes to say is that the backdoors they insert are only
accessible to them, not to others. For example the DUAL_EC backdoor could only
be exploited by the NSA. With this backdoor, now China and everyday criminals
can also use it.

I see the benefit of inserting multiple backdoors. But none of them should be
vulnerable to rival nations.

~~~
coldtea
> _But one thing the NSA likes to say is that the backdoors they insert are
> only accessible to them, not to others._

Which is an empty statement when it comes to security principles. If you've
placed a backdoor (and some are blatantly obvious if you look for it, like
some SSL issues), then others can use it too. Most backdoors are not of the
"we have an encrypted password only we know" variety, but of the purposeful
hole to exploit.

> _I see the benefit of inserting multiple backdoors. But none of them should
> be vulnerable to rival nations._

Except if the idea is to monitor the local population, and you do not care
that much if others monitor them too.

------
blazespin
The big story here is not that Juniper is weak but rather that these types of
attacks are succeeding. If Juniper has fallen, god knows what else is
vulnerable.

------
hdmoore
If anyone is interested, you can find the unpacked firmware and some rough
diffs online at [https://github.com/hdm/juniper-
cve-2015-7755/](https://github.com/hdm/juniper-cve-2015-7755/)

------
acd
Some corporations will not know about the issue or ignore it and thus will get
hacked by the backdoor. Now this backdoor does not only benefit those who
implanted it, it will benefit the opposing side who can hack using it.

------
gtirloni
I think these is a good example for people that complained about OpenBSD
refusing to use cloud servers for their infrastructure. Point being security
at this level shouldn't be taken lightly. Juniper must have a ton of security
measures in place and they end up with this.

------
mtgx
Juniper is using Dual EC....are you kidding me? Now I have zero doubt this is
Juniper's fault because of its cooperation with NSA to keep backdoors in its
systems.

If I remember correctly even tptacek was claiming initially that "Dual EC is
not so bad...not that many companies use it anyway, because they would be
stupid to use a 1000x slower algorithm". Yeah, except some of the biggest
networking equipment makers in the world who do use it, and who sell products
to many other small and large companies, too. Quite a bit of an attack surface
for the NSA.

The point was always that Dual_EC should've _never_ become a NIST standard, no
matter how "bad it was and that _probably_ nobody would use it anyway". It was
made a standard for a reason by the NSA, to convince at least some of the big
companies to use it. And they succeeded in that.

We can only hope that the good people who work in standard bodies will never
allow something like that to happen again, because in the end backdoors always
end up being used for "evil", whether by the initial creators or by someone
else who finds them later.

~~~
tptacek
If you're going to use quotation marks when referring to something I said, you
should actually quote me, instead of making stuff up.

------
y04nn
Don't gouvernements can check the source code? like for Windows?

~~~
mcintyre1994
It's an interesting thought. If they checked and spotted this would they
report it to defend against the attacker that injected it, or would they just
pocket the master password and use it themselves?

~~~
Kristine1975
Maybe both: They found a second backdoor, reported one and kept the other.
This makes them trustworthy in the eyes of Juniper, while still netting them a
backdoor.

------
danso
I'm looking at Juniper's news page [1] and its Twitter feed [2]...it doesn't
give me a lot of confidence that this security breach or even its (apparently
inadequate) patch doesn't even a news item or a Tweet.

[1] [http://newsroom.juniper.net/](http://newsroom.juniper.net/)

[2]
[https://twitter.com/JuniperNetworks/with_replies](https://twitter.com/JuniperNetworks/with_replies)

~~~
jjp
Was discussed yesterday on this thread
[https://news.ycombinator.com/item?id=10754917](https://news.ycombinator.com/item?id=10754917)
which points to the proactive announcement Juniper made

~~~
SyneRyder
There's also [http://advisory.juniper.net/](http://advisory.juniper.net/) with
further details on each security notice.

