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

181–190 of 500 posts

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

#181

Post by nequo »

pajko wrote: post #44
herpderperator wrote: post #42

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

https://github.com/CERN-CERT/pam_2fa

This is great but would this neutralize the xz backdoor? The backdoor circumvents authentication, doesn't it?

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

#182

Post by MuffinFlavored »

acdha wrote: post #147
MuffinFlavored wrote: post #98

Earlier quoted context omitted.

How/why did the test data get bundled into the final library output?

That’s what the compromised build stage did. It’s really interesting to read if you want to see the details of how a sophisticated attacker works: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b... https://gynvael.coldwind.pl/?lang=en&id=782

> build-to-host.m4

I wasn't aware that the rogue maintainer was able to commit himself without any PR review (or he snuck it through PR review) rogue steps in the build process as well that went unnoticed so that he could bundle decompressed `xz` streams from test data, that also patched output .so files well enough to add hooking code to them.

How many "process failures" are described in that process that exist in every OSS repo with volunteer unknown untrusted maintainers?

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

#183

Post by rhaps0dy »

bpfrh wrote: post #148
tredre3 wrote: post #144

Earlier quoted context omitted.

You also add another program with potential vulnerabilities, and as port knocking is not as popular as e.g. sshd, wireguard, maybe it gets less scrutiny and it leads to a supply chain attack? That other program is just a stateful firewall, aka the Linux Kernel itself. If you can't trust your kernel then nothing you do matters.

That other programm is knockd, which needs to listen to all traffic and look for the specified packets. Granted, that program is really small and could be easily audited, but that same time could have been spent on trying apparmor/seclinux + a good vpn and 2fa

I much prefer the approach I read about in https://github.com/moxie0/knockknock (use a safe language, trust basically only the program you write and the language), to a random port daemon written in C which pulls libpcap to sniff everything.

To some extent knockknock also trusts the Python interpreter which is not ideal (but maybe OK)

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

#184

Post by throitallaway »

aborsy wrote: post #156

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

As I understand it Ed448 was only recently added to openssh, so maybe it was chosen in order to evade detection by analysis tools that scan for keys (if such a thing is possible.)

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

#185

Post by belorn »

reaperman wrote: post #172
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…

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

Chaining multiple different login system can make sense. A more sensible solution over port knocking would be an alternative sshd implementation with a tunnel to the second sshd implementation. Naturally the first one should not run as root (similar to the port knocking daemon).

That way it would not be in clear text, and the number of bits of security will be order of magnitude larger even with very simple password. The public facing sshd can also run more lightweight algorithms and disable loggings for lower resource usage.

Regardless if one uses two sshd or port knocking software, the public facing daemon can have backdoors and security bugs. If we want to avoid Xz-like problems then this first layer need to be significant hardened (With SELinux as one solution). Their only capability should be to open the second layer.

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

#186

Post by marcus0x62 »

bpfrh wrote: post #137
TacticalCoder wrote: post #75

Earlier quoted context omitted.

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

>It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks). So would have a vpn or using a bastion host with a custom non standard ssh implementation... At some point you have to make the choice to not implement a security measure and I would argue that should stop at vpn+standard software for secure access. If you are a bigger compa…

> Port Knocking doesn't add any security benefit in the sense that there are known non avoidable security risk aka your transmit your password(knocking) in clear text over the network.

This take is bordering on not even wrong territory. The point of port knocking isn't to increase entropy of your password or authentication keys per se, it is to control who can send packets to your SSH daemon, either to limit the noise in your logs or to mitigate an RCE in the SSH daemon. The vast majority of potential attackers in the real world are off-path and aren't going to be in a position to observe someone's port-knocking sequence.

Is VPN a better solution? Maybe, but VPNs, especially commercial VPNs have their own set of challenges with regard to auditability and attack surface.

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

#187

Post by teddyh »

kelnos wrote: post #171
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…

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

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

If we’re talkning about this specific backdoor, consider this: If the attacker had successfully identified a target SSH server they could reasonably assume had the backdoor, would they be completely halted by a port knocker? No, they would brute-force it easily.

Port knocking is very bad security.

(It’s “Kerckhoffs’s ”, by the way.)

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

#188

Post by PhilipRoman »

teddyh wrote: post #177
VWWHFSfQ wrote: post #170

Earlier quoted context omitted.

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

>This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely.

I don't know how VPNs are implemented on Linux, but in principle it should be possible to sandbox a VPN server to the point where it can only make connections but nothing else. If capabilities are not enough, ebpf should be able to contain it. I suspect it will have full control over networking but that's still very different from arbitrary code execution.

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

#189

Post by eli »

haswell wrote: post #16
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.

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.

More to the point it prevents your enemies from using the exploit against friendly targets.

The tradeoff is that, once you find it, it's very clearly a backdoor. No way you can pretend this was an innocent bug.

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

#190

Post by delusional »

GabeIsko wrote: post #175
herpderperator wrote: post #42

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

> I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion.

Did it? At the point an attacker has remote code execution, couldn't they just as easily pivot into an outgoing connection to some command and control server? I don't see how some intermediary access point would have alleviated this problem. If the call is coming from inside the house, the gig is already up.

Post reply on HN