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

161–170 of 500 posts

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

#161

Post by TacticalCoder »

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.

> ... nd they’re just presenting the story like this to keep their detection methods a secret. It’s what I would do.

Basically "parallel construction". It's very possible it's what happened.

https://en.wikipedia.org/wiki/Parallel_construction

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

#162

Post by cesnja »

ametrau wrote: post #150
squigz wrote: post #82

Earlier quoted context omitted.

I wonder if one could combine port knocking and TOTP in some way, so the sequence is determined by the TOTP? (Security is not my thing; don't judge me!)

Yeah you could but wouldn’t it defeat the purpose of being basically a secret knock before you can give the password? The password should be the ssh password.

This would be just to allow you to connect to the server. If there was a vulnerable sshd on port 22, an adversary would have to know the port knocking sequence to connect to sshd and run the exploit.

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

#163

Post by btown »

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.

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 nation-state involvement, it certainly borrows from a wide-ranging playbook of techniques.

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

#164

Post by guyomes »

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.

Some of this activity was actually documented through the alleged data breach of a hacking company [1].

[1]: https://en.wikipedia.org/wiki/Hacking_Team

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

#165

Post by teddyh »

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…

Port knocking is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes manageable, adjust your logging levels.

The security of port knocking is also woefully inadequate:

• It adds very little security. How many bits are in a “secret knock”?

• The security it does add is bad: It’s sent in cleartext, and easily brute-forced.

• It complicates access, since it’s non-standard.

1. https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...>

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

#166

Post by pxx »

Denvercoder9 wrote: post #140
amluto wrote: post #107

Earlier quoted context omitted.

Not quite. It still looks vulnerable: an attacker A without the private key impersonates a victim server V and reports their host key. A careless attacker B with the key tries to attack A, but an ends up recovering a valid payload targeting V.

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.

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

#167

Post by godman_8 »

herpderperator wrote: post #42
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…

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…

My solution to this has been creating a public bastion server and use Wireguard. Wireguard listens on a random UDP port (port knocking is more difficult here.) This client is set up to have a dynamic endpoint so I don't need to worry about whitelisting. The key and port information are stored in a password manager like Vaultwarden with the appropriate documentation to connect. Firewall rules are set to reject on all other ports and it doesn't respond to ICMP packets either. A lot of that is security through obscurity but I found this to be a good balance of security and practicality.

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

#168

Post by strunz »

wolverine876 wrote: post #110

Have the heads of the targeted projects - including xz (Lasse Collin?), OpenSSH (Theo?), and Linux (Linus) - commented on it? I'm especially interested in how such exploits can be prevented in the future.

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...:

>Lasse regularly has internet breaks and is on one at the moment, started before this all kicked off. He has posted an update at https://tukaani.org/xz-backdoor/ and is working with the community.

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

#169

Post by AlexCoventry »

password4321 wrote: post #126
AlexCoventry wrote: post #109

Earlier quoted context omitted.

> say that port knocking is pointless and security theatre Who was saying that?

https://hn.algolia.com/?query=port%20knocking%20obscurity&ty... 20200515 https://news.ycombinator.com/item?id=23187662 etc.

Thanks.

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

#170

Post by VWWHFSfQ »

teddyh wrote: post #165
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…

Port knocking is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes manageable, adjust your logging levels. The security of port knocking is also woefully inadequate: • It adds very little security. How many bits are in a “secret knock”? • The securi…

Port knocking is definitely dumb, but "increase your password lengths, or cryptographic key sizes" does nothing if your ssh binary is compromised and anyone can send a magic packet to let themselves in.

Strict firewalls, VPNs, and defense-in-depth is really the only answer here.

Of course, those things all go out the window too if your TCP stack itself is also compromised. Better to just air-gap.

Post reply on HN