8 ms·
NSA Helped British Spies Find Security Holes in Juniper Firewalls
- tptacek 11y agoWorth considering: every serious SIGINT agency probably had this capability against Netscreen VPNs. If you do a lot of network infiltration, these boxes are among the most useful targets; unlike routers running JunOS, the VPN concentrators have a large outside-the-packet-filter attack surface, and everyone runs them. It'd be surprising if NSA and GCHQ didn't have similarly powerful capabilities against all the current VPN products.
- epistasis 11y agoWhile I don't doubt that's true for closed-source products, would it also be true for open source products? I've heard that some methods of IPSec key exchange are compromised, but don't know details. Would it also be good to suspect OpenVPN's method of key exchange?
- jcrawfordor 11y agoThe vast majority of defects groups like intelligence agencies are exploiting are not going to be intentionally-placed backdoors - they're going to be typical vulnerabilities discovered the normal way, just by an organization with immense resources and no motivation to share. So the bottom-line is that it comes down to how much you trust the people that made the software. Is it a very high quality vendor? Is it a very high quality open-source project? The nice thing about open-source software is that you have a much better ability to evaluate this from the inside. Get on mailing lists, poke around trackers, and see how they usually deal with security disclosures. Do they even have a formal program to do so? I'm not sure that OpenVPN does, although a lot of distros watch that carefully.
- armitron 11y agoI'm sorry but this all comes to moot. For any opensource project of substantial size, you absolutely "have not a much better ability to evaluate this from the inside by getting on mailing list and trackers". All of that is irrelevant and a waste of time at best (at worst you're deluding yourself). Unless you're one of the few people on the planet who are good at auditing code for security vulnerabilities and devote the time to do it (or pay someone else to do the same), you have no stable basis to be making any assumptions as to the security status of a codebase. If this doesn't convince you, look at all the security-critical opensource projects that are riddled with security bugs. There is not a single one of them that hasn't been compromised time and time again. Sad but true.
- vox_mollis 11y agoSince it's now clear that "many eyes makes all bugs shallow" is patently false, the MO for said agencies to compromise OSS projects is to play the long game of making numerous benign commits, becoming trusted, then committing subtly compromised code. This would be much easier than compromising specific algorithms or KE protocols. Cheap, too. All it takes is plenty of patience.
- nyan4 11y ago> Since it's now clear that "many eyes makes all bugs shallow" is patently false "patently false". Proof needed, please, we have enough FUD.
- vox_mollis 11y agoGnuTLS and Heartbleed are pretty good examples for starters.
- MikeNomad 11y agoAnd for counter examples, I refer to the CERT emails I get regarding the latest software vulnerabilities and patches. Software security is unfortunately, a goal, not an absolute. The process is both fluid and dynamic, and the improvements iterative. To directly address the tenor of your comments, perhaps it would be better to say, "More eyes make bugs more shallow."
- nickpsecurity 11y agoOn contrary, the person making that claim needs to prove it's true or else we reject it as FUD against proprietary software. For a long time, the only software to resist prolonged pentesting by NSA were proprietary products certified to B3/A1 and Type 1 respectively. If NSA could hack them, they couldn't pass. Likewise, in safety, we've seen a number of high assurance systems fielded where every state (including failure) it could be in was known ahead of time. Some setups, like mainframes, hit 17-30 year uptime. All proprietary. Meanwhile, in OSS land, we have a steady stream of easily-prevented or detected defects that compromise security. Just like in most proprietary shops. Like proprietary, those OSS projects producing highly-secure stuff are done by great designers/coders with careful review and testing processes. The community-developed OSS hasn't reached the assurance of aforementioned proprietary systems or some in academia. Yet, highly correct or secure stuff seems equally rare in both types of development with proprietary having a bit more just because there were people paying professionals to build those. In theory, with free/cheap labor, OSS could eventually produce more but there's not enough interest. So, the endless stream of bugs in both closed and OSS software that are often really old disproves many eyes argument. It didn't work for even shallowest bugs consistently, much less deep ones. Software quality comes from people taking responsibility and putting time into QA, esp design/code review. OSS, shared-source proprietary, closed-source... always same requirement that gives quality.
- superuser2 11y agoTake a look at the CVEs. People find vulnerabilities in trusted open source projects all the time. The NSA hires a lot of smart people to spend all day looking for them and not share their findings with the Internet. No infiltration required.
- sitkack 11y agoKinda makes CERT a backwater. By the time it is public, you are already owned.
- adrtessier 11y ago> If you do a lot of network infiltration, these boxes are among the most useful targets; unlike routers running JunOS, the VPN concentrators have a large outside-the-packet-filter attack surface, and everyone runs them. Don't forget that the newer SRX-series VPN gateways are JunOS-based, and seem to be recommended by most Juniper sales people these days. There are certainly a ton of ScreenOS devices, but Juniper seems to have mostly deprecated them in their messaging. The primary Juniper security track certifications are JunOS-focused, and there's only a basic specialization available from them for ScreenOS. Juniper has mostly staked their future on JunOS from what I can tell.
- discardorama 11y agoI have a feeling that this is how these agencies skirt the law: agency X is not allowed to do "A", so it helps agency B do it, and share the findings with X. And vice versa. So the GCHQ spies on Americans willy-nilly, and the Americans spy on Brits, with full knowledge of each other.
- akerro 11y agoThat's how British government "doesn't use drons". They tell US to use drons to automatically bomb a target and kill hundreds of people, whole attack is organised by UK, but technically, it was done by US. In such case UK says in report they didn't kill anyone and US say they rented weapons.
- mattmanser 11y agoOur government does use drones? Has done for years.
- ck2 11y agoThis is like right out of a movie script and you are probably right. How did Google engineers put it? Oh yeah: https://plus.google.com/108799184931623330498/posts/SfYy8xbDWGG https://plus.google.com/108799184931623330498/posts/SfYy8xbD...
- venomsnake 11y agoThat has been open secret since the early 90s I think.
- samstave 11y agoThis is explicitly revealed in how the NSA is sharing info with Israel.
- deleted 11y ago[deleted]
- tptacek 11y agoDid The Intercept just publish a document about Juniper insecurity that they've had since 2013, or had they already published this? If they hadn't already published it, why not? It could have done some good before, but does no good now.
- striking 11y agoTo me, it almost seems like they haven't gotten to reading through all of the content of the archives that they have. But when there's a serious 0-day on the loose, it's not too difficult to Ctrl-F the archives to check if the NSA has anything to do with it.
- akerro 11y ago> the archives https://search.edwardsnowden.com/ https://search.edwardsnowden.com/ https://search.wikileaks.org https://search.wikileaks.org what more you have?
- BinaryIdiot 11y agoIt's my understanding that Snowden released the documents to two journalists (Glenn being one of them) on the grounds that they release "responsibly" meaning redact or don't publish names of under cover agents, etc. So unless I missed it the entire archive has never been released. Instead it's released in tiny bits and pieces by Glenn when it seems most appropriate. I'm assuming this archive is updated as pieces come in. For example I did not see this content within the archive. That's my understanding anyway; if I'm wrong please let me know :)
- akerro 11y agoYes, you're right, but what does it have to do with the link I posted?
- BinaryIdiot 11y agoHmm I thought you were implying that was everything. Oops.
- MichaelGG 11y ago> ...it does make clear that, like the unidentified parties behind those hacks, the agencies found ways to penetrate the “NetScreen” line of security products... It does? Sounds like this is a rather normal, expected, analysis. They're just reviewing products; probably they already had similar capabilities on IOS and wanted to make sure they could handle other targets or a shift in the market. This does not sound like getting backdoors placed, at all. I hate to be suspicious or cynical here, but is this just The Intercept being opportunistic? Is there any reason to relate this to the recent "unauthorized code" issues?
- revelation 11y agoPresumably you should direct your anger at the parties responsible for the occlusion and uncertainty here. If that fails, let's hate on Juniper. In any case, the linked PDF says that they do indeed have current exploitation capabilities for Juniper products and are working on more, even if it initially reads like a product brochure.
- MichaelGG 11y agoCurrent as of that time. Juniper's released a lot of security advisories since them. Though it's likely that they continue to find exploits. I'd be surprised if they don't have similar reports for any popular product, hardware or software, closed or open source.
- strictnein 11y agoI think they're trying hard to connect dots that aren't really connected. Glenn gets a little overzealous at times, in my opinion.
- BinaryIdiot 11y agoYou are completely correct. There isn't any correlation indicating that a security agency was behind the backdoors setup in their OS. Granted this could still be the case but there isn't any evidence, known to the public at least, that any security agency had a hand in creating the backdoors. The timing of this article is obviously done in order to capitalize on the recent Juniper news. I would suspect all security agencies to be looking at the security of al networking products that they can get a hand on.
- deleted 11y ago[deleted]
- nickpsecurity 11y agoNot sure about whether it's subversion or basic hacking. You should assume, though, that they might have hacks in any common product that can be used for a security bypass. Here's why: IT markets usually become oligopolies where a few players products are all over the place. Firewalls, routers, VPN's, OS's on desktop, OS's on mobile, net configuration, build systems... handfuls of implementations in each dominate in market share. So, rather than beating everything, you can focus on 0-days in a tiny few to beat almost everyone [that matters to a TLA]. Another side of this coin is that they'll add to their hitlist whatever they encounter the most. They probably run into Juniper firewalls all the time. So, it's higher priority. Using high-quality, but lower-priority-to-them, components reduces you risk of being hit by them. So, one of my recommendations is to build/use strong systems, use diverse components of good quality, and obscure the workings of both at the interface. They'll trip your alarms trying to figure out what you're using before they hack you.
- oroup 11y agoSeems like a prime opportunity for a class action lawsuit. Juniper was selling a class of products that categorically did not do what it claimed. What would be interesting is their method of defense. As was pointed out to me in an earlier thread, companies have legal immunity when assuring the intelligence community with their work.[1] But Juniper already claims that they do not assist third parties to compromise their products. So they would either need to change their statements or be ineligible for this defense.
- superuser2 11y agoThere is no indication that Juniper cooperated with the NSA or acted intentionally to compromise its products. All software has defects, and if bugs entitled customers to civil damages there would be 0 technology companies left alive. The standard is negligence, but the NSA is sophisticated enough to compromise designs that were not negligent.
- chei0aiV 11y agohttp://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html http://blog.cryptographyengineering.com/2015/12/on-juniper-b...
- phicoh 11y agoIt seems to me that having Dual_EC_DRBG in your code today is an extreme case of incompetence. Ideally, that should be enough to sue them out of business.
- biot 11y agoInteresting that Juniper merely claims that putting in a backdoor or working with others to do the same is against their policy. They seem to be avoiding saying a very simple, clear statement: "We never have and never will intentionally compromise the security of or put backdoors into our products, whether for ourselves or on behalf of a third party". That they can't come out and say that makes their claims suspect.
- jlgaddis 11y agoFrom TFA: > "As we’ve stated previously … it is against established Juniper policy to intentionally include ‘backdoors’ that would potentially compromise our products or put our customers at risk. Moreover, it is Juniper policy not to work with others to introduce vulnerabilities into our products.” -- Juniper
- biot 11y agoThat's the point I'm making, only I didn't bother to quote that exact paragraph myself. What you've quoted states only that their policy is against it; Juniper makes no claims that they've never violated their policy. It's like the NSA stating that collecting information on Americans is against their policy. I'm sure you can appreciate that there may be differences between policy and practice.
- chei0aiV 11y agoSeems they were lying when they said that: http://blog.cryptographyengineering.com/2015/12/on-juniper-backdoor.html http://blog.cryptographyengineering.com/2015/12/on-juniper-b...
- draw_down 11y agoWell, or they are spectacularly incompetent. We don't know which.
- deleted 11y ago[deleted]
- AndyMcConachie 11y agoSo how long has Glen Greenwald and others with access to the Snowden cache known about this? There was only one Snowden cache. If the document was provided by Snowden, did we hear about it earlier? Who has access to the Snowden cache now? Do we know?
- NN88 11y agoSo the US isn't supposed to gather intel now? IS that what you're saying Glenn?