Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

github.com

Post reply on HN
Print view View original

251–260 of 500 posts

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#251

Post by robocat »

davikr wrote: post #74
faxmeyourcode wrote: post #43

Edit: I misunderstood what I was reading in the link below, my original comment is here for posterity. :) > From down in the same mail thread: it looks like the individual who committed the backdoor has made some recent contributions to the kernel as well... Ouch. https://www.openwall.com/lists/oss-security/2024/03/29/10 The OP is such great analysis, I love reading this kind of stuff!

Lasse Collin is not Jia Tan until proven otherwise.

Passive aggressive accusation.

This style of fake doubt is really not appropriate anywhere.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#252

Post by Alezz »

hybridtupel wrote: post #208
gowld wrote: post #201

Earlier quoted context omitted.

This goes back to WWII. USA solves problems with manufacturing and money. Europeans relatively lack both, so they solve problems with their brains.

Israel is not in Europe

The perfect definition of Europe is if they took part in the Eurovision Song Contest.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#253

Post by fpgaminer »

declan_roberts wrote: post #77

One thing I notice about state-level espionage and backdoors. The USA seems to have an affinity for hardware interdiction as opposed to software backdoors. Hardware backdoors make sense since much of it passes through the USA. Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors. A much harder game to play.

My completely unexpert opinion, informed by listening to all the episodes of Darknet Diaries, agrees with this. US intelligence likes to just bully/bribe/blackmail the supply chain. They've got crypto chops, but I don't recall any terribly sophisticated implants like this one (except Stuxnet, which was likely Israel's work funded/assisted by the US). NK isn't terribly sophisticated, and their goal is money, so that doesn't match either. Russia is all over the place in terms of targets/sophistication/etc because of their laws (AFAIK it's legal for any citizen to wage cyberwarfare on anything and everything except domestically), but this feels a bit beyond anything I recall them accomplishing at a state level. Israeli organizations have a long history of highly sophisticated cyberwarfare (Stuxnet, NSO group, etc), and they're good about protecting their access to exploits. That seems to fit the best. That said, saying "Israeli organization" casts a wide net since it's such a boiling hotspot for cybersecurity professionals. Could be the work of the government, could be co-sponsored by the US, or could just be a group of smart people building another NSO group.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#254

Post by yread »

btown wrote: post #163
declan_roberts wrote: post #87

Earlier quoted context omitted.

I agree that this is probably about persistence. Initially I thought the developer was playing the long-con to dump some crypto exchange and make off with literally a billion dollars or more. But if that was the case they wouldn't bother with the key. It'd be a one-and-done situation. It would be a stop-the-world event. Now it looks more like nation-state spycraft.

It's worth also noting that the spycraft involved a coordinated harassment campaign of the original maintainer, with multiple writing styles, to accelerate a transition of maintainership to the attacker: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00568.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.h... While this doesn't prove…

Maybe they weren't all sockpuppets. Here Jigar Kumar was nitpicking Jia Tan's changes:

https://www.mail-archive.com/xz-devel@tukaani.org/msg00556.h...

That was not necessary to gain trust. Writing style is different, too. Later when Jia gained commit access he reminds him to merge it.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#255

Post by mlyle »

gnramires wrote: post #217
mlyle wrote: post #159

Earlier quoted context omitted.

Naive knocking isn't good as a primary security mechanism, but it lowers your attack surface and adds defense in depth. It means that people who can't intercept traffic can't talk to the ssh server-- and that's most attackers at the beginning phases of an attack. And even someone who can intercept traffic needs to wait for actual administrative activity.

Defense in depth has value I agree, but I think it can also be counterproductive in some cases. Every layer can also be buggy and have vulnerabilities, which can often leak (e.g. into code execution) and compromise the whole system (bypassing layers). What happened in this case seems to be a case of maintained hijacking and introducing vulnerabilities. Adding an additional dependency (of say a port-knocking library)…

> Adding an additional dependency (of say a port-knocking library) doesn't look great in that regard, if the dependency can be hijacked to add remote code execution capabilities.

Port knocking infrastructure can be minimal, knowing nothing but addresses knocking. It can also be completely outside the protected service on a gateway.

Indeed, it can even be no-code, e.g. https://www.digitalocean.com/community/tutorials/how-to-conf...

> OpenSSH should be extremely simple and easy to understand, such that every proposal and change could be easily scrutinized.

But OpenSSH intrinsically is going to have a much larger attack surface.

> then a small codebase can go most of the way to mathematically provable security (bonus points for formal verification).

It's worth noting this would not have helped against this attack:

* It was against another dependency, not openssh

* The actual vulnerability didn't occur in the code you'd inspect as part of verification processes today. (I don't think anyone is formally verifying build process).

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#256

Post by cpach »

gowld wrote: post #202
wolverine876 wrote: post #110

Have the heads of the targeted projects - including xz (Lasse Collin?), OpenSSH (Theo?), and Linux (Linus) - commented on it? I'm especially interested in how such exploits can be prevented in the future.

OpenSSH and Linux were not targeted/affected. xz and the Debian distribtion of OpenSSH were targeted.

Fedora too.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#257

Post by Delk »

allanbreyes wrote: post #210
btown wrote: post #163

Earlier quoted context omitted.

It's worth also noting that the spycraft involved a coordinated harassment campaign of the original maintainer, with multiple writing styles, to accelerate a transition of maintainership to the attacker: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00568.h... https://www.mail-archive.com/xz-devel@tukaani.org/msg00569.h... While this doesn't prove…

Ugh, that this psyops sockpuppetry may have started or contributed to the maintainer's mental health issues seems like the most depressing part of all this. Maintaining OSS is hard enough.

Probably didn't start them, considering that he already mentioned (long-term) mental health issues in the mailing list discussion in which the (likely) sock puppets started making demands.

But it's hard to see the whole thing helping, and it is some combination of depressing and infuriating. I hope he's doing ok.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#258

Post by kstrauser »

bawolff wrote: post #227
gghffguhvc wrote: post #97

Earlier quoted context omitted.

Even with the MIT disclaimer and the author not being the distributor or have any relationship with the distributor. Publishing vulnerable open source software to GitHub with a disclaimer that says it isn’t fit for any purpose seems like a bit of an oversight of using MIT license in distros to me.

That is not how disclaimers work. You cannot disclaim liability for intentionally harming someone. You also cannot avoid criminal charges for a crime simply by shouting "don't blame me"

That's exactly right. Imagine a license that said "...and I can come to your house and kill you if I want to." Even if someone signed it in ink and mailed a copy back, the licensor still can't go to their house and kill them even though the agreement says they can.

I can imagine the case of maybe a "King of the Hill"-type game played on bare hardware, where you're actively trying to hack into and destroy other players' systems. Such a thing might have a license saying "you agree we may wipe your drive after downloading all your data", and that might be acceptable in that specific situation. You knew you were signing up for a risking endeavor that might harm your system. If/when it happens, you'd have a hard time complaining about it doing the thing it advertised that it would do.

Maybe. Get a jury involved and who knows?

But somewhere between those 2 examples is the xz case. There's no way a user of xz could think that it was designed to hack their system, and no amount of licensing can just wave that away.

For a real world analogy, if you go skydiving, and you sign an injury against waiver, and you get hurt out of pure dumb luck and not negligence, good luck suing anyone for that. You jumped out of a plane. What did you think might happen? But if you walk into a McDonald's and fall through the floor into a basement and break your leg, no number of "not responsible for accidents" signs on the walls would keep them from being liable.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#259

Post by thenewwazoo »

loeg wrote: post #134

> The ciphertext is encrypted with chacha20 using the first 32 bytes of the ED448 public key as a symmetric key. As a result, we can decrypt any exploit attempt using the following key: Isn't this wild? Shouldn't the ciphertext be encrypted with an ephemeral symmetric key signed by the privkey? I guess anyone with the public key can still read any payload, so what's the point?

This is a NOBUS attack - Nobody But Us.

By tying it to a particular key owned by the attacker, no other party can trigger the exploit.

Post reply on HN