Hacker News Reader

Comment by miduil | Hacker News Reader

Super impressed how quickly the community and in particular amlweems were able to implement and document a POC. If the cryptographic or payload loading functionality has no further vulnerabilities, this would have been also at least not introducing a security flaw to all the other attackers until the key is broken or something.

Edit: I think what's next for anyone is to figure out a way to probe for vulnerable deployments (which seems non-trivial) and also perhaps possibly ?upstreaming? a way to monitor if someone actively probes ssh servers with the hardcoded key.

Kudos!

View on HN

Well, it's a POC against a re-keyed version of the exploit; a POC against the original version would require the attacker's private key, which is undisclosed.

It's a POC nevertheless, it's a complete implementation of the RCE minus obviously the private key.

It doesn't matter. The people with the private key already knew all of this because they implemented it. The script kiddies without the private key can't do anything without it. A POC doesn't help them in any way.

A way to check if servers are vulnerable is probably by querying the package manager for the installed version of xz. Not very sophisticated, but it'll work.

> It doesn't matter.

To understand the exact behavior and extend of the backdoor, this does matter. An end to end proof of how it works is exactly what was needed.

> A way to check if servers are vulnerable is probably by querying the package manager

Yes, this has been know since the initial report + later discovering what exact strings are present for the payload.

https://github.com/Neo23x0/signature-base/blob/master/yara/b...

> Not very sophisticated, but it'll work.

Unfortunately, we live in a world with closed-servers and appliances - being able as a customer or pen tester rule out certain class of security issues without having the source/insights available is usually desirable.

> we live in a world with closed-servers and appliances

Yeah but these servers and appliances aren't running Debian unstable are they? I'd understand if it affected LTS versions of distros, but these were people living on the bleeding edge anyway. Folks managing such servers are going to be fine running `apt-get update`.

We got lucky with this one, tbh.

Are you saying POCs are pointless unless a script kiddie can use it?

The context of the conversation, which you seem to have missed, is that now that we have a POC, we need a way to check for vulnerable servers. The link being that a POC makes it easier for script kiddies to use it, meaning we're in a race against them. But we aren't, because only one group in the whole world can use this exploit.

> is that now that we have a POC, we need a way to check for vulnerable servers.

You misunderstand me, the "need to check for vulnerable servers" has nothing to do with the PoC in itself. You want to know whether you're vulnerable against this mysterious unknown attacker that went through the all the hoops for a sophisticated supply chain attack. I never said that we need a way to detect it because there is a POC out, at least I didn't meant to imply that either.

> script kiddies to use it, meaning we're in a race against them

This is something you and the other person were suddenly coming up with, never said this in first place.

Could the provided honeypot print out keys used in successful and unsuccessful attempts?

I don't think any (sane) client would sent its private key on login. Private key only serves as a "solver" of a puzzle created using the public key.

Probing for vulnerable deployments over the network (without the attacker's private key) seems impossible, not non-trivial.

The best one could do is more micro-benchmarking, but for an arbitrary Internet host you aren't going to know whether it's slow because it's vulnerable, or because it's far away, or because the computer's slow in general -- you don't have access to how long connection attempts to that host took historically. (And of course, there are also routing fluctuations.)

Should be able to do it by having the scanner take multiple samples. As long as you don’t need a valid login and the performance issue is still observable, you should be about to scan for it with minimal cost

Looks like the slowdown is actually at sshd process startup time, not authentication time. So it's back to being completely impossible to network-probe for.

Reply on news.ycombinator.com