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

401–410 of 500 posts

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

#401

Post by cookiengineer »

dxthrwy856 wrote: post #391

The parallels in this one to the audacity event a couple years back are ridiculous. Cookie guy claimed that he got stabbed and that the federal police was involved in the case, which kind of hints that the events were connected to much bigger actors than just 4chan. At the time a lot of people thought its just Muse Group that's involved, but maybe it was a (Russian) state actor? Because before that he claimed that au…

Careful, APT28 is pretty dangerous. They are merging their ops with APT29 these days, and I wouldn't wake the cozy bear if I were you.

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

#402

Post by pixelfarmer »

EasyMark wrote: post #398

This whole thing makes me wonder if AI could detect "anomalies" like the human who found the actual hack did. Observe a system (lots of systems) and use that data to spot anomylous behavior from "new" versions of packages being added, throw up a red flag that is like "this really doesn't act like it did in the past because parameter(s) are unusual given previous versions"

Just needs a fine grained enough set of parameters that are observed on a system, aka "monitoring", and flag anything that sticks out. No need for "AI" unless the parameters that are monitored have more of a (complex) pattern to them than some value +/- deviation or similar things. "AI" is, in an abstract way, a pattern matcher and replacer, but also a big cannon that is often not needed and simpler heuristics work faster and better (and are usually deterministic).

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

#403

Post by vikramkr »

greyface- wrote: post #356
vikramkr wrote: post #355

Earlier quoted context omitted.

Is there some weird loophole or something I'm missing here? Otherwise, I'm not exactly sure how hacking wouldn't be illegal.

Hacking statues cover unauthorized access, and there's no evidence that unauthorized access has occurred, unless we see someone actually making use of the backdoor in the wild. Accessing a system without authorization is a crime, but distributing code that contains a backdoor is not a crime. The attacker was authorized to publish changes to xz.

Do you have a source for the claim that this isn't a crime because it didn't succeed? As a sanity check, checking the plain text of the CFAA, it covers attempted hacking as you'd expect. So distributing a system with a backdoor, introducing a backdoor, etc all seem quite comfortably covered by existing statues. Which makes sense since like, I don't want to say 'duh' because I think that probably wouldn't meet HN guidelines for discourse but I'm not sure what else to say. Even American politicians, as notoriously incompetent as our leaders can be sometimes, wouldn't miss a crime that obvious. https://www.law.cornell.edu/uscode/text/18/1030

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

#404

Post by vikramkr »

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.

As a sanity check, attempted crime is still crime, so not a lawyer but part B isn't exactly ambiguous here: https://www.law.cornell.edu/uscode/text/18/1030

In terms of a plausible business model - I mean that's conspiracy to commit crime, like of course that's illegal? And depending on the state actor and the target system - literally treason if it's a cyber attack as a part of a war? You can put whatever you want into a license or contract but obviously that doesn't let you override the actual law

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

#405

Post by j16sdiz »

bilekas wrote: post #385
mondrian wrote: post #383

Earlier quoted context omitted.

A main culprit seems to be the addition of binary files to the repo, to be used as test inputs. Especially if these files are “binary garbage” to prove a test fails. Seems like an obvious place to hide malicious stuff.

It is an obvious place for sure, but it also would have been picked up if the builds where a bit more transperant. That batch build script should have been questioned before approval.

By whom? The attacker have assumed the maintainer role. Nobody is reviewing.

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

#406

Post by lpapez »

EasyMark wrote: post #398

This whole thing makes me wonder if AI could detect "anomalies" like the human who found the actual hack did. Observe a system (lots of systems) and use that data to spot anomylous behavior from "new" versions of packages being added, throw up a red flag that is like "this really doesn't act like it did in the past because parameter(s) are unusual given previous versions"

Anomaly, fraud, outlier detection...

AI has been trying to solve that for several decades and in my experience in production these systems usually end up being a set of expert written rules saying "if X is greater than Y, notify someone to check".

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

#407

Post by rwmj »

bclemens wrote: post #361
rwmj wrote: post #29

Earlier quoted context omitted.

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.

We likely would have backported the change. I'm already planning a big rebase of packages that missed the Fedora 40 / C10S branch (related to RISC-V in that case).

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

#408

Post by pyinstallwoes »

mrkramer wrote: post #212
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…

At first I thought the guy who did this was a lone wolf but now I believe it was indeed state actor. They coordinated and harassed original maintainer into giving them access to the project, basically they hijacked the open source project. The poor guy(the original maintainer) was alone against state actor who was persistent with the goal of hijacking and then backdooring the open source project. It seems like they w…

> “Recently I've worked off-list a bit with Jia Tan on XZ Utils and”

> "In 2021, JiaT75 submitted a pull request to the libarchive repository with the title ‘Added error text to warning when untaring with bsdtar’ which seemed legitimate at first glance. "

Seems “Jia” is related to both

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

#410

Post by ToneWashed »

withinboredom wrote: post #396
bilekas wrote: post #379

This whole thing has been consuming me over the whole weekend. The mechanisms are interesting and a collection of great obfuscations, the social engineering is a story that’s shamefully all too familiar for open source maintainers. I find most interesting how they chose their attack vector of using BAD test data, it makes the rest of the steps incredibly easier when you have a good archive, manipulate it in a structu…

It’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies. These long-games are kinda scary and until whatever “evil” is actually done you have no idea what is actual…

> It’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies.

Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? In lieu of recent events I don't think anyone would blame you, in fact you might even suggest they explain such an oddly specific side effect in a README or such.

Post reply on HN