[plg94]

I don't think we know what exactly this does, yet. I can only answer one of those questions, as far as I understand the "unreplayable" part is refering to this:

> Apparently the backdoor reverts back to regular operation if the payload is malformed or *the signature from the attacker's key doesn't verify*.

emphasis mine, note the "signature of the attacker's key". So unless that key is leaked, or someone breaks the RSA algorithm (in which case we have far bigger problems), it's impossible for someone else (researcher or third-party) to exploit this backdoor.

[cryptonector]

It's not using RSA. It's hooking RSA. And the attacker's signature is Ed448, not RSA.

[rmi_]

> So unless that key is leaked

But, just for replayability, we could "patch" the exploit with a known key and see what it does, don't we?

[swid]

Replayability means something different in this context. First, we do know the backdoor will pass the payload to system, so in general it is like an attacker has access to bash, presumably as root since it is sshd.

Replayability means, if someone were to catch a payload in action which did use the exploit, you can’t resend the attacker’s data and have it work. It might contain something like a date or other data specific only to the context it came from. This makes a recorded attack less helpful for developing a test… since you can’t replay it.

[tialaramex]

> It might contain something like a date or other data specific only to the context it came from.

In all these modern protocols, including SSHv2 / SecSH (Sean Connery fans at the IETF evidently) both parties deliberately introduce random elements into a signed conversation as a liveness check - precisely to prevent replaying previous communications.

TLS 1.3's zero round-trip (ORT) mode cannot do this, which is why it basically says you'd better be damn sure you've figured out exactly why it's safe to use this, including every weird replay scenario and why it's technically sound in your design or else you must not enable it. We may yet regret the whole thing and just tell everybody to refuse it.

[usrusr]

What could be done, I think, is patch the exploit into logging the payload (and perhaps some network state?) instead of executing it to be able to analyse it. Analyse it, in the unlikely case that the owner of the key would still try their luck using it after discovery, on a patched system.

What it does: it's full RCE, remote code execution, it does whatever the attacker decides to upload. No mystery there.

[chii]

> see what it does

it does whatever the decrypted/signed payload tells the backdoor to execute - it's sent along with the key.

The backdoor is just that - a backdoor to let in that payload (which will have come from the attacker in the future when they're ready to use this backdoor).

[superb_dev]

This feels very targeted

[Ekaros]

Or very untargeted. Something intended just to lay dormant by chance if succeeded...

It is very good backdoor to have if you at whatever time have dozens of options. See sshd running, test this you are done if it works, if not move to something else.

[dools]

Or targeted not really at doing anything but at researching the nature of supply chain vulnerabilities themselves.

[takeda]

This doesn't look like a research.

This looks like state sponsored attack. Imagine having a backdoor that you can just go to any Linux server and with your key you can make it execute any code you wish without any audit trail. And no one without the key can do it, so even if your citizens use such vulnerable system other states won't be able to use your backdoor.

[cjbprime]

Spending two years actually maintaining an open source project that you will later backdoor is a very expensive way to perform such research.

[yencabulator]

Untargeted (backdoor goes almost everywhere), but very selective (backdoor can only be triggered by the original attacker).

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

[BlueFalconHD]

It would be really cool if in 20 years when we have quantum computers powerful enough we could see what this exploit does.

[denysvitali]

My understanding is that we know somehow already what the exploit allows the attacker to do - we just can't reproduce it because we don't have their private key.

Technically, we can modify the backdoor and embed our own public key - but there is no way to probe a random server on the internet and check if it's vulnerable (from a scanner perspective).

In a certain way it's a good thing - only the creator of the backdoor can access your vulnerable system...

[tialaramex]

It's a NOBUS (Nobody But Us can use it) attack. The choice to use a private key means it's possible that even the person who submitted the tampered code doesn't have the private key, only some other entity controlling them does.

[kortilla]

We do know what it does. If it decrypts it just passes to system().

[password4321]

AFAIK still no luck with Gauss from 2012

https://securelist.com/gauss-abnormal-distribution/36620/

[cryptonector]

I don't understand yet where the "unreplayable" part comes from, but this isn't it.

[yencabulator]

Replayable: You observe attack against server A, you can take that attack and perform it against server B.

This attack is unreplayable because it cryptographically ties into the SSH host key of the server.

[cryptonector]

I know what replayable means. But even with your explanation of what makes it unreplayable it's not strictly true: you could replay the attack on the server it was originally played against.

[yencabulator]

Sure. But the interest is in being able to talk to server B to figure out if it's vulnerable; that's impossible, because the attack can't be replayed to it.

[cryptonector]

Thanks.