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

171–180 of 500 posts

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

#171

Post by kelnos »

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…

I don't think I agree. This backdoor means that it doesn't matter how long your key lengths or cryptographic key sizes are; that's kinda the point of a backdoor. But an automated attempt to find servers to exploit is not going to attempt something like port knocking, or likely even looking for a sshd on a non-standard port.

Kerckhoff's law goes (from your link):

> The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.

With this backdoor, that principle does not hold; it's utterly irrelevant. Obscuring the fact that there even is a ssh server to exploit increases safety.

(I dislike port knocking because of your third point, that it complicates access. But I don't think your assertions about its security principles hold water, at least not in this case.)

(Ultimately, though, instead of something like port knocking or even running sshd on a non-standard port, if I wanted to protect against attacks like these, I would just keep sshd on a private network only accessible via a VPN.)

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

#172

Post by reaperman »

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…

Security-by-obscurity is dumb, yes. But in the context of supply-chain exploits in the theme of this xz backdoor, this statement is also myopic:

> 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 your sshd (or any other exposed service) is backdoored, then the "effective bits" of any cryptographic key size is reduced to nil. You personally cannot know whether or not your exposed service is backdoored.

Bottom-line is: adding a defense-in-depth like port knocking is unlikely to cause harm unless you use it as justification for not following best-practices in the rest of your security posture.

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

#173

Post by rcaught »

loeg wrote: post #134

> The ciphertext is encrypted with chacha20 using the first 32 bytes of the ED448 public key as a symmetric key. As a result, we can decrypt any exploit attempt using the following key: Isn't this wild? Shouldn't the ciphertext be encrypted with an ephemeral symmetric key signed by the privkey? I guess anyone with the public key can still read any payload, so what's the point?

That action would create extra noise.

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

#174

Post by TheBlight »

AtNightWeCode wrote: post #133
TheBlight wrote: post #60

Earlier quoted context omitted.

Everyone keeps saying this but it seems unlikely to me that they'd do this for a relatively short window of opportunity and leave their methods for all to see.

My guess is that a ransomware group is behind this. Even if the backdoor had gone into production servers it would have been found fairly quickly if used at some scale.

>My guess is that a ransomware group is behind this.

My bet would be that they were after a crypto exchange(s) where they've already compromised some level of access and want to get deeper into the backend.

>Even if the backdoor had gone into production servers it would have been found fairly quickly if used at some scale.

I agree. Yes it's possible the backdoor could've gone unnoticed for months/years but I think the perp would've had to assume not.

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

#175

Post by GabeIsko »

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…

I wouldn't really consider port knocking to be that effective of a way to block connections. It is really only obscure, but port knocking software is very accessible. So if you know a port needs to be knocked, it's not hard for an attacker to get to it.

The main benefit of port knocking is that it allows you to present your ports as normally closed. If you have a system and you are worried about it getting port scanned for whatever reason, it makes sense to have a scheme where the ports are closed unless it receives a knock. So if someone gets access they shouldn't for whatever reason and pulls a portscan off, the information they get about your system is somewhat limited.

In this scheme, it would be much better to have an access point you authenticate with and then that handles the port knocking for the other devices. So it is a kind of obscure method that is really only useful in a specific use case.

As far as SSH keys go, I would argue that SSH support is so ubiquitous, and SSH access is so powerful that it is a reasonable security tradeoff. I also don't think that SSH ports should be exposed to the internet, unless it is a specific use case where that is the whole point, like GitHub. I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion.

I personally don't know any application where you really need supreme admin access to every device, from any device, from anywhere in the world, while at the same time it has extreme security requirements. That's a pretty big task. At that point, constructing a dedicated, hardened access point that faces the internet and grants access to other devices is probably the way to go.

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

#176

Post by TheBlight »

avidiax wrote: post #85
TheBlight wrote: post #60

Earlier quoted context omitted.

Everyone keeps saying this but it seems unlikely to me that they'd do this for a relatively short window of opportunity and leave their methods for all to see.

You are judging this by the outcome, as though it were pre-ordained, and also assuming that this is the only method this agency has. It is much more likely that this backdoor would have gone unnoticed for months or years. The access this backdoor provides would be used only once per system, to install other APT (advanced persistent threats), probably layers of them. Use a typical software RAT or rootkit as the first…

It was found in a few weeks so why is it more likely it wouldn't have been noticed for months/years with more people running the backdoored version of the code?

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

#177

Post by teddyh »

VWWHFSfQ wrote: post #170
teddyh wrote: post #165

Earlier quoted context omitted.

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.

Many people argue that a VPN+SSH is a reasonable solution, since it uses two separate implementations, where both are unlikely to be compromised at the same time. I would argue that the more reasonable option would be to split the SSH project in two; both of which validates the credentials of an incoming connection. This would be the same as a VPN+SSH but would not convolute the network topography, and would eliminate the need for two keys to be used by every connecting user.

However, in this case, the two-layer approach would not be a protection. Sure, in this case the SSH daemon was compromised, and a VPN before SSH would have protected SSH. But what if the VPN server itself was compromised? Remember that the SSH server was altered, not to allow normal logins, but to call system() directly. What if a VPN server had been similarly altered? This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely.

It is a mistake to look at this case and assume that since SSH was compromised this time, SSH must always be protected by another layer. That other layer might be the next thing to be compromised.

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

#178

Post by RamRodification »

knoxa2511 wrote: post #28
acdha wrote: post #6

Has anyone tried the PoC against one of the anomalous process behavior tools? (Carbon Black, AWS GuardDuty, SysDig, etc.) I’m curious how likely it is that someone would have noticed relatively quickly had this rolled forward and this seems like a perfect test case for that product category.

Sysdig released a blog on friday. "For runtime detection, one way to go about it is to watch for the loading of the malicious library by SSHD. These shared libraries often include the version in their filename." The blog has the actual rule content which I haven't seen from other security vendors https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...

That relies on knowing what to look for. I.e. "the malicious library". The question is whether any of these solutions could catch it without knowing about it beforehand and having a detection rule specifically made for it.

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

#179

Post by nick238 »

TacticalCoder wrote: post #75
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…

> Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking. I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-kno…

The advantage of port knocking to me is just reducing the amount of garbage script-kiddie scans. IMHO the design of `sshd` needs to just assume it will be slammed by garbage attempts and minimize the logging. I've heard of `fail2ban`, but banning does nothing as the bots have an unlimited number of IPs.

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

#180

Post by stock_toaster »

aborsy wrote: post #156

Why ED448? It’s almost never recommended, in favor of curve 25519.

I believe ed25519 offers 128 bits of security, while ed448 offers 224 bits of security. ed448 has larger key sizes too, which does seem like an odd choice in this case. Maybe it was chosen for obscurity sake (being less commonly used)?
Post reply on HN