6 ms·
On the Juniper backdoor
- baby 11y ago* It seems like there was already a backdoor in place with the Dual EC in place. That Jupiner could use. * Or maybe they had to use Dual EC because of government pressure but they changed the EC keypair to fuck with the NSA. NSA is not happy and changed it back. * Or ... In any case, what is clear is that a backdoored PRNG (Dual EC) was implemented behind a "fake" PRNG. Someone knew that, and thus changed the EC keypair of the backdoored PRNG. This is very shady.
- l3m0ndr0p 11y agoHigher Management @juniper are well aware of these back doors. They will deny it, which is what they have been told to do by our government. There are many more devices that have this type of back door.
- jerf 11y agoWhy are you sure this was "our" government? (For any particular value of "our".)
- tyho 11y agoHere is a wild theory. The constant Q was changed not by a hacker but by a good samaritan within Juniper to a safe value. Juniper responded with a patch that actually reintroduces the problem.
- nkurz 11y agoAn aspect I haven't seen discussed yet: Many people seem to presume that the custom value of Q used by Juniper was done so that either they or some confederate could passively decrypt communications. The existence of a pre-intrustion bug that leaked the required bytes to allow this would seem to point in this direction as well. But if someone was already making use of this backdoor, wouldn't they have quickly noticed if they lost access? And if this someone was Juniper (or someone allied with them) wouldn't they have been able to (perhaps silently) report and revert the change to regain access? It would seem that no one who knew the secret value objected to the change. And now Juniper is fixing the problem by reverting to the original non-standard value, avoiding the presumed NSA-compromised recommended value. But what's special about that original value that they go out of their way to return to it? If their goal was truly security, why not hash something "provably" secure, as suggested in the article? What's an interpretation of events where all these things make sense? The one that makes the most sense to me is to assume that the entity that made the "unsolicited" change to Q was the same as the one who knew the secret of the original, and they change was made because they wanted to restrict someone else's access. But this doesn't fit with the change back to the original, rather than to a new value.
- baby 11y agothe change back to the original value is just easy because they just need to revert a commit. There is nothing else to see here...
- tyho 11y agoPerhaps the backdoor v2, was not found in an internal code review as claimed. It might have been found after some three letter agency tried to use their dormant back door only to find it didn't work.
- fabian2k 11y agoAm I understanding this correctly, Juniper is simply setting the Dual-EC DRBG constants back to the values they chose themselves? So if they originally chose values that would create a backdoor, this backdoor would be accessible again? Ripping out Dual EC DRBG entirely seems to be the only sensible choice here.
- lagadu 11y agoYou are understanding it correctly, yes.
- tyho 11y agoOnly from the perspective of somebody who wants a secure Internet. Apparently Juniper do not fit in that category.
- x5n1 11y agoThere are probably users of this bug that would not be happy if Juniper all the sudden cut support to their paying customers utilizing the bug. It's a feature not a bug ;)
- ZoFreX 11y agoDefinitely. But this was a quick fix due to its nature. It's possible that they know their original values are good, and this is therefore the smallest change to quickly get this out of the hands of... whoever had it. Of course, I think we'd all like to see it ripped out entirely, but that is a larger change that would need some time and care taken over it. Hopefully this is what's going on...
- coldcode 11y agoAfter this revelation you wonder why anyone would use Juniper's products, given how inept they seem to be given how the code was written/tested. I bet people will go right on using them as if nothing happened. Sad.
- lovelearning 11y agoJuniper must be regretting their decision to reveal this vulnerability publicly instead of quietly combining the patch with other feature updates. It's turning out to be a PR disaster for them.
- baby 11y agoWhich is sad because this is exactly what we need, more transparency from these kind of companies.
- based2 11y agohttp://boingboing.net/2015/12/21/juniper-networks-backdoor-conf.html http://boingboing.net/2015/12/21/juniper-networks-backdoor-c...
- _yy 11y agoNo way out of this, really. Damned if you do and damned if you don't. At least they took the high road and admitted the backdoor right away.
- draw_down 11y agoYes, that would be my question as well.
- nly 11y agoTL;DR: It now looks possible that Juniper had a backdoor in place all along, before the 'unauthorized code' was even put in place, and, even if they didn't, their code quality and auditing process seems to have been in the toilet for years. The ball is in Junipers court now: to prove they are merely incompetent and not outright malicious.
- pmoriarty 11y agoFrom what I understand, ScreenOS wasn't even made by Juniper, but rather by a company which they bought. So I'm not convinced that the blame for this backdoor can be placed on Juniper's shoulders.
- nly 11y agoWas that part of the acquisition of NetScreen in 2004? Juniper acquired NetScreen in February...but Dual EC wasn't published as a draft until June of that year. This is new code. Even if it weren't, why would it be reasonable to allow critical cryptographic components to go unaudited for 8 years? If the analysis so far is correct, then a single independent test vector for the RNG should have caught this bug. One. Lousy. Test. Furthermore, the fact they discussed their use of DualEC in 2013, and then claimed their construct was secure, is proof they were aware of the danger and yet, apparently, they hadn't done anything to verify this. Hanlon's razor is going to condemn them one way or another here. Unless they can demonstrate extraordinary circumstances, then Juniper security products should be considered toxic.
- tptacek 11y agoThe likelihood of them ever having the cryptographic components of ScreenOS competently audited is very low. Most firms didn't even start getting basic software security assessments done until ~5 years ago, and almost nobody gets crypto reviews done (crypto reviews are nosebleed expensive, because only a tiny fraction of software security people can do them competently).
- 11y ago
- deleted 11y ago[deleted]
- makecheck 11y agoThe description of P and Q values as mere 32-bit constants makes it sound like any value would be feasible and that these would be easily selected. They actually hold the two chosen points on the elliptic curve. Also, since these are part of the public-domain knowledge of the system, it is reasonable to expect that the values might even be built into hardware in the field, etc. and not easily changed. It might be much more feasible to revert to an earlier value if the original value was already stored somewhere. The real problem with DualEC-PRNG is that if P and Q were somehow related, you wouldn't know this by looking at them and knowledge of the relationship would be restricted to the issuers (in the case of the "recommended" P and Q values, the NSA; in the case of Juniper, their own employees). The hidden relationship could be used to deduce the output of the generator and therefore deduce any keys based on the now-predictable values.
- fanf2 11y ago32 bytes, i.e. 256 bits, which is why the curve is called P256.
- tyho 11y agoThere is effectively no point applying the patch. All it does is take the backdoor away from unknown party A and give it back to unknown party B.
- 3JPLW 11y agoWell, it also fixes the other backdoor, which is accessible to parties A, B, and everyone else.
- myth_buster 11y agoI think this is probably the best case to point out the reason for avoiding backdoors in the system. The author put it more eloquently... The problem with cryptographic backdoors is not that they're the only way that an attacker can break intro our cryptographic systems. It's merely that _they're one of the best_. They take care of the hard work, the laying of plumbing and electrical wiring, so attackers can simply walk in and change the drapes.
- arca_vorago 11y agoWhat else do people expect on routers, firewalls and switches with closed source. Once again, the power of open-source is shown to be superior (a challenge and not always easy yes). I recently did a big network upgrade and I got so tired of hearing "Cisco/Juniper/$BIGNAME never got anyone fired." I spent a long time looking at all the options, the main issue with the open source ones is a lack of performance usually due to lack of asics/fpgas for encryption offloading. When it came down to it, I went with Ubiquiti and their fork of VyOS called EdgeOS. Runners up router OS's were VyOS, PFSense, IPfire, routing engines being Quagga, XORP, and Bird Internet routing daemon. The point is that open-source isn't an instant solution for these kinds of issues (code obfuscation, code review complexity, weakenesses in many-eyes theory) but it's still better than proprietary because at least you can fix it yourself if you please or at least someone else can. I am a huge proponent of open-sourcing as much as possible, even given it's higher resource investment (hiring *nix-beards) because it gives a company freedom to be more agile than standard proprietary systems and their licensing-by-a-thousand-cuts and lock-in style. Sometimes it doesn't make sense, and even as a FOSS proponent and a heavy GPLv3 supporter, I have to recognize sometimes that's not the best option either. I tend to still use Cisco on industrial controls, but it's mostly because of the service & support options, not because of Cisco's security. I just assume that just about every manufacturer based in the US has been NSL'ed and has backdoors in software & hardware... in the meantime, the solution for people like us is to push people like Juniper away from their old business model and force them into competing with FOSS. We can fix the software, but the hardware will be much more difficult. I have heard some interesting ideas on hardware checksumming lately though. Just my two cents at least. edit: Forgot to mention I am very fascinated by the networking features in DragonflyBSD, especially ipfw3, so if you haven't looked at it it's worth a peek. Also HAMMER2 is going to be awesome and is already on par with BTRFS and ZFS.
- jauer 11y agoA caution re: EdgeOS. The control plane is largely open source but the data plane uses closed-source kernel modules and closed/proprietary APIs to drive the Cavium Octeon network processor. They seem to be adopting more closed control plane in newer versions because there aren't any mature FOSS stacks for service provider oriented protocols (e.g. MPLS+VPLS+RSVP-TE+LDP+...). On the closed side there are a handful of vendors that provide control plane stacks for all that.
- anonbanker 11y agoThis is why all the networking equipment I have is littered with chinese backdoors, rather than the NSA/GCHQ ones.