[HN Gopher] Juniper breach mystery starts to clear with new deta...
___________________________________________________________________
Juniper breach mystery starts to clear with new details on hackers
and U.S. role
Author : merrier
Score : 330 points
Date : 2021-09-05 16:07 UTC (6 hours ago)
(HTM) web link (www.bloomberg.com)
(TXT) w3m dump (www.bloomberg.com)
| jgalt212 wrote:
| never roll your own crypto, except maybe sometimes ...
| dannyw wrote:
| 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.
| Ansil849 wrote:
| This smacks way more of "well, what did you expect would
| happen?" than surrealism. If you introduce a vulnerability, it
| is nothing but hubris to think that you'll be the only one to
| leverage the vulnerability.
| kafkaIncarnate wrote:
| It's decades of antivirus style mindsets (we'll just clean up
| after), mixed with formerly being in law "enforcement" (we
| can't do anything until AFTER the law is broken), mixed with
| decades of "security by obscurity" and paranoid "hide and
| seek" culture, mixed with 9/11 vengeance, plus American
| exceptionalism.
|
| With a smack of ham to it. I call it hot ham water.
| vlovich123 wrote:
| Kind of, but my reading of it is that it was also a supply-
| side chain attack where they modified the constant that was
| used in the code before the binary was built. So at that
| level of access, I'm not sure any algorithms would hold up. I
| don't think Dual ECDRGB was used to attack the source control
| system.
| timmytokyo wrote:
| The brilliant part is that they did it in a way that
| remained undetected for so long. And the reason they could
| do that is because the backdoor already existed.
| Tylast wrote:
| I wonder how much Intellectual Property was exfiltrated
| because of this?
| dheera wrote:
| Is there a list of exactly what equipment (model numbers) was
| breached?
| celticninja wrote:
| It is software not hardware, so whatever model used the
| software.
| capableweb wrote:
| Theoretically you can run any software on any hardware so
| all hardware in the world is infected.
|
| 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.
| dheera wrote:
| Right, I'm wondering what models were designed to
| officially run the software that was infected, and if
| there are models that are known (by source code, reverse
| engineering or otherwise) to run uninfected firmware.
| snuxoll wrote:
| Basically any Juniper NetScreen (SSG-xxx) device, since
| it was ScreenOS that was modified by the attackers.
| nowugetme wrote:
| https://setkorp.com
| nowugetme wrote:
| https://setkorp.com
| indymike wrote:
| > That's surreal.
|
| 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).
| [deleted]
| [deleted]
| matheusmoreira wrote:
| Not surreal at all. It's exactly what everyone in the
| cryptography communuty said would happen if people listened to
| the government and added backdoors for the "good guys".
|
| 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.
| kafkaIncarnate wrote:
| They won't. You'll have lists and lists and lists, and
| they'll just say "you live in a society, you have no
| reasonable expectation of privacy", and then expect you
| replace your walls with glass on your house.
|
| They're too far gone if they still believe "if you have
| nothing to hide, you have nothing to fear" so openly.
| petre wrote:
| That's what security researchers and cryptographers had been
| warning about all along. Security for thee but not for me
| doesn't work.
| deadalus wrote:
| What if an insider helped the foreign adversary gain access?
| SV_BubbleTime wrote:
| Does that change anything with the NSA getting NIST, DoD, and
| later mfgs to go along with an algorithm that had two
| backdoors?
| adventured wrote:
| > The NSA made Juniper use a backdoored algorithm
|
| 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.
| nitrogen wrote:
| This is exactly how they "make" a company do something. Look
| at what happened to the Qwest (IIRC?) CEO to see what happens
| if you refuse these contracts.
| Supermancho wrote:
| https://www.eff.org/deeplinks/2007/10/qwest-ceo-nsa-
| punished...
|
| 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.
| pjc50 wrote:
| Were Juniper informed of the vulnerability at the time they
| made the decision? It appears not.
| wbl wrote:
| The vulnerability had been disclosed in 2007 by several
| independent researchers. It had also been patented by
| Certicom.
| stjohnswarts wrote:
| Exactly, if a company is willing to go to court they can't be
| made to build backdoors like this, at least not yet. Hence
| why everyone was peeved at apple for siding with the
| government to add government spyware to every apple phone to
| make sure citizens comply.
| stjohnswarts wrote:
| lol no! it was totally expected and security people and
| encryption advocates have been literally saying this kind of
| thing was bound to happen for Decades. You can only imagine how
| much of this remains out there. Also, see the recent Apple
| debacle. Letting government interfere with private business
| without a warrant is always, always bad. Even with a warrant it
| is troubling, but at least there are some checks and balances
| from the courts (supposedly neutral party)
| darksaints wrote:
| This needs to be brought up every single time congress proposes
| encryption backdoors.
| mdoms wrote:
| It's Bloomberg. Be skeptical.
| dylan604 wrote:
| I'm surprised we haven't seen an article explaining that the
| chip shortage is due to so many hidden chips being secretly
| placed on mobos used by the largest vendors.
| sockpuppet_12 wrote:
| Why is that story so far fetched exactly?
| philistine wrote:
| If you are referring to Bloomberg's bombshell story about
| rogue chips installed on motherboards in China during
| assembly at the factory that then have compromised Apple
| and Amazon (referenced here:
| https://www.aei.org/technology-and-innovation/bloombergs-
| bom...) than the far-fetched element is that it has been
| three years since the story came out and not a single
| element of physical evidence have been presented, when
| one would simply need a microscope to find them in
| devices. This after multiple major news organizations
| spent years trying to follow-up on the story and found no
| evidence whatsoever to back it up.
|
| It was a game of telephone gone horribly wrong, and
| Bloomberg's reputation is shot since they have refused to
| retract it.
| dylan604 wrote:
| That so many hidden/secret chips are being placed on
| mobos that we are suffering a global chip shortage
| because of it?
|
| 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.
| stjohnswarts wrote:
| But be far less skeptical than if it had come out of a Rupert
| Murdoch owned news source.
| the_rectifier wrote:
| It's not groundbreaking: it happened again and again.
| FridayoLeary wrote:
| How do you know it isn't still happening?
| TheRealDunkirk wrote:
| 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.
| oefrha wrote:
| Already discussed a fair bit two days ago:
| https://news.ycombinator.com/item?id=28404219
| dang wrote:
| Thanks! Macroexpanded:
|
| _The NSA 's Backdoor in Dual EC_ -
| https://news.ycombinator.com/item?id=28404219 - Sept 2021 (87
| comments)
| squarefoot wrote:
| Are there alternative OSes for this very specific hardware? I
| mean, Juniper aside, the risk that other network gear is
| similarly affected as well surely is not zero, so I wonder if
| there is any FOSS (also as in auditable) alternative firmware for
| these devices, or any ongoing efforts to create one.
| [deleted]
| rdtsc wrote:
| > Members of a hacking group linked to the Chinese government
| called APT 5 hijacked the NSA algorithm
|
| 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.
| codetrotter wrote:
| > 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!
|
| 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.
| SomeBoolshit wrote:
| Probably pretty chill internally. "The thing we knew would
| happen and that every expert said would happen happened."
| kafkaIncarnate wrote:
| "It fell within the acceptable matrix risk parameters."
| c7DJTLrn wrote:
| When an Agency with the purpose of ensuring the Security of the
| Nation does the exact opposite... makes you wonder why they
| even exist.
| zach_garwood wrote:
| "What would you say you do here?"
| baby wrote:
| There were two backdoors that were discovered at the time btw,
| the other one was a hardcoded password that could get you in
| any router (or something like that?) Odds are that there are
| more that weren't caught.
| JackGreyhat wrote:
| Correct. Same as Fortinet:
| https://betanews.com/2016/01/12/fortinet-firewalls-
| feature-h...
| haukem wrote:
| 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.
| mmmBacon wrote:
| This is a great example of why more operators should adopt white
| box solutions.
| tyingq wrote:
| 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 analysis.
| kazen44 wrote:
| i doubt you are able to get the same features out of whitebox
| hardware.
|
| 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.
| mmmBacon wrote:
| Actually I think P4 programmable switch ASICs such as
| Barefoot are going to become more prevalent over time and
| hence features will be available in software.
| kazen44 wrote:
| hasn't P4 been kind of dead in the water for the last
| couple of years.
| bifrost wrote:
| 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
| sekh60 wrote:
| Check out vyos.net
| Datagenerator wrote:
| Open- and FreeBSD deserve more usage
| 0x000000001 wrote:
| Well, JunOS is FreeBSD -- the magic is in their proprietary
| hardware. I'm not aware of open/whitebox solutions that can
| compete
| bifrost wrote:
| 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.
| kazen44 wrote:
| The same goes for a VMX, which arguable is even harder to
| virtualize (and it is not on par with a real MX series
| router yet). Mainly because emulating some trio chipset
| features is at the moment very hard/impossible to do with
| great performance. (especially the dense queing part)
| [deleted]
| collsni wrote:
| We are playing with a slippery slope! A backdoor is a backdoor.
| Honestly it is getting to the point where open source is the only
| way to go - imo.
|
| I'd like to be able to perform SAST scans and code review on all
| software that protects my enclaves.
| vmception wrote:
| Maybe I'm just jaded but isnt this the bottom of the slippery
| slope? The backdoored algorithm from a state actor was the
| slippery slope.
|
| 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
| collsni wrote:
| Lol. Yes you are right. I was directly referencing the idea
| of purposful backdoors becoming the norm.
| jart wrote:
| Most open source crypto code just does what NIST and DJB say to
| do. There's no magic imparted by it being FOSS.
| goodpoint wrote:
| On the contrary, there's plenty of different implementations
| of the same algorithms.
|
| Plus it's also extremely difficult to make underhanded
| changes to magic numbers if the source code is public.
| collsni wrote:
| I agree and that's pretty sad. FOSS gives the opportunity to
| code review.
| SV_BubbleTime wrote:
| Heart bleed is still the biggest point against your
| argument.
|
| 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.
| slim wrote:
| NIST _or_ DJB. It 's safer to ignore NIST and do what DJB
| says.
| nullc wrote:
| Makes NIST's responses towards DJB in the PQ crypto process
| have been ... interesting.
|
| https://groups.google.com/a/list.nist.gov/g/pqc-
| forum/c/3mVe...
| 9front wrote:
| C'mon man, that was 5-6 years ago!
| Spooky23 wrote:
| 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.
| bifrost wrote:
| 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...
| oenetan wrote:
| https://archive.is/QISk9
| aborsy wrote:
| 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?
| markus_zhang wrote:
| I'm actually thinking we have these kinds of backdoors in all
| products that may impact national security. Think it this way:
| What's the best way for NSA to conveniently access any product
| without pulling any string because doing so may alert the
| perpetrator? This is the only way that it can do it quietly. Of
| course, theoretically they could hire massively numbers of
| researchers and programmers but I don't really think it's gonna
| enough.
| legrande wrote:
| Well one heuristic to look at is how much proprietary and
| closed-source software is out there, and then make a rough
| estimate, say 3% of proprietary software has some sort of
| backdoor or malicious payload in it.
|
| What you have to ask, is why is certain software proprietary?
| Most of it is innocent, but sometimes it's closed for evil
| reasons.
| PenguinCoder wrote:
| Can almost certainly be sure CISCO is affected by something
| similar.
| tlb wrote:
| 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'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.
| a1369209993 wrote:
| > 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
| zahllos wrote:
| I think this is a little unfair to NIST. Some parts aren't
| entirely factual. For example while DES was specified at 56
| bits if we discount parity bits, I'm not sure how much choice
| they had in this - I suspect NSA/US gov more widely here.
| NSA, which is distinct from NIST but obviously works with
| them, requested changes to the DES S-Boxes during design that
| resulted in better protection from differential
| cryptanalysis, a technique unknown to anyone else at the
| time. So the NSA weakened DES in one way but strengthened it
| in another.
|
| 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/p
| ublicationDetails/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.
| merrier wrote:
| http://web.archive.org/web/20210903093344/https://www.bloomb...
|
| https://archive.is/QISk9
| [deleted]
| NelsonMinar wrote:
| 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.
|
| 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.
| kafkaIncarnate wrote:
| "You either die a hero, or live long enough to see yourself
| become the villain." -Harvey Dent
| caeril wrote:
| > you'd be crazy to trust anything the NSA offers to make you
| more secure
|
| 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.
| spockz wrote:
| Would you be safe by running multiple layers around your
| network? Each layer from a different vendor?
| tim-- wrote:
| It depends on your threat level.
| swiley wrote:
| Your best bet is to use things developed entirely in the
| open. Even if that compromises performance.
| mark_l_watson wrote:
| 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.
| the_rectifier wrote:
| Not at all, it was focused on implementing backdoors and
| surveillance for decades before that.
| [deleted]
| jorblumesea wrote:
| The intentional weakening of ECC has been an open secret for
| decades, and it's suspicious that this wasn't known by Juniper.
|
| I wonder if they were coerced into including it?
|
| https://www.schneier.com/blog/archives/2007/11/the_strange_s...
| NelsonMinar wrote:
| The article tells us "the Pentagon tied some future contracts
| for Juniper specifically to the use of Dual Elliptic Curve".
| That's not outright coercion but it's a significant incentive.
| Hell, RSA allowed itself to be corrupted for a measly $10M.
| https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...
| Buttons840 wrote:
| What does "ECC" mean here?
| aspenmayer wrote:
| I'm guessing it's elliptic curve cryptography.
|
| https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
| nowugetme wrote:
| https://setkorp.com
| JamesNay wrote:
| 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 finds out, who those APT are, because
| attribution is 1% more accurate than astrology.
| tomerv wrote:
| I lost you at the second paragraph. Crypto researches generally
| agree today that the NSA actually chose strong contents for DES
| (I assume that's what you meant by DEC?). They invented
| differential cryptanalysis a decade before anyone else, and
| used that to strengthen the cypher. Everyone suspected their
| motives at the time, but eventually academy caught up with the
| knowledge the NSA had, and could show that the constants are in
| fact good.
|
| Too bad they're doing the opposite of that nowadays...
| ragona wrote:
| The GP is talking about Dual EC (the infamous algorithm in
| question) and abbreviating it DEC.
| hjamesd wrote:
| Indeed, like this one
|
| https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
| bink wrote:
| The article mentions the Clipper Chip briefly but doesn't touch
| on what was widely believed at the time -- that the NSA and their
| political counterparts went completely silent on using
| legislation to backdoor encryption algorithms not because they
| lost the fight but because they had found a better way.
| cplex wrote:
| 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?
| largbae wrote:
| 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.
| edoceo wrote:
| It's too bad Soekris is gone. For home and small-corp networks
| they made an awesome router and you could put your favorite Linux
| on there. Trustable devices are hard to find.
|
| Also, if anyone knows of a Soekris like alternative I'm all ears,
| what to do if my 6501 and my spare 6501 die.
|
| Edit: this http://www.soekris.com/products/net6501-1.html
___________________________________________________________________
(page generated 2021-09-05 23:00 UTC)