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

361–370 of 500 posts

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

#361

Post by bclemens »

rwmj wrote: post #29
arnaudsm wrote: post #9

Have we seen exploitation in the wild yet?

If it hadn't been discovered for another month or so, then it would have appeared in stable Fedora 40, Ubuntu 24.4 and Debian, and then it definitely would have been exploited. Another year it would have been in RHEL 10. Very luck escape.

Nope, it wouldn't have been in RHEL 10 or any of the rebuilds. CentOS Stream 10 already branched from Fedora / ELN. The closest it would have gotten is a Fedora ELN compose, and it's doubtful it would have remained undiscovered long enough to end up in CentOS Stream 11.

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

#362

Post by Zuiii »

heeen2 wrote: post #359

I wonder if separating the test files out into their own repo, so that they would not have been available at build time could have made this harder. The reasoning being that anything available and this potentially involved in the build should be human readable.

> Anything available and this potentially involved in the build should be human readable.

That's actually a good principle to adopt overall.

We should treat this attack like an air plane accident and adopt new rules that mitigate the chances of it being successfully carried out again. We might not be able to vet every single person who contributes, but we should be able to easily separate out noisy test data.

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

#363

Post by CommitSyn »

Beijinger wrote: post #280
haswell wrote: post #16

Earlier quoted context omitted.

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

Not only did it mandate authentication, but there was also a Killswitch, and there's no other reason for that than because you have reasons to suspect someone may have access to this sensitive world-stopper exploit and use it against you. That leaves simply a (reasonably, but still) paranoid person, and people worried about that+consequences are unlikely to have the mental well-being to pull this off, or, a group of people.

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

#364

Post by bandrami »

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.

The whole point of asymmetric-key is that a middleman can't do that. Even if you relayed the entire handshake, all traffic after that is just line noise to you unless you have the transmitter's private key. You can't read it or mangle it (well, you can mangle it, but the receiving party will know it was mangled in transit). The exploit string on the wire for that transmission won't work in the context of any other transmission sequence.

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

#365

Post by pxx »

bandrami wrote: post #364
pxx wrote: post #166

Earlier quoted context omitted.

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.

The whole point of asymmetric-key is that a middleman can't do that. Even if you relayed the entire handshake, all traffic after that is just line noise to you unless you have the transmitter's private key. You can't read it or mangle it (well, you can mangle it, but the receiving party will know it was mangled in transit). The exploit string on the wire for that transmission won't work in the context of any other tr…

Yeah I had mistakenly thought the exploit string was transmitted during key exchange (read too quickly on "pre-auth"), which is incorrect; see sibling comment. I'm unfortunately past the edit window now.

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

#366

Post by [deleted] »

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…

[deleted]

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

#367

Post by CommitSyn »

pxx wrote: post #353
jhugo wrote: post #301

Earlier quoted context omitted.

It did, actually: the filename can contain terminal control characters, which thanks to the change from safe_fprintf to fprintf, were printed without escaping, which allows the creator of the archive being extracted to control the terminal of the user extracting the archive.

That's (a) not exploitable without the existence of a much higher-severity exploit -- sure you can clear the screen, but that's low impact (b) possible to trigger on other extant paths; see https://github.com/libarchive/libarchive/issues/2107 so it seems nothing new was introduced (c) kind of contrived to get to execute; you have to somehow fail to extract the archive but on the happy path you'll see a bunch of weird…

Is it possible it was part of a planned or current exploit chain, some other way it could have been utilized?

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

#369

Post by AlexanderTheGr8 »

Is there any progress on identifying the attacker? This would make it much easier to find out it this was really a state-sponsored attack.

If this backdoor can be classified as a crime, github logs can identify the IP/location/other details of the attacker which is more than enough to identify them, unless their OPSEC is perfect, which it almost never is (e.g. Ross Ulbricht).

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

#370

Post by db48x »

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.

I’m no lawyer, but it is at minimum tortuous interference.
Post reply on HN