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

271–280 of 500 posts

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

#271

Post by furstenheim »

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…

I actually wondered how many packages they harassed until they got access to one such

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

#272

Post by fubar9463 »

jmb99 wrote: post #216
FergusArgyll wrote: post #128

Earlier quoted context omitted.

Interesting... Though you can edit whatever log file you want

Any log that root on that box has write access to. It’s theoretically possible to have an anomaly detection service running on a vulnerable machine dumping all of its’ data to an append-only service on some other non-compromised box. In that case, (in this ideal world) the attacker would not be able to disable the detection service before it had logged the anomalous traffic, and wouldn’t be able to purge those logs s…

You would be sending logs to a log collector (a SIEM) in security terms, and then you could join your firewall logs against your SSH auth logs.

This kind of anomaly detection is possible. Not sure how common it is. I doubt it is common.

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

#273

Post by bawolff »

kstrauser wrote: post #258
bawolff wrote: post #227

Earlier quoted context omitted.

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 player…

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

Even this is a bad example, since it is just gross negligence and not intentional. A better analogy would be if mcdonalds shoots you.

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

#274

Post by acdha »

dogman144 wrote: post #223
acdha wrote: post #6

Has anyone tried the PoC against one of the anomalous process behavior tools? (Carbon Black, AWS GuardDuty, SysDig, etc.) I’m curious how likely it is that someone would have noticed relatively quickly had this rolled forward and this seems like a perfect test case for that product category.

Depends how closely the exploit mirrors and/or masks itself within normal compression behavior imo. I don’t think GuardDuty would catch it as it doesn’t look at processes like an EDR does (CrowdStrike, Carbon black), I don’t think sysdig would catch it as looks at containers and cloud infra. Handwaving some complexity here, as GD and sysdig could prob catch something odd via privileges gained and follow-on efforts by…

Guard Duty does have some ptocees level monitoring with some recent additions: https://aws.amazon.com/blogs/aws/amazon-guardduty-ec2-runtim...

The main thing I was thinking is that the audit hooking and especially runtime patching across modules (liblzma5 patching functions in the main sshd code block) seems like the kind of thing a generic behavioral profile could get but especially one driven by the fact that sshd does not do any of that normally.

And, yes, performance and reliability issues are a big problem here. When CarbonBlack takes down production again, you probably end up with a bunch of exclusions which mean an actual attacker might be missed.

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

#275

Post by bawolff »

Voultapher wrote: post #241
bawolff wrote: post #214

Earlier quoted context omitted.

> Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors What is this in reference to?

NSO Group They are an Israel based company, that sell zero-click RCEs for phones and more. Such malicious software was involved in the murder of journalist Jamal Khashoggi. Their exploits, developed in-house as well as presumably partially bought on the black market, are some of the most sophisticated exploits found in the wild, e.g. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... > JBIG2 doesn't have…

> that sell zero-click RCEs

Exactly my point. They do not sell backdoors.

Don't get me wrong, still icky, but definitely not a "very well engineered, multi-year software backdoors"

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

#276

Post by bawolff »

ginko wrote: post #233
bawolff wrote: post #214

Earlier quoted context omitted.

> Other countries such as Israel are playing the long-con with very well engineered, multi-year software backdoors What is this in reference to?

Probably Stuxnet.

Stuxnet was not a backdoor.

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

#277

Post by slaymaker1907 »

bawolff wrote: post #224
slaymaker1907 wrote: post #220

Earlier quoted context omitted.

I think it would help to try and secure signing infrastructure as much as possible. First of all, try to have 3 devs for any given project (this is the most difficult step). Make sure logging into or changing any of the signing stuff requires at least 2 of the devs, one to initiate the JIT and one to monitor. Additionally, take supply chain steps like requiring independent approval for PRs and requiring the signing p…

I do not think any of that would have prevented this situation.

Upon further reading, I think you might be correct. I initially thought a good signing process would be sufficient since it sounded like this malicious blob was secretly being included in the tarball by the build server, but it instead seems to be the case that the malicious binary was included in the repo as a test file.

You could probably still protect against this sort of attack using signing, but it would be much more laborious and annoying to get working. The idea is that you would somehow declare that OpenSSH binaries must be signed by a *particular* key/authority, that VS Code is signed by Microsoft, Chrome signed by Google, etc. Additionally, the config declaring all of this obviously needs to be secured so you'd need to lock down access to those files (changing key associations would need to require more permissions than just updating old software or installing new software to be useful).

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

#278

Post by pama »

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.

The core source of the vulnerability (symbol lookup order allowing a dependency to preempt a function) might theoretically be fixed at the Linux+OpenSSH level.

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

#279

Post by xvector »

bawolff wrote: post #275
Voultapher wrote: post #241

Earlier quoted context omitted.

NSO Group They are an Israel based company, that sell zero-click RCEs for phones and more. Such malicious software was involved in the murder of journalist Jamal Khashoggi. Their exploits, developed in-house as well as presumably partially bought on the black market, are some of the most sophisticated exploits found in the wild, e.g. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... > JBIG2 doesn't have…

> that sell zero-click RCEs Exactly my point. They do not sell backdoors. Don't get me wrong, still icky, but definitely not a "very well engineered, multi-year software backdoors"

They implant backdoors and sell zero-click RCEs that exploit those backdoors.

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

#280

Post by Beijinger »

haswell wrote: post #16
asveikau wrote: post #10

It's pretty interesting that they didn't just introduce an RCE that anyone can exploit, it requires the attacker's private key. It's ironically a very security conscious vulnerability.

I suspect the original rationale is about preserving the longevity of the backdoor. If you blow a hole wide open that anyone can enter, it’s going to be found and shut down quickly. If this hadn’t had the performance impact that brought it quickly to the surface, it’s possible that this would have lived quietly for a long time exactly because it’s not widely exploitable.

This is just a safety measure that it does not blow up in your own face (country).
Post reply on HN