6 ms·

Does not make sense. Why would a user upload a public key with a "command=" option? And, in any case, the command executes with the privileges of the user, so i

Does not make sense. Why would a user upload a public key with a "command=" option? And, in any case, the command executes with the privileges of the user, so it can do nothing that can't already be done by a normal command invocation.

PeterWhittaker 3y ago
Exactly the reason I’ve half considered flagging the article. You remember the old meme, 1. A thing 2. ??? 3. Profit! This is sort of like that: TFA skips over the part where the user is owned or conned by someone else. The honest headline would be “yet another clever malicious thing you can do once you compromise someone else’s accounts!” but I can see where that would get fewer clicks.
- hxugufjfjf 3y ago
  It's a persistence technique, see https://attack.mitre.org/tactics/TA0003/ https://attack.mitre.org/tactics/TA0003/
  - PeterWhittaker 3y ago
    Absolutely! In the meme, it would be step 3, profit/persist. You still need step 2, own. An even better headline, that would get even fewer clicks, would be "post compromise persistence technique using SSH authorized keys".
    - hxugufjfjf 3y ago
      Yes.
VitalKoshalew 3y ago
From my experience, almost nobody fully understands proper public key distribution practices. Usually, it all ends with "Please find my public key attached to this e-mail." - "Imported. You can log in." No fingerprint check via different means of communication (e.g. over phone) etc. I can imagine a scenario of an attacker being able to intercept and substitute such e-mail with an identical one that just has the attached public key modified to include the backdoor "command=" modification. There may be numerous other scenarios such as substituting a public key in a shared public key storage/database. Public keys are often treated as something totally harmless. It's assumed that the worst case scenario is that SSH connection will just fail if a public key was tampered with unless an attacker is also able to intercept and proxy actual SSH connection in real time (which is much more complex and much less feasible). The attack described should be taken very seriously. Entities that have shared public key repositories may need to review their practices and include an automatic check for "command=" in the public keys uploaded. Of course, proper procedures on SSH server end (such as visually inspecting a key before installing it while confirming the fingerprint over a different medium) should already prevent this attack from succeeding, but they likely rely on additional human intervention which is not always done in real life.
- jcarrano 3y ago
  That makes more sense, but then, in any case, you should be transmitting public keys over a medium that is authenticated in some form. Otherwise, an attacker could simple replace the key by theirs. The advantage of this method is that it works without supervision. If the attacker just replaced the key, they would have to attempt to login in the narrow window between installation and it being replaced because it does not work.

PeterWhittaker 3y ago

Exactly the reason I’ve half considered flagging the article. You remember the old meme, 1. A thing 2. ??? 3. Profit! This is sort of like that: TFA skips over the part where the user is owned or conned by someone else. The honest headline would be “yet another clever malicious thing you can do once you compromise someone else’s accounts!” but I can see where that would get fewer clicks.

hxugufjfjf 3y ago
It's a persistence technique, see https://attack.mitre.org/tactics/TA0003/ https://attack.mitre.org/tactics/TA0003/
- PeterWhittaker 3y ago
  Absolutely! In the meme, it would be step 3, profit/persist. You still need step 2, own. An even better headline, that would get even fewer clicks, would be "post compromise persistence technique using SSH authorized keys".
  - hxugufjfjf 3y ago
    Yes.

VitalKoshalew 3y ago

From my experience, almost nobody fully understands proper public key distribution practices. Usually, it all ends with "Please find my public key attached to this e-mail." - "Imported. You can log in." No fingerprint check via different means of communication (e.g. over phone) etc. I can imagine a scenario of an attacker being able to intercept and substitute such e-mail with an identical one that just has the attached public key modified to include the backdoor "command=" modification. There may be numerous other scenarios such as substituting a public key in a shared public key storage/database. Public keys are often treated as something totally harmless. It's assumed that the worst case scenario is that SSH connection will just fail if a public key was tampered with unless an attacker is also able to intercept and proxy actual SSH connection in real time (which is much more complex and much less feasible). The attack described should be taken very seriously. Entities that have shared public key repositories may need to review their practices and include an automatic check for "command=" in the public keys uploaded. Of course, proper procedures on SSH server end (such as visually inspecting a key before installing it while confirming the fingerprint over a different medium) should already prevent this attack from succeeding, but they likely rely on additional human intervention which is not always done in real life.

jcarrano 3y ago
That makes more sense, but then, in any case, you should be transmitting public keys over a medium that is authenticated in some form. Otherwise, an attacker could simple replace the key by theirs. The advantage of this method is that it works without supervision. If the attacker just replaced the key, they would have to attempt to login in the narrow window between installation and it being replaced because it does not work.