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

331–340 of 500 posts

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

#331

Post by heavyset_go »

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.

Yeah, that was a hard read. I think it highlights the importance of emotionally distancing yourself from your projects.

It's also interesting because it exploits the current zeitgeist when it comes to maintainers' responsibilities to their users and communities. Personally, I think it puts too much expectation on maintainers' shoulders, especially when they're working for free.

Personally, I think maintainers are doing favors for users, and if they don't like how the project is progressing or not, then too bad. That's not a popular sentiment, though.

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

#332

Post by heavyset_go »

stingraycharles wrote: post #38
Alifatisk wrote: post #18

Earlier quoted context omitted.

For real, it's almost like a state-sponsored exploit. It's crafted and executed incredibly well, the performance issue feels like pure luck it got found.

I like the theory that actually, it wasn’t luck but was picked up on by detection tools of a large entity (Google / Microsoft / NSA / whatever), and they’re just presenting the story like this to keep their detection methods a secret. It’s what I would do.

You're describing parallel construction and it is something that happens all of the time.

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

#333

Post by amluto »

pxx wrote: post #166
Denvercoder9 wrote: post #140

Earlier quoted context omitted.

I'm not too familar with the SSH protocol, but is it possible to impersonate a victim server V without having the private key to their host key?

This stuff is pre-auth. You can just treat the entire thing as opaque and proxy everything to the host you're trying to compromise; as soon as you have an exploit string for a given host you can just replay it.

I suppose the original attacker could give really fancy exploit strings that verify the eventual payload strongly enough to prevent someone replaying the attack from accomplishing much.

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

#334

Post by loeg »

jhugo wrote: post #306
loeg wrote: post #266

Earlier quoted context omitted.

I don't think this is responsive to my comment.

I think it is? They were not trying to hide the content, but rather to ensure that nobody else could encrypt valid payloads.

The signing accomplishes that. The chacha20 encryption with part of a public key, which is what I'm discussing above, is just obfuscation.

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

#335

Post by loeg »

kevincox wrote: post #282
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?

Encrypting the payload will allow you to get by more scanners and in general make the traffic harder to notice. Since the publicly available server code needs to be able to decrypt the payload there is no way to make it completely secure, so this seems like a good tradeoff that prevents passive naive monitoring from triggering while not being more complicated than necessary. The only real improvement that I can see b…

Seems like single-byte XOR would be almost as good for obfuscation purposes, but I guess using chacha20 from the public key as a pseudo-OTP doesn't hurt.

> The only real improvement that I can see being made would be adding perfect forward secrecy so that a logged session couldn't be decrypted after the fact. But that would likely add a lot of complexity (I think you need bidirectional communication?)

Yeah.

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

#336

Post by wezdog1 »

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!

Also it may br a coincidence but JiaT75 looks a lot like Transponder 7500 which in aviation means hijacked...

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

#337

Post by jeroenhd »

croemer wrote: post #312
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.

Jia Tan's GitHub activity was mostly 10-18@UTC, consistent with Europe/Israel/Russia

It's rather trivial to fake git commits.

Basing this stuff on email times (especially replies to emails sent that same day) would be more relevant. However. if this operation was pulled off with the precision and opsec that it seems to have been, I wouldn't be too surprised if whatever group is behind this attack would've sent over + funded a developer somewhere in a time zone of their choice.

No doubt any nation state is able to station someone in Russia/Israel/one of the n-eyes countries.

I doubt OSINT will figure out who is really behind this, but I'm sure governments will, soon enough. Whether or not they report the truth of their findings, and if one should trust the official reporting, is yet another tough question.

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

#338

Post by Culonavirus »

croemer wrote: post #312
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.

Jia Tan's GitHub activity was mostly 10-18@UTC, consistent with Europe/Israel/Russia

I like to think that the performance issue in the exploit was actually an exploit of an exploit, a counterintelligence act, by some "good samaritan" :D

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

#339

Post by bawolff »

Aloisius wrote: post #298
slaymaker1907 wrote: post #277

Earlier quoted context omitted.

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…

It was both. The binary object file was obfuscated in two "test" xz files in the repo itself. The code to extract the object file and inject it into the build process was only in the GitHub release tarball. The code in the tarball could have been prevented if only automated tarballs were permitted (for instance, GitHub's branch/tag source tarballs) or caught after the fact by verifying the file hashes in the tarball…

> The code to extract the object file and inject it into the build process was only in the GitHub release tarball.

I thought it was in both, however the backdoor wasn't inserted with the default build time options, so it ended up in the tarball, but not if you just did make unless you set things up the same as the build server.

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

#340

Post by bawolff »

xvector wrote: post #279
bawolff wrote: post #275

Earlier quoted context omitted.

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

That's a pretty strong claim. Do you have any evidence they have done this?

And i mean, i'm genuinely curious. I don't think they would be above doing so if they had the opportunity, i just haven't heard of any instances where they were caught doing so.

Post reply on HN