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

221–230 of 500 posts

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

#221

Post by pxx »

takeda wrote: post #204
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.

If you think of it as a state sponsored attack it makes a lot of sense to have a "secure" vulnerability in system that your own citizens might use. It looks like the whole contribution to xz was an effort to just inject that backdoor. For example the author created the whole test framework where he could hide the malicious payload. Before he started work on xz, he made contribution to libarchive in BSD which created…

The libarchive diff didn't create any vulnerability. The fprintf calls were consistent with others in the same repository.

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

#222

Post by bawolff »

udev4096 wrote: post #125
sureglymop wrote: post #31

Earlier quoted context omitted.

Yes.. The RCE happens at the connection stage before anything is logged.

That's insane. How exactly does this happen? Are there no EDR/IDS who can detect an RCE at the connection stage?

An IDS may detect something depending on what it is looking for. The grandparent is saying that sshd doesn't log anything. Which is not that surprising since sshd is atracker controlled.

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

#223

Post by dogman144 »

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 the threat actor via this exploit.

So imo means only EDRs (monitoring processes on endpoints) or software supply chain evaluations (monitoring sec problems in upstream FOSS) are most likely to catch the exploit itself.

Leads into another fairly large security theme interestingly - dev teams can dislike putting EDRs on boxes bc of the hit on compute and UX issues if a containment happens, and can dislike limits policy and limits around FOSS use. So this exploit hits at the heart of a org-driven “vulnerability” that has a lot of logic to stay exposed to or to fix, depending on where you sit. Security industry’s problem set in a nutshell.

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

#224

Post by bawolff »

slaymaker1907 wrote: post #220
pixl97 wrote: post #32

Earlier quoted context omitted.

So who's started scanning open source lib test cases for more stuff like this?

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.

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

#225

Post by VMG »

MOARDONGZPLZ wrote: post #72
edflsafoiewq wrote: post #64

Earlier quoted context omitted.

They could announce it without revealing their detection method. I don't see what the extra indirection buys them.

Shutting down 99.9% of speculation on how the vulnerability was found in the first place.

(1) obviously not

(2) they could just say they found it during some routine dependency review or whatever

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

#226

Post by hnthrowaway0328 »

coldpie wrote: post #63
hnthrowaway0328 wrote: post #33

Earlier quoted context omitted.

Do we have a detailed technical analysis of the code? I read a few analysis but they all seem preliminary. It is very useful to learn from the code.

There's a few links down at the bottom of the OP to quite detailed analysis. From there you could join a Discord where discussion is ongoing.

Thanks coldpie.

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

#227

Post by bawolff »

gghffguhvc wrote: post #97
kstrauser wrote: post #62

Earlier quoted context omitted.

Yes. This would surely be prosecutable under the CFAA. Honestly, if I were involved in this, I'd hope that it was, say, the FBI that caught me. I think that'd be the best chance of staying out of the Guantanamo Bay Hilton, laws be damned.

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"

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

#228

Post by [deleted] »

deepbreath wrote: post #206
ulrikrasmussen wrote: post #94

Earlier quoted context omitted.

What if the knocking sequence was derived from a TOTP secret?

Don't have to do anything too complicated. Here's the knocker code in a short Bash script, produced by GPT4: ~ % gpt4 'write a very short bash script that takes the number stored in ~/.ssh/knock_seq, increments it by 1 and saves it to the file. It then takes the new number and concatenates it with the value stored in the file ~/.ssh/secret. It pipes the resulting string to sha1sum, spitting out binary. It then takes…

[deleted]

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

#229

Post by halJordan »

cesarb wrote: post #136
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.

This is called NOBUS: https://en.wikipedia.org/wiki/NOBUS

This is not that concept. That concept is no one but us can technically complete the exploit. Technical feasibility in that you need a supercomputer to do it, not protecting a backdoor with the normal cia triad

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

#230

Post by jcranmer »

gghffguhvc wrote: post #48

Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.

There are things you can't contractually wave away, especially in form contracts that the other side has no ability to negotiate (which is what software licenses amount to).

One of those things is going to be fraud: if the maintainer is intentionally installing backdoors into their software and not telling the user, there's going to be some fraud-like statute that they'll be liable for.

Post reply on HN