A Systematic Analysis of the Juniper Dual EC Incident [pdf](cs.uic.edu)
cs.uic.edu
A Systematic Analysis of the Juniper Dual EC Incident [pdf]
https://www.cs.uic.edu/~s/papers/juniper2016/juniper2016.pdf
27 comments
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/
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/
Abstract: 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.
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.
Video: https://www.youtube.com/watch?v=JRneMj7LX8U&list=PLC86T-6ZTP...
A summary of what happened back then: https://cryptologie.net/article/316/junipers-backdoor/
A summary of what happened back then: https://cryptologie.net/article/316/junipers-backdoor/
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.
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.
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?
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?
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.
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.
> I think the biggest implication is how far they're willing to go to compromise commerical hardware.
This.
Phone basebands, the Intel ME[1], NICs, Windows, anything from Cisco; they all have to be considered broken.[1] With Linux, at least there is a public code history, but considering the value of the target, tricky code can't be ruled out, nor can attacks at the distribution/packaging layer.
Vernor Vinge wrote a fun book called _Deepness in the Sky_, which, among other things, explores some implications of untrustworthy computing.
[1] And plenty of things not on that list, and perhaps something on it isn't. But for some risk models, they have to be assumed broken.
This.
Phone basebands, the Intel ME[1], NICs, Windows, anything from Cisco; they all have to be considered broken.[1] With Linux, at least there is a public code history, but considering the value of the target, tricky code can't be ruled out, nor can attacks at the distribution/packaging layer.
Vernor Vinge wrote a fun book called _Deepness in the Sky_, which, among other things, explores some implications of untrustworthy computing.
[1] And plenty of things not on that list, and perhaps something on it isn't. But for some risk models, they have to be assumed broken.
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.
Let not the perfect be the enemy of the good though.
Every time I hear someone asking for some improvement in openness and security, someone jumps in to point out how something else will circumvent it. Fine -- but how is anything going to get done if we sit paralysed a proliferation of worries?
Every time I hear someone asking for some improvement in openness and security, someone jumps in to point out how something else will circumvent it. Fine -- but how is anything going to get done if we sit paralysed a proliferation of worries?
> 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.
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.
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.
If you don't have a remotely exploitable vulnerability, it doesn't scale to global panopticon levels.
>It's insane that the government allowed them to do this.
What do you mean by this? The statement seems to imply they had to ask for permission from someone other than themselves?
What do you mean by this? The statement seems to imply they had to ask for permission from someone other than themselves?
I think the implication is that after the technical staff came up with the proof of concept, the operation to actually deploy it probably got reviewed by a somewhat senior official charged with making policy. He's expressing more surprise that the policy maker deemed the operation in the best interests of the United States than that the technical staff came up with the idea.
Whoever authorized the operation decided it was worth the many millions of damage it could do to Juniper.
NSA backdoored Dual EC that is used by Juniper.
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.
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.
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.
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.
I think the NSA offered to "help" them implement Dual_EC since nobody was using it. That would explain the backdoor stopping the extra safety feature that avoided using it alone.
I have a suspicion that the NSA had access to their source at some point.
I have a suspicion that the NSA had access to their source at some point.
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.
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.
[deleted]
Let's not get crazy. Sharks?
Of course, it's Dolphins.
I wonder what software did the layout for the article. I hope it was not LaTeX. That first blockquote is really bizarre.
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
The block quote itself is just \begin{quote} ... \end{quote}.
The published version looks like this https://imgur.com/puBzzdZ
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.
But there's nothing so bad that publisher's addon packages, and standards can't make worse.
- 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.