Juniper breach mystery starts to clear with new details on hackers and U.S. role
bloomberg.com
bloomberg.com
Just wanted to acknowledge how brilliant that is. They could have made any other code change, but it was genius using NSA's own backdoor.
NSA advocated for that backdoor to be included in the standards. The US government then would be embarrassed and would want to cover up any issues related to it, including the fact that it was taken over by someone else!
Gotta wonder what that Monday morning meeting was like at the NSA when they realized what had happened.
Although there is no real skills gap between target school graduates and non-targets, this observation also serves the dual purpose of undermining the NSA’s perceived omnipotence.
Changing the Dual_EC backdoor's public key in shipping products would NOT have been NOBUS.
I feel more like, there’s a chance that by modifying an intentional backdoor it could be that it would go unnoticed because anyone at the NSA looking at it may skip over reviewing closely the part of the code that has the known backdoor in it.
Steal the other guy's stuff is no longer brilliant, it's not even surprising. It shouldn't have been surprising to "brilliant" people advocating back doors back in the day.
It is much more plausible that US companies didn't want to name and shame their biggest customer than the Chinese reverse engineering a cryptographic backdoor. This could have been supported by the general NSA/GCHQ efforts to ensure their activies are mis-attributed.
The "it was China" determination was made by Mandiant, a company that receives over half its revenue from the US government (per the 2014 FireEye M&A call).
Heck, Microsoft (Longhorn), SecureWorks (Platinum Colony), and Google (GOSSIPGIRL) are the only US companies that have even publicly assigned names to track US linked APT groups.
I didn't understand this statement, but it's intrigued me. What are the names for and how do they lead to tracking US-linked APT (advanced, persistent threat a.k.a state sponsored) groups and who's doing the tracking?
CrowdStrike has a naming scheme that includes implied classes for specific countries of origin. For example you may have heard of "FANCY BEAR" which is part of the BEAR family but different from the "COZY BEAR" group. Everyone in the industry knows FANCY BEAR is the Russian GRU and COZY BEAR is Russian SVR, but by using the code names nobody has to come out and say it publicly (or face the consequences of being wrong).
The three companies I named are the only US based ones I know of that have publicly assigned named to US based threat actors. Kaspersky Antivirus (a Russian company) calls them the "Equation Group" due to their love of complex encryption, and the Hungarian government calls them "Tilded Team." If you ask Mandiant or CrowdStrike - they don't exist.
With a smack of ham to it. I call it hot ham water.
It's very important to clarify that the NSA didn't make them use it. The DoD required it as terms for future contracts. Juniper grabbed the money in knowing exchange for putting their customers at risk.
Why does that distinction matter? It dramatically increases Juniper's culpability in the scheme. If the DoD had actually forced them to use it, that dramatically reduces Juniper's culpability.
If a company refuses, they are making a decision (more of a gamble). Corporations will almost universally sacrifice customer safety for profit. Especially when they are making a decision between "for sure losing opportunity money" and "maybe losing money after a court case".
That does not mean they aren't liable when things go bad.
Nacchio simply tried to use it as an excuse. He was just throwing shit against the wall and hoping that some of it stuck. Here's his claim: he was not in a rightful state of mind when he sold his shares because of problems with his son, and the imminent announcement of a number of government contracts.
Yeah sure, I know exactly what he means. Whenever I'm not in a "rightful state of mind" the way I cope with it is to dump company stock that I'm restricted from selling. /s
Nacchio was nothing but a greedy scumbag, and he went to Federal prison because of it.
The Wikipedia article says, as do other accounts, that beam splitters were used to tap into fiber optic lines. That might in fact be how it was done, but I do not think that was necessary.
IIRC, Juniper core routers were (uniquely, at the time?) capable of duplicating traffic on a NIC to another NIC without performance impact on capacity as a whole. This would have made them particularly suitable for mass surveillance that would not show up in network management metrics.
“We want you to backdoor your product for ‘National Security’ and if you do, we’ll buy many millions of dollars worth of your gear.”
What doesn’t make sense about that?
It doesn't absolve the NSA of any guilt here either, but this is not a helpless Juniper giving in due to full weight and power of the government.
No, I'm not being serious. Obviously what dheera is referring to is not software vs hardware but rather what hardware is affected. To comment that it's the hardware that is running the software that is infected is hardly useful.
You can argue that is was a software problem, not a hardware problem. This is wrong. It was a human problem. The humans involved span the software and hardware and more across all models.
No, that's expected behavior and will eventually happen approaching the limit of 100% of the time.
Even worse, a backdoor is often a greater security risk than normal authorization because the backdoor can often access all the data, not just a single user's data.
In short, if you are in government, do not ask for backdoors, if you are in the private sector do not make backdoors. Backdoors are a flawed idea that leads to very bad things for everyone (private sector losses hit government in the pocketbook, too).
A backdoor rekey attack, if it lets the attacker gain a foothold that allows them continued access after the attack is detected. That is really bad!
Do you really need it explained why that's far fetched? I'm going to let you think on that a bit longer. It should have kicked in by now.
It was a game of telephone gone horribly wrong, and Bloomberg's reputation is shot since they have refused to retract it.
This isn't a true statement, if strictly read--there are many techniques to hide undocumented components on boards, and covering all of them requires more than just a pass under a SEM. There's a fun talk that goes over a lot of them here: https://www.youtube.com/watch?v=RqQhWitJ1As
Hope this sort of thing keeps happening. I want more concrete examples to cite when people defend this stupidity. I want the governments of the world to be too embarrassed to talk about cryptography ever again, least of all demand backdoors into private infrastructure.
They're too far gone if they still believe "if you have nothing to hide, you have nothing to fear" so openly.
I don't think America can ever recover from this breach of trust. Maybe NSA just needs to be shut down entirely. Or at least redefined explicitly as an adversarial agency to everyone.
Yeah, like introducing the Clipper chip!
You'd also be crazy to trust anything made by American gear vendors. This is not the only instance of this, just one of the ones for which FVEY got caught.
Is non-US gear also compromised? Yeah, probably. But the PLA and the GRU can't physically confine you to an 8x8 steel cage on trumped-up charges predicated on the data they exfil from your network.
Your best bet is to buy gear from countries either not-friendly or actively hostile to the country you're in. Sure, you're probably pwned, but they're not sending a SWAT team in an MRAP to shoot your dog, either.
Actually they can, and with less legal recourse for you than in the US. It just depends on where in the world you happen to be when they decide they want you.
In any country, you'll end up in a steel cage regardless of whether you bought your computer or software from the KGB, NSA, or a homemade kit in a bazaar in Nicaragua made by a kid from Chile.
The NSA's Backdoor in Dual EC - https://news.ycombinator.com/item?id=28404219 - Sept 2021 (87 comments)
And can we trust standard committees who, funded by public, put back doors in encryption and weaken security of public services?
What you have to ask, is why is certain software proprietary? Most of it is innocent, but sometimes it's closed for evil reasons.
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's misdeeds were all unintentional and they've learned their lesson and there won't be any more backdoors. Perhaps. Ultimately they serve the US administration, so in the long term it depends on whether future administrations actually want everyone to have unbreakable cryptography. Doesn't seem like a safe thing to count on.
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
In 1975 brute-forcing of 56-bit keys was a NOBUS capability.
A lot of this weakening of ciphers was US government policy at the time: crypto was considered only to have military applications so in the same way foreign countries don't get the full US-edition fighter jet, they also didn't get the full crypto.
DualEC was a mess, no doubt, and should never have been standardized. I'm guessing they were railroaded by NSA. What is bizarre is that everyone knew it sucked. Not only the backdoor potential but also that it was slow. In fact the backdoor was even patented: https://worldwide.espacenet.com/publicationDetails/biblio?CC... which is my personal favorite part of the saga.
So while DualEC was a mess and the export policy was disliked, generally speaking the NIST process for standardising things is widely regarded.
Of course that does not mean you should trust them blindly, but examine the evidence. AES, SHA3, the lightweight crypto competition and the pqc process will all produce ciphers from largely non-US scientists and there are detailed discussions on the forums and at the workshops.
Of course if they decide to shut down these forums for discussion or ignore community consensus then there are definitely reasons to worry.
We were just using it wrong, it's a backup tool, not an encryption standard. ;-)
[1] US2007189527, abstract: https://news.ycombinator.com/reply?id=28427331&goto=item%3Fi...
Note that when parent says "you can't trust NIST" and you counter with something along the lines of "that's unfair... NIST acts untrustworthy/knowingly recommends subpar options because of NSA", it doesn't really counter what is being said.
If NIST decisions are based mostly on "whatever the NSA tells them to do", rather than the actual technical merits of the things they recommend, then... yes, they are generally not worthy of trust (blind or otherwise), because you'll always have to double-check their statements against other sources (e.g. your own knowledge, expert cryptographers, etc.).
Fool me once, shame on you; fool me twice, shame on me.
That's the problem of being untrustworthy once in a while... it's easier to lose your reputation than to regain it.
As it is... if you use anything recommended by NIST without first checking with the actual trustworthy community of researchers, you're asking for it.
TL;DR: Trying to justify why the NIST is seen as untrustworthy (or acts as such) does not change the fact that it is seen as untrustworthy by many people (and, as far as I can tell, fairly so).
I'd like to be able to perform SAST scans and code review on all software that protects my enclaves.
Starting to think “slippery slope” worries are unfalsifiable, because there is no standard for admitting that the precedent already occurred and the worst scenario already happened.
Oh yeah, and unfalsifiable things are illegitimate to me
The key word you correctly used is OPPORTUNITY.
I like smaller localized governance, but would not be opposed at all to a federal subsidized program for security bugs and open source development of algorithms and code for commonly required tasks.
Plus it's also extremely difficult to make underhanded changes to magic numbers if the source code is public.
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/3mVe...
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4baO...
Your best bet is multiple layers of defense. It may sound ridiculous, but don't use just one VPN/firewall. Make your adversaries compromise multiple vendors. Encrypt several times. That's what the actual DoD does and why the NSA probably doesn't even care. And, of course, the really important information is classified and never hits a publicly reachable network at all, so compromising the supply chain doesn't even help. As a private organization, you probably don't have the option to build an entirely separate network that doesn't touch the Internet and then protect the ingress/egress nodes with your own private military, so I don't know what to tell you there.
Also, if anyone knows of a Soekris like alternative I'm all ears, what to do if my 6501 and my spare 6501 die.
Is PC Engines acceptable as an alternative? E.g. https://www.pcengines.ch/apu4d4.htm
It does have limitations, e.g. only 1 GHz clock speed.
The bigger problem for all manufacturers is the chip shortage. E.g. most of PC Engines stuff is "expected ~ 2022". But there may be some stock at their distributors. https://www.pcengines.ch/newshop.php?c=4
Edit: if you dig deeper you may also find hardware you didn't expect. E.g. at some point OpenBSD was able to run on some Ubiquiti hardware. I don't know if Ubiquiti still make products that can run OpenBSD. https://www.openbsd.org/octeon.html
I wonder if they were coerced into including it?
https://www.schneier.com/blog/archives/2007/11/the_strange_s...
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
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...
In my opinion, they jump to conclusion on insufficient circumstantial evidence. I have not forgotten the SuperMicro debacle.
In this article, they repeat the some jumping and aggrandizing on multiple fronts.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
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.
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 analysis.
Juniper's core routers have neat features in terms of redundancy. failing over a FPC (card with ASIC) to another routing engine(control plane) without downtime or packet flow impact is a big one. Performance might be there on the lower end (<40g), but there are a lot of features which require asics.
Another example is QoS/CoS without impacting performance or queues. These are the kind of things you cannot handle at the CPU without impacting traffic performance, which bites you when you are doing major traffic flows.
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
https://www.cisco.com/c/en/us/solutions/collateral/silicon-o...
In other merchant silicon, while not P4, Broadcom has offered their own proprietary programmability in Trident 3/4.
I think adoption has been slower more due to lack of relevant domain expertise in software as well as relative inability of pretty much anyone to properly model the impact of routing features on a production network than anything else.
P4 is being widely adopted at the NIC level.
Pretty much. Unless you have some remarkably top-notch people, this proposal is just security theatre. The chances you'll compromise yourself through an error in a complex area are much higher than the liklihood a sophisticated attacker will breach you.
Whoever integrated this into their products after November 2007 is either incompetent or was bribed by the NSA.
2. Tie up a commercial contract with this mode being made the default.
It’s just Apple CSAM all the way down.
So basically, it means that "appeasing a customer" is a very easy and cheap way to control engineers... From there on, realize that there's no security at all for those who are not able to make their own.
Now let's talk about ethics in the engineer's training...
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 finds out, who those APT are, because attribution is 1% more accurate than astrology.
Too bad they're doing the opposite of that nowadays...
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...