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

191–200 of 500 posts

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

#191

Post by beefnugs »

pixl97 wrote: post #32
jobs_throwaway wrote: post #17

Imagine how frustrating it has to be for the attacker to meticulously plan and execute this and get foiled so late in the game, and so publicly

So who's started scanning open source lib test cases for more stuff like this?

Like everything else in this world, its utterly and completely unfixably broken: There is no way you can have complex huge dependencies properly.

The best most paranoid thing is to have multiple networking layers hoping they have to exploit multiple things at once, and whitelist only networking for exactly what you are expecting to happen. (which is completely incompatible with the idea of ssl, we would need a new type of firewall that sits between ALL applications before encryption, like a firewall between applications and the crypto library itself, which breaks a bunch of other things people want to do)

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

#192

Post by teddyh »

PhilipRoman wrote: post #188
teddyh wrote: post #177

Earlier quoted context omitted.

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

That would be possible, yes, but it’s not the current situation. And since we can choose how we proceed, I would prefer my proposal, i.e. that the SSH daemon be split into two separate projects, one daemon handling the initial connection, locked-down like you describe, then handing off the authenticated connection to the second, “inner”, SSH daemon, which also does the authentication, using the same credentials as submitted by the connecting user. This way, the connecting user only has to have one key, and the network topology does not become unduly twisted.

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

#193

Post by bevekspldnw »

est31 wrote: post #59
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.

I doubt that if Google detected it with some internal tool, they'd reach out to Microsoft to hide their contribution. It was reported by an MS engineer who happens to be involved in another OSS project. MS is doing business with the US intelligence community, for example there is the Skype story: First, rumors that NSA offers a lot of money for people who can break Skype's E2E encryption, then MS buys Skype, then MS…

“Even if it was the NSA, why would they hide that capability”

Perhaps you’re not familiar with what NSA historically stood for: Never Say Anything.

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

#194

Post by bevekspldnw »

timmytokyo wrote: post #132
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'm not sure why everyone is 100% sure this was a state-sponsored security breach. I agree that it's more likely than not state-sponsored, but I can imagine all sorts of other groups who would have an interest in something like this, organized crime in particular. Imagine how many banks or crypto wallets they could break into with a RCE this pervasive.

Motive and patience. Motive as you point out is shared by many parties.

Typically its only state agencies that will fund an operation with uncertain pay off over long periods of time. That type of patience is expensive.

Online criminals are beholden to changing market pressures and short term investment pressures like any other start up.

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

#195

Post by [deleted] »

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…

[deleted]

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

#196

Post by deepbreath »

delusional wrote: post #190
GabeIsko wrote: post #175

Earlier quoted context omitted.

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

> At the point an attacker has remote code execution

The attacker doesn't have remote code execution in the xz case unless they can speak to your port 22. Port knocking prevents them from doing so, provided they don't know how to knock.

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

#197

Post by e_y_ »

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 through obscurity is only a problem if obscurity is the main defense mechanism. It's perfectly fine as a defense-in-depth. This would only be an issue if someone did something stupid like set up a passwordless rlogin or database server expecting port knocking alone to handle security.

Also as pointed out elsewhere, modern port knocking uses Single Packet Authorization which allows for more bits. It's also simpler and uses a different mechanism than ssh (which due to its age, has historically supported a bunch of different login and cryptography techniques), which reduces the chance that an attacker would be able to break both.

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

#198

Post by PhilipRoman »

teddyh wrote: post #192
PhilipRoman wrote: post #188

Earlier quoted context omitted.

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

That would be possible, yes, but it’s not the current situation. And since we can choose how we proceed, I would prefer my proposal, i.e. that the SSH daemon be split into two separate projects, one daemon handling the initial connection, locked-down like you describe, then handing off the authenticated connection to the second, “inner”, SSH daemon, which also does the authentication , using the same credentials as s…

Huh, I briefly looked at the documentation for UsePrivilegeSeparation option and it looks very similar to what you're describing. Interesting why it didn't prevent this attack.

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

#199

Post by bpfrh »

marcus0x62 wrote: post #186
bpfrh wrote: post #137

Earlier quoted context omitted.

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

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

If you read my full sentence in the context it stands, I argue that authorizing access to your openssh instance is done by sending an authentication code in cleartext.

It does not matter if that authentication code is in the form of bits, tcp pakets, colors or horoscopes as long as your transmit that in clear text it is in fact no a secure mechanism.

Yeah but now you basically have to always run an vpn that only exists between your server and your client, because otherwise your clear text authentication code is visible and at that point just use wireguard and make a 1-1 tunnel only for ssh with no known attacks, even if the attacker is in the same network.

Yes a vpn that has no known reliably attack vector is definitely better than a protocol with a known working attack vector

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

#200

Post by trelane »

godman_8 wrote: post #167
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…

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…

I've seen this discussed a fair bit, and always the recommendation is to use wire guard and expose ssh only to the "local network" e.g. https://bugs.gentoo.org/928134#c38

First, I don't see how this works where there's a single server (e.g. colocation).

Second, doesn't that just make Wireguard the new hack target? How does this actually mitigate the risk?

Post reply on HN