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

411–420 of 500 posts

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

#411

Post by pyinstallwoes »

asveikau wrote: post #303
yread wrote: post #254

Earlier quoted context omitted.

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.

This looks like a very phony "debate". I think the most convincing case made about the sock puppets is around account creation dates, and also people disappearing after they get what they need. Like Jigar disappearing after Jia becomes maintainer. Or the guy "misoeater19" who creates his debian bug tracker account to say that his work is totally blocked on needing xz 5.6.1 to be in debian unstable.

Ah, the good ol’ lever of urgency. Urgency frequency smells of deception.

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

#412

Post by withinboredom »

ToneWashed wrote: post #410
withinboredom wrote: post #396

Earlier quoted context omitted.

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…

> Have you considered reaching out to the maintainers of that project and (politely) asking them to explain?

That's kind of a catch-22, right? They'd explain with a seemingly good answer if they did it for actual reasons. They'll still explain with a seemingly good answer if they did it for nefarious reasons.

I don't have a good answer to this except to monitor this dependency and its changes.

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

#413

Post by greyface- »

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

Earlier quoted context omitted.

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 guid…

I'm not claiming the attempt didn't succeed. I'm claiming that the attempt didn't occur, and that distributing the backdoor more widely would only have created the preconditions for an attempt. We don't know who the intended target was, or what the intended payload was.

Yes, subsection (b) of the CFAA covers attempts at acts described in subsection (a) of the CFAA. Which specific act under subsection (a) do you claim has been attempted?

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

#414

Post by xvector »

eklitzke wrote: post #302
xvector wrote: post #286

Earlier quoted context omitted.

He used ProtonMail. I wonder if ProtonMail can pull IP logs for this guy and share them.

It might be worth looking into, but: 1) Probably by design protonmail doesn't keep these kinds of logs around for very long 2) Hacking groups pretty much always proxy their connection through multiple layers of machines they've rooted, making it very difficult or impossible to actually trace back to the original IP

For [1], unfortunately it does.

True regarding the second point.

[1]: https://techcrunch.com/2021/09/06/protonmail-logged-ip-addre...

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

#415

Post by gus_ »

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 EDR would have detected an inbound connection to port 22. Then it'd have detected the attacker's activity (opened files, executed commands, etc)

If the EDR is capable of intercepting the forks, clone() execves, open(), etc, then you can follow the traces. If it's able to deny certain activity based on rules like modifying /etc/ld.so.preload or download files with curl/wget, it'd have made the attacker's life a bit more difficult.

If the attacker loaded a rootkit, then probably you'd have lost visibility of what the attacker did after that. Also not all the EDRs hook all the functions, or they have bugs, so many times you are not able to follow a trace (without pain/guessing).

This telemetry usually is sent to a remote server, so the attacker could not have deleted it.

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

#416

Post by throw156754228 »

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…

They removed the repo so only the attackers had access to the code and know how.

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

#417

Post by verytrivial »

davikr wrote: post #74
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!

Lasse Collin is not Jia Tan until proven otherwise.

Speaking only hypothetically, but two points:

1) No-one has been is proven to "be" anyone in this case. Reputation is OSS is built upon behaviour only, not identity. "Jia Tan" managed to tip the scales by also being helpful. That identity is 99% likely to be a confection.

2) People can do terrible things when strongly encouraged or worse coerced. Including dissolving identity boundaries.

The first problem can be 'solved' by using real identities and web of trust but that will NEVER fly in OSS for a multitude of technical and social reasons. The second problem will simply never be solved in any context, OSS or otherwise. Bad actors be bad, yo.

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

#418

Post by andybak »

throw156754228 wrote: post #416
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…

They removed the repo so only the attackers had access to the code and know how.

No. They obviously didn't do that so you're just being sarcastic but not actually making any point of your own in addition to that.

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

#419

Post by wholinator2 »

withinboredom wrote: post #412
ToneWashed wrote: post #410

Earlier quoted context omitted.

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

> Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? That's kind of a catch-22, right? They'd explain with a seemingly good answer if they did it for actual reasons. They'll still explain with a seemingly good answer if they did it for nefarious reasons. I don't have a good answer to this except to monitor this dependency and its changes.

Is it possible that it was added by a bad actor, and that most of the individuals in contact will not have signed off on it? I mean, this whole thing started by an interested party digging deeper than anyone else had, you could trigger that for someone else. At the very least, what do you have to lose? If the best they can do is look like they're fine, then every possible side effect is to root up a frighteningly well hidden inflator

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

#420

Post by sofixa »

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…

> 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 could just as easily be a lone wolf capable of writing in different styles (really not difficult if one spends enough time online, one gets exposed to all sorts of styles) or even just your run of the mill criminal gang.

In fact, "multiaccount" cheating (where a single person has multiple accounts that interact with one another in a favourable manner, e.g. trading for stuff for reduced fees, or letting themselves be killed to pad stats, or expressing opinions leaving the impression of mass support, etc.) has been present in many MMO games for more than a decade. I recall an online game I was really into back in high school, eRepublik, which simulated real world politics, economics and warfare (in a really dumbed down version of course), and multiacounts were especially prevalent in politics, where candidates for election would often be padded by fake groups, or even entire countries being taken over by a gang of real people with like ten accounts each.

The complexity is nothing new. The only indicator this could be a state actor is the long con aspect of it. The attacker(s) were looking into years between starting and actually being able to exploit.

Post reply on HN