A Systematic Analysis of the Juniper Dual EC Incident [pdf]
cs.uic.edu
cs.uic.edu
- 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.
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.
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.
A summary of what happened back then: https://cryptologie.net/article/316/junipers-backdoor/
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.
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?
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.
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.
If you don't have a remotely exploitable vulnerability, it doesn't scale to global panopticon levels.
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?
What do you mean by this? The statement seems to imply they had to ask for permission from someone other than themselves?
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.
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.
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 have a suspicion that the NSA had access to their source at some point.
The block quote itself is just \begin{quote} ... \end{quote}.
The published version looks like this https://imgur.com/puBzzdZ
But there's nothing so bad that publisher's addon packages, and standards can't make worse.