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.
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.
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.
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.
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?
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.
> 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.
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?
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.
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.
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.
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.
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.
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}.
- 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.