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

261–270 of 500 posts

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

#261

Post by aftbit »

shp0ngle wrote: post #236
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.

CIA didn't put anyone new into gitmo for years. The 30 remaining gitmo prisoners are all W Bush holdovers that all subsequent administrations forgot.

Sure but that's because the world knows about Gitmo now. What about the other quieter black sites?

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

#262

Post by anonymous-panda »

cjbprime wrote: post #8
miduil wrote: post #2

Super impressed how quickly the community and in particular amlweems were able to implement and document a POC. If the cryptographic or payload loading functionality has no further vulnerabilities, this would have been also at least not introducing a security flaw to all the other attackers until the key is broken or something. Edit: I think what's next for anyone is to figure out a way to probe for vulnerable deploy…

Probing for vulnerable deployments over the network (without the attacker's private key) seems impossible, not non-trivial. The best one could do is more micro-benchmarking, but for an arbitrary Internet host you aren't going to know whether it's slow because it's vulnerable, or because it's far away, or because the computer's slow in general -- you don't have access to how long connection attempts to that host took…

Should be able to do it by having the scanner take multiple samples. As long as you don’t need a valid login and the performance issue is still observable, you should be about to scan for it with minimal cost

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

#263

Post by SAI_Peregrinus »

Ekaros wrote: post #46
cellis wrote: post #26

Earlier quoted context omitted.

Or...falling back on less noticed contingency plans...

My pet theory is that this was just one project they have been running for years. They are likely doing many more at same time. Slowly inserting parts in various projects and getting their contributors inside the projects.

If it's an intelligence agency exploit, this is nearly certain. Getting agents hired as employees of foreign companies to provide intelligence is an ancient practice. Getting agents to be open source maintainers is a continuation of the same thing.

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

#264

Post by varenc »

meowface wrote: post #151
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.

>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. Why not? It's possible someone else could've discovered the exploit before the big attack but decided not to disclose it. Or that they could've disclosed it and caused a lot of damage the attacker didn't necessarily want. And they easily could've been planning both a long-term way to acce…

I think we need to consider the context. The attacker ultimately only had control over the lzma library. I'm skeptical that there's an innocent looking way that lzma could have in the open introduced an "accidental" RCE vuln that'd affect sshd. Of course I agree that they also wanted an explicit stealth backdoor for all the other reasons, but I don't think a plausibly deniable RCE or authentication bypass vuln would have even been possible.

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

#265

Post by stefan_ »

ajross wrote: post #153
toasteros wrote: post #58

Earlier quoted context omitted.

The name that keeps coming up is Jia Tan ( https://github.com/JiaT75/ ) but we have no way of knowing if this is a real name, pseudonym, or even a collective of people.

It's also worth pointing out, given the almost two years of seemingly valuable contribution, that this could be a real person who was compromised or coerced into pushing the exploit.

It’s also worth pointing out that parts of the RCE were prepared almost two years ago which makes this entirely implausible.

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

#266

Post by loeg »

thenewwazoo wrote: post #259
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.

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

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

#267

Post by acdha »

MuffinFlavored wrote: post #182
acdha wrote: post #147

Earlier quoted context omitted.

That’s what the compromised build stage did. It’s really interesting to read if you want to see the details of how a sophisticated attacker works: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b... https://gynvael.coldwind.pl/?lang=en&id=782

> build-to-host.m4 I wasn't aware that the rogue maintainer was able to commit himself without any PR review (or he snuck it through PR review) rogue steps in the build process as well that went unnoticed so that he could bundle decompressed `xz` streams from test data, that also patched output .so files well enough to add hooking code to them. How many "process failures" are described in that process that exist in e…

This guy was pretty trusted after a couple of years of working on the project so I think it’s a category error to say process improvements could have fixed it. The use of autoconf detritus was a canny move since I’d bet long odds that even if your process said three other people had to review every commit they would have skimmed right over that to the ”important” changes.

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

#268

Post by toast0 »

mlyle wrote: post #84
herpderperator wrote: post #42

Earlier quoted context omitted.

The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. This can turn into a footgun: you're away from your usual device, something happens and you desperately need to connect, but now you can't because all the devices in your vicinity don't have the ability to perform $SECURITY_FEATURE_X so that you can connect, and you're screaming a…

> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. You can type http://hostname:porttoknock in a browser. As long as you're not behind a super restrictive gateway that doesn't let you connect to arbitrary ports, you're golden.

Likely won't be enough if you're behind CGNAT and you get a different public IP on different connections.

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

#269

Post by barkingcat »

yread wrote: post #254
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…

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.

that's precisely what sock puppetry does ... talk/write in a different writing style to make others believe it's different people.

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

#270

Post by [deleted] »

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.

[deleted]
Post reply on HN