
A Systematic Analysis of the Juniper Dual EC Incident [pdf] - andreasley
https://www.cs.uic.edu/~s/papers/juniper2016/juniper2016.pdf
======
tetha
I gotta say, the combine subtlety of this vulnerability is impressive:

\- There is a config flag, which may or may not have a valid use. I'm not a
networker or security expert, I cannot tell.

\- That config flag in turn causes two random number generators to interact
via a global variable to cause a small off-by-one error. Furthermore, both
code pieces don't look strinkingly wrong, from a cursory glance by someone not
familiar with the code base. I've seen worse code being approved in a review.

\- This boundary error leaks internal state of the inner EC-based PRNG, which
allows an attacker with prior knowledge, sufficient computing capacity and
solid knowledge of math and crypto to get the state of the inner RNG

\- This information can be exfiltrated through both a complex queue/pool-
system and a complex handshaking protocol. Maybe I'm more familiar with PRNGs,
but the IKE part started to go over my head.

I've always acknowledged the idea of very subtle, deniable and complex
vulnerability introduction, both through cryptographic conditions, subtle code
and language issues and all of that. Software is hard and complex.

But this is an example that's both scary, very complex and close enough to
comprehension to be very, very scary without being vague. Thank you for the
analysis and the write-up.

~~~
Klathmon
I have a feeling you already know about it, but for others that really enjoy
reading these kinds of exploits, the "underhanded C contest"[0] is fantastic
reading material that will give you very similar feelings.

It's terrifying how even simple code can hide extremely bad exploits. Many of
the entries even follow every linter/compiler warning/best practice out there.

[0] [http://www.underhanded-c.org/](http://www.underhanded-c.org/)

------
okket
Abstract: [https://eprint.iacr.org/2016/376](https://eprint.iacr.org/2016/376)

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.

------
baby
Video:
[https://www.youtube.com/watch?v=JRneMj7LX8U&list=PLC86T-6ZTP...](https://www.youtube.com/watch?v=JRneMj7LX8U&list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=52m15s)

A summary of what happened back then:
[https://cryptologie.net/article/316/junipers-
backdoor/](https://cryptologie.net/article/316/junipers-backdoor/)

------
45h34jh53k4j
Why anyone would trust Juniper firewalls or VPN's after this incident is the
question.

Against the advice of the cryptographer community, they implemented a known
backdoored algorithm in 2008, and then let that backdoor be usurped by unknown
attackers until discovery in 2015.

Every piece of code released by Juniper should now be questioned for back
doors.

------
lifeisstillgood
Can anyone with more knowledge than me comment?

This seems to be "The NSA (?history of elliptic curve hackery) added code to
enable them to snoop on VPNs running on Juniper routers and juniper think they
fixed it but didn't"

Are the routers now locked down? Will we ever know? How on earth did someone
add to their binary?

Is there a bigger picture here?

~~~
slackingoff2017
I think the biggest implication is how far they're willing to go to compromise
commerical hardware. This could ruin Juniper, a large US company. It's insane
that the government allowed them to do this.

The first thing I think of is phone basebands. If they're hacking enterprise
firewalls I have to assume they've already exploited the baseband in the vast
majority of phones. It's the one place they can stick a software plant over
the airwaves.

I think it's time to call for open source basebands, anything else just isn't
safe anymore.

~~~
kbart
Open source baseband only won't be enough, there are plenty of CPUs/MCUs
capable of running backdoors/malware spread on any modern board (heck, even
battery controller often runs on a full fledged MCU). Until we have an open
hardware + software, we will never be safe from government and other well-
funded crooks.

~~~
jwfxpr
> Open source baseband only won't be enough,

Not sufficient, perhaps, but necessary. A 0-day in baseband firmware seems a
helluva lot more attractive a target than in a battery controller MCU.

~~~
ethbro
Exactly. Such is the entire point of a firewall.

If you don't have a _remotely_ exploitable vulnerability, it doesn't scale to
global panopticon levels.

------
slackingoff2017
Low effort comment, but I think it's hilarious how much the NSA has started to
look like a Bond villain.

Just waiting for the day we find out about their secret lair inside an extinct
volcano where they're breeding sharks with lasers attached to their heads.

~~~
tptacek
We don't know that it was NSA, and in fact it's a little unlikely that it is,
because NSA is the author of Dual_EC and the standard includes recommended
default values for Dual_EC's Q, which we can presume NSA knows the dlogs for.

The smoking gun for this backdoor was a modified Q, which NSA wouldn't have to
do, and which represents _truly spectacularly bad_ tradecraft, by drawing
attention to a backdoor NSA claims isn't a backdoor in a way that leaves
virtually no doubt that it's a backdoor.

~~~
pbsd
I don't think it was the NSA either, but do note that Juniper itself had
originally Q set to a different value than the recommended one, and then
_that_ value was modified.

~~~
tptacek
Right, the "original" code is also super shady! I like (but don't believe) the
story where the later backdoor was actually USG, but done to break some other
country's NOBUS backdoor.

------
dfc
I wonder what software did the layout for the article. I hope it was not
LaTeX. That first blockquote is really bizarre.

~~~
stevecheckoway
It was indeed LaTeX. The ACM format creates a 1" box at the bottom of the
first column which contains the copyright information. The copyright
information on the authors' version (yes, I see the typo in the document now)
doesn't take up much space so there's a lot of white space.

The block quote itself is just \begin{quote} ... \end{quote}.

The published version looks like this
[https://imgur.com/puBzzdZ](https://imgur.com/puBzzdZ)

~~~
adrianratnapala
Hmm, I was going to say it was LaTeX, and that for all it's strengths, it
always did strange things with boxes interacting with pagebreaks.

But there's nothing so bad that publisher's addon packages, and standards
can't make worse.

