Live data from Hacker News

Juniper breach mystery starts to clear with new details on hackers and U.S. role

bloomberg.com

61–70 of 180 posts

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#61

Bloomberg at the frontline of "having no idea how anything works at all". When the NSA designed DEC, they primed it with constants, that you'd need to know to break the encryption with low effort. Somebody discovered that and made it known publicly. So now before the rumors evolve into actual security engineers looking into it, the NSA creates a scapegoat APT, that "altered" some "code" at Juniper. Of course nobody f…

Indeed, like this one

https://www.bloomberg.com/news/features/2018-10-04/the-big-h...

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#62
post #40
post #7

How many more back-doors like that are out there that are not in public domain yet? And can we trust standard committees who, funded by public, put back doors in encryption and weaken security of public services?

No, you can't trust NIST on security. They've certified algorithms they must have known were deliberately weakened in every generation: DES in the 1970s, the Clipper chip in the 80s, "export-grade" RSA in the 90s, and broken RNGs in the 2000s. The deliberate weakening generally comes from the NSA, but NIST is required to work with them on security standards. A number of reputable security researchers claim that NIST'…

> DES in the 1970s

To clarify: the deliberate weakening for DES was literally reducing the key size. There was also some suspicious behaviour with the S-boxes, but that turned out not to be a attack. Sadly, but unsurpisingly, it's not as simple as "Do the oppposite of what the nation state adversary recommends.", although these days independent research is doing well enough that "Ignore them[0] unless they have a non-'trust us' justification." is a adequate policy.

0: for crypto design advice; obviously they're still a attacker and you need to deal with that

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#64

Earlier quoted context omitted.

Open- and FreeBSD deserve more usage

Well, JunOS is FreeBSD -- the magic is in their proprietary hardware. I'm not aware of open/whitebox solutions that can compete

Yes and no TBH.

Some Juniper gear emulated the IP2 forwarding asics in software, its fairly decent for what it is. All of the packet inspection stuff runs inside of FreeBSD. The new vSRX is all software and uses commodity cpu power for everything.

For raw speed, pfsense does a really good job on the low end of things but doesn't offer a lot of the inspection/IPS features that JunOS has. Arguably few people actually need IPS anyways.

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#65
post #51

Question- wouldn’t the change made by APT5 have been eventually obvious to whoever was originally using the back door? It would stop working for whoever expected the original value to be used, right? How did that go undetected for years?

Optimistic theory: it really was just for emergencies and was not in active use. Pessimistic theory: the NSA had already moved on to bigger and better exploits, but couldn't be bothered to tidy up.

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#66

The Pulse Secure exposure is pretty scary. If you have to comply with stupid Federal security requirements, Pulse and Cisco are pretty much the main players. Pulse is a steaming turd without back doors.

Yeah, the spin out lowered the product quality for sure.

Pulse is a winner from a UX standpoint, its "ok" from an admin/operational perspective but its not great. There was a while when some simple netconf commands would crash Pulse. I brought this up at a BAJUG meeting and the engineers there said "yeaaaah, don't use netconf".

AFAIK Pulse is still based on the old Neoteris codebase so who knows what else is still in there...

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#67

For its first 50 years or so NSA had a dual mission: protect the US from spying while spying on others. But these last 20 years they've undermined that first mission. They've now attacked and weakened American technology so many times that you'd be crazy to trust anything the NSA offers to make you more secure. It doesn't help when they lose control of their own hacking tools igniting a major expansion in ransomware.…

You are correct, and the transition point was 9/11. Before that the NSA was doing good work shoring up our digital infrastructure, as well as working with the FBI to go after international crime syndicates. I wish we could get back to that.

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#68
post #3

This is ground breaking. The NSA made Juniper use a backdoored algorithm, and a foreign adversary hacked into Juniper and changed the backdoor key (essentially). That's surreal.

And if you think they only strong-armed Juniper into doing this, I've got seaside real estate in Nevada to show you. AT LEAST Cisco should be considered compromised as well.

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#69
post #11
post #6

This is a great example of why more operators should adopt white box solutions.

It would be interesting to see a refreshed view of what products white-box is able to replace. I recall that Juniper and Cisco were hard to replace for some products because the performance edge was in proprietary ASICs that aren't available to white box builders. I suspect that CPU improvements and things like user-space networking (DPDK and friends) might have closed the gap some, but I haven't seen any recent anal…

The main leap for whitebox is AES-NI for SSL/TLS offload.

Nobody is really using DPDK/NETMAP in OSS products from what I can tell.

Netgate is doing TNSR, but its not open source: https://www.netgate.com/tnsr-applications/edge-routing

Re: Juniper breach mystery starts to clear with new details on hackers and U.S. role

#70
Wikipedia already said that Dual EC DRBG is shitty in November 2007: https://en.wikipedia.org/w/index.php?title=Dual_EC_DRBG&oldi... (article from 16. November 2007)

Whoever integrated this into their products after November 2007 is either incompetent or was bribed by the NSA.

Post reply on HN