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

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

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

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