Skip to content

Better sanitization of SSH keys

The command ssh keys add does accept simple commands that may arise some security concern.

Originally reported by a customer. Not sure I can name them nor put a link to the ticket, but you can see it by searching this issue link in the ticketing system. There's some screenshots there.

Threat model

A SSH key was added into the CryptOps shell before the attack took place.

Possible scenario: A leaked SSH private key that can only be replaced in a lapsed time after an individual/organisation being hit by a cyberattack.

Issues

  1. The ssh keys add command accepts more than 3 parameters, the first one should be key type, second should be the public key itself, and the third one should be optional and the comment of the key itself, which leads to potential execution of one or more arbitrary command

  2. The ssh keys add command cannot accept long keys input like ssh-rsa AAA which directly leads to failure of missing ssh-key error.

  3. First time adding a secondary SSH key will leads to combining the second key into the first key item, which results the key ID 1 contains two cryptops client command instead of 2 key ID to contain 1 command each.

  4. A logged in session of Cryptops shell can remove ALL key IDs, possibly resulting an unusable shell afterward (not yet tested)

Reproduction steps

Steps to reproduce:

  1. Login into CryptOps shell via SSH with one(1) default SSH key added by the system

  2. Type in command ssh keys add ssh-ed25519 AA...

  3. Type in command ssh keys list to see the keys combined together

  4. Type in command ssh keys add ssh-ed25519 AA...; echo Hello world!

  5. Type in command ssh keys list to see a second key ID being created with that arbitrary command embedded following to the cryptops client command