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

151–160 of 500 posts

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

#151

Post by meowface »

declan_roberts wrote: post #87
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.

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 access a huge swath of machines and also biding their time for a huge heist.

They have no reason to not restrict the backdoor to their personal use. And it probably is spycraft of some sort, and I think more likely than not it's a nation-state, but not necessarily. I could see a talented individual or group wanting to pull this off.

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

#152

Post by meowface »

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.

It's really interesting to think what might've happened if they could've implemented this with much less performance overhead. How long might it have lasted for? Years?

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

#153

Post by ajross »

toasteros wrote: post #58
yodsanklai wrote: post #37

Do we know who's the attacker?

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.

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

#154

Post by 7373737373 »

Alifatisk wrote: post #18
asveikau wrote: post #10

It's pretty interesting that they didn't just introduce an RCE that anyone can exploit, it requires the attacker's private key. It's ironically a very security conscious vulnerability.

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 read someone speculating that the performance issue was intentional, so infected machines could be easily identified by an internet wide scan without arousing further suspicicion.

If this is or becomes a widespread method, then anti-malware groups should perhaps conduct these scans themselves.

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

#155

Post by meowface »

jsmith99 wrote: post #52
stingraycharles wrote: post #38

Earlier quoted context omitted.

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.

The attacker changed the projects contact details at oss fuzz (an automated detection tool). There’s an interesting discussion as to whether that would have picked up the vulnerability https://github.com/google/oss-fuzz/issues/11760

That's a fascinating extra detail. They really tried to cover all their bases.

There's some plausible evidence here that they may've tried to use alter egos to encourage Debian to update the package: https://twitter.com/f0wlsec/status/1773824841331740708

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

#157

Post by noman-land »

shanemhansen wrote: post #106
noman-land wrote: post #93

Earlier quoted context omitted.

I'm a bit of a noob about this. Can you explain what this means?

Port knocking involves sending a packet to certain ports on a host. It's overkill but typing http://host:port/ in your browser will, as part of trying to make a TCP connection, send a packet to that port.

Thanks, I didn't realize port knocking could be done manually like this as a way to "unlock" an eventual regular ssh attempt outside the browser. This makes sense now and is super clever!

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

#158

Post by discite »

ulrikrasmussen wrote: post #94
mr_mitm wrote: post #73

Earlier quoted context omitted.

Note that port knocking is vulnerable to replay attacks. Single Packet Authentication is better, but requires a private key (can be your SSH key). https://www.cipherdyne.org/fwknop/

What if the knocking sequence was derived from a TOTP secret?

Definitely some fun project to try

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

#159

Post by mlyle »

mr_mitm wrote: post #73
jolmg wrote: post #56

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. If that's important, one should be able to set up port knocking such that you're able to do the knocks even by changing the port in a sequence by hand on e.g. a web browser address bar.

Note that port knocking is vulnerable to replay attacks. Single Packet Authentication is better, but requires a private key (can be your SSH key). https://www.cipherdyne.org/fwknop/

Naive knocking isn't good as a primary security mechanism, but it lowers your attack surface and adds defense in depth.

It means that people who can't intercept traffic can't talk to the ssh server-- and that's most attackers at the beginning phases of an attack. And even someone who can intercept traffic needs to wait for actual administrative activity.

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

#160

Post by belorn »

dec0dedab0de wrote: post #36

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to b…

Rather than port knocking, I prefer IP knocking. The server has several ip addresses and once a correct sequence of connection is made, the ssh port opens. Since so few know about IP knocking, it much safer than port knocking.

/s

Post reply on HN