I couldn’t tweet a better description than the headline for this piece: After SolarWinds breach, lawmakers ask NSA for help in cracking Juniper cold case. cyberscoop.com/nsa-juniper-ba…
For those who haven’t heard this story, the context here is back in 2015 hackers broke into the source code repository of Juniper’s NetScreen firewalls and introduced serious vulnerabilities. 1/
Everyone has heard of the SolarWinds supply chain attack, but almost nobody outside our little community remembers Juniper. We don’t even know who the ultimate victim was. And there’s a reason for that. 2/
The reason is simple: following the Juniper hack, the FBI and Juniper put a tight lid on everything. Nobody, including members of Congress, were able to get straight answers about who did it or what the target was. So it vanished from our collective memory. 3/
This has real consequences. To some extent our lack of preparedness for SolarWinds is a direct result of our government’s decision to pretend that the previous major supply-chain attacks didn’t happen. 4/
Why has the Juniper attack been buried by secrecy? There are two possible answers. One has to do with the nature of the hack, which very likely repurposed an existing backdoor in NetScreen firewalls. The other has to do with the ultimate target. 5/
Regarding the first, we know that Juniper included a *likely* crypto backdoor based on an NSA algorithm called Dual_EC_DRBG even before the hack. We also know that the attackers repurposed that code to use new public keys of their choosing. This is very embarrassing. 6/
(We know this because people on Twitter and co-authors of mine were able to reverse engineer the details from the published firmware images. See here for a nice explanation. dl.acm.org/doi/pdf/10.114…)
The second answer to “why was this buried” is much more speculative. It has to do with the identity of the actual target(s) that were attacked using the NetScreen vulnerabilities. We don’t know who they are, and they might be important. 8/
I continue to harbor the conspiracy theory that the Office of Personnel Management hack was in some way related to Juniper, based solely on the timing and some equipment manifests from that agency. I’m probably wrong, but that would be a hell of a reason to cover things up. 9/
The point here is that with attacks like this and a secrecy response, we’re screwed. Until we know what happened in these cases, we can’t learn from it. This makes us defenseless, and you can bet our adversaries prefer it that way. 10/
It’s as though the US government decided to react to Pearl Harbor by covering things up. You have to imagine that history would look a lot different. Hopefully we’ll stop making this mistake. //fin
• • •
Missing some Tweet in this thread? You can try to
force a refresh
My students @maxzks and Tushar Jois spent most of the summer going through every piece of public documentation, forensics report, and legal document we could find to figure out how police were “breaking phone encryption”. 1/
This was prompted by a claim from someone knowledgeable, who claimed that forensics companies no longer had the ability to break the Apple Secure Enclave Processor, which would make it very hard to crack the password of a locked, recent iPhone. 2/
We wrote an enormous report about what we found, which we’ll release after the holidays. The TL;DR is kind of depressing:
Authorities don’t need to break phone encryption in most cases, because modern phone encryption sort of sucks. 3/
Stories like this remind me that people in the Infosec community routinely make and sell exploits to these nations. citizenlab.ca/2020/12/the-gr…
I’m honestly curious how conscientious security researchers justify selling these tools, knowing how likely it is that they’ll be used for applications like this one.
One of the interesting things about this story is how difficult it must be to instrument iOS devices to catch these 0-click exploits in action. Partly because Apple makes it difficult.
So the resolution explicitly calls for gaining “targeted access to encrypted data”, but we’re going to say that’s not a “backdoor in encryption”. Because we say things.
Sorry, @TechCrunch. The resolution may or may not be serious, but it’s not ambiguous. You either gain access to encrypted data or you don’t. techcrunch.com/2020/11/09/wha…
The problem with encryption backdoors isn’t solved by “proportionality” or having great laws that ensure the tech is only used in a targeted manner.
The problem with encryption backdoors is that to use them in a targeted way, you first need to create an encryption backdoor.
Not to pick on @SwiftOnSecurity here, but since Juniper and Dual EC are in the news, I think it’s worth revisiting the evidence that someone deliberately inserted Dual EC as a backdoor.
But short summary: Juniper included two random number generators in their NetScreen devices. One was documented. The other was undocumented. The undocumented one was Dual EC. 1/
New Reuters article on the NSA’s “new” policy around inserting backdoors into commercial encryption systems. A lot in here. reuters.com/article/us-usa…
Or rather, a lot *not* in here. After the disaster that was the 2015 Juniper hack (due to an NSA backdoor in Juniper’s VPN products being exploited by foreign hackers), the NSA has developed a set of new policies. But they won’t talk about them of course.
Oh look, here’s Juniper admitting to Congress that an NSA backdoor was exploited in their products. And the NSA writing a report on “lessons learned”. Which they then misplaced.