NSA Helped British Spies Find Security Holes in Juniper Firewalls | Hacker News Reader

NSA Helped British Spies Find Security Holes in Juniper Firewalls

theintercept.com

189 pointsslasaus57 comments

I 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.

That'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.

Our government does use drones? Has done for years.

This 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/SfYy8xbD...

This is explicitly revealed in how the NSA is sharing info with Israel.

That has been open secret since the early 90s I think.

Worth 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.

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

While 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?

The 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.

I'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.

Take 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.

Kinda makes CERT a backwater. By the time it is public, you are already owned.

Since 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.

The threat is long proven and it's wise you consider it. The high assurance sector & CompSci demonstrated it repeatedly in pentests and evaluations going back to the 70's. Here's some stuff for you or anyone interested in the subversion threat.

Landmark work by Myer in 1980 fleshing it out http://csrc.nist.gov/publications/history/myer80.pdf

Demonstration of simplicity of it against NFS by Anderson http://www.dtic.mil/dtic/tr/fulltext/u2/a401762.pdf

Lack's use of one against Windows XP https://calhoun.nps.edu/bitstream/handle/10945/962/03Jun_Lac...

All the same group, Navy Postgraduate School, with some of the professors being founders of information security field. They never forget the old stuff that works. Always mention the old strategy, high-assurance, as a solution as it was only thing proven to work. People never learn, though. Hence, endless opportunities in new projects for 0-days and subversion. ;)

The "many eyes makes all bugs shallow" quote was never said in the context of security vulnerabilities, and I would argue that they are different in nature. Normally, a bug means that something that I want to work doesn't. Then I can fix it or report it.

When the bug is a security vulnerability (e.g. Hertbleed), then everything work as it should, I can log into all the servers I have access to and all the functionality I want is there. The difference is that someone else can get access to my system or get access to information they are not supposed to. You don't discover this by using the system, you have to actively be looking for vulnerabilities. This is quite different from other kinds of bugs.

To be fair, it's probably not "many eyes make all bugs shallow" which is necessarily false, but the implication that open source guarantees enough eyes to begin with.

Whether or not an open source project is popular, whether contributing looks good on a resume, the number of competent programmers in the relevant fields with time to spare, and even the aesthetic quality of the code probably have influence on how much attention it gets. A hip framework is bound to get much more attention than an old, horrifying to look at mess of C, even if the latter happens to be mission critical to the internet.

All bugs might be shallow, if the number of eyes scaled in proportion with the amount of code, and the number of languages remained constant. The problem might be that people simply assumed Linus' law to be axiomatic, which results in kind of a Someone Else's Problem field permeating the community, as well as an implicit trust in the security of FOSS code which might not necessarily be warranted.

> Since it's now clear that "many eyes makes all bugs shallow" is patently false

"patently false". Proof needed, please, we have enough FUD.

On 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.

Maybe a new OSS license is needed where the price of using the software is reviewing some code once in a while.

I broke it down from a security or auditing angle for all sides here:

https://www.schneier.com/blog/archives/2014/05/friday_squid_...

Review was fundamental. It would be costly and take talent. So, like you, I proposed something that was open source but not quite free. Not many in OSS want to discuss proprietary OSS options but I think it's a critical conversation as it could get better stuff on the market. Prior conversations here at least showed the term, open source, was highly loaded with the expectation of free distribution due to its history. So, I'll modify the essay and next discussion to use shared source.

Elaborated more on my concept for a hybrid here:

https://news.ycombinator.com/item?id=10500298

GnuTLS and Heartbleed are pretty good examples for starters.

And 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."

> the MO for said agencies to compromise OSS projects is to play the long game of making numerous benign commits

Are there examples of this actually happening— that is, a nominally trusted committer intentionally adding a backdoor to a widely used OSS project? If this is in fact "the MO for said agencies", then there should be several examples you can point to.

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

You 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.

> There isn't any correlation indicating that a security agency was behind the backdoors setup in their OS.

I am not so sure. There are strong indications pointing[1] at state actors.

[1] http://securityaffairs.co/wordpress/42971/hacking/juniper-sc...

As to what you're quoting, yes, it does. It seems likely that they found ways to penetrate NetScreen. At the end of the original top secret document:

> The vast majority of current Juniper exploits are against firewalls running the ScreenOS operating system.

This reads like a statement of fact. That they knew of multiple exploits against ScreenOS. Enough to use the term "vast majority". That doesn't mean the most recent backdoors are their work, but it does seem to imply that they found ways to penetrate NetScreen.

I think they're trying hard to connect dots that aren't really connected. Glenn gets a little overzealous at times, in my opinion.

Presumably 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.

Current 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.

Did 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.

To 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.

> the archives

https://search.edwardsnowden.com/ https://search.wikileaks.org

what more you have?

It'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 :)

http://cryptome.org/2013/11/snowden-tally.htm is one of the places trying to track Snowden document releases.

Yes, you're right, but what does it have to do with the link I posted?

Hmm I thought you were implying that was everything. Oops.

No, I'm just looking for more places like the ones I linked ;)

Searchable database of leaked documents that can be linked in flamewars ;)

Greenwald is still sitting on an estimated 90% of the original Snowden document cache.

It's quite likely that Juniper's security advisory was sufficient cause to release this from the cache.

per: https://cryptome.org/2013/11/snowden-tally.htm

>If they hadn't already published it, why not?

I must be naive in thinking that you just don't have a billionaire fund an organization to leak secrets in any timely fashion ;)

I wonder if this document was supplied to Juniper first, leading to the security audit that found the 2 recent vulnerabilities. Now that there are press reports of government officials saying the NSA wasn't responsible for these 2 exploits, they publish proof that at the very least the NSA viewed Juniper as a target and likely had exploits of their own (or via GHCQ).

> If they hadn't already published it, why not? It could have done some good before, but does no good now.

My guess is that there are a lot of documents to go through, which will take years.

Are you advocating for a Wikileaks-style unreducted data dump (against Snowdens wishes), or you want Greenwald to "work faster"?

The document was created in documentcloud.org today.

They must have published it previously, because it's been floating around here for a couple of days. A slide just showing that they targeted Juniper products.

edit: First picture here: http://boingboing.net/2015/12/21/juniper-networks-backdoor-c...

Seems 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.

There 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.

http://blog.cryptographyengineering.com/2015/12/on-juniper-b...

It 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.

Not 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.

So 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?

So the US isn't supposed to gather intel now? IS that what you're saying Glenn?

Interesting 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.

From 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

Seems they were lying when they said that:

http://blog.cryptographyengineering.com/2015/12/on-juniper-b...

Well, or they are spectacularly incompetent. We don't know which.

That'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.

Reply on news.ycombinator.com