-
Notifications
You must be signed in to change notification settings - Fork 71
SKA security advisory: SSH port redirection attack
A design flaw was identified in the SSH Key Authority key synchronization component. Aside from SSH host key verification, SKA did not perform any further verification that it had connected to the correct server when syncing keys to a server. A malicious server administrator could use SSH port redirection (eg. via iptables) to sync the keys for their server to another server of their choosing, and since server administrators can reset the SSH host key for their own server in SKA, the sync to the wrong server would be allowed to go ahead.
Horizontal privilege escalation.
To exploit this flaw, the user must be a server administrator for an actively synced server registered in SKA.
By exploiting this flaw, the user could gain SSH access on another server that is either:
- Managed through SKA
- Set up to be managed through SKA, but not currently registered with it
Commit c184b031 introduces several new configuration options to address this issue, some of which are enabled by default as an immediate measure, and others which are recommended as better long-term solutions.
The first new option, which is enabled by default, prevents server administrators from resetting the SSH host key of their own server. Only full SKA admins will be able to reset any host keys. This can be an inconvenience if you have a large number of VMs that are often reinstalled by their owners. In such cases, if you have deployed the other protective measures below, you may wish to consider disabling this option.
This option, enabled by default, prevents key synchronization from proceeding in any cases where multiple servers share the same SSH host key. The sync will be reported as a failure, and the list of servers sharing the same host key will be displayed on the server's page. This provides a good defence against attacks aimed at any servers registered in your SKA install, however you will need to make sure that none of your servers currently share the same SSH host key.
Hostname verification is a supplement to SSH host key verification for making sure that the sync process has connected to the server that it expected to. It can either be configured to check against the server's own hostname (as found by hostname -f) or to check against a pre-defined .hostnames file in /var/local/keys-sync/. Further details about the available hostname verification modes can be found in the config/config-sample.ini file.
The latter option provides the most solid protection of all, as it requires explicit opt-in on the server itself for being synced to via the hostname that it is known as in SKA.
We recommend that you upgrade and enable host key reset restriction and host key collision protection immediately (and these will be enabled by default on upgrade unless specified otherwise in the config file). It is also recommended that you investigate the hostname verification options and choose the verification method that works best for your infrastructure.
- Discovered and reported by Tobias Josefowitz of Opera Software.
- Mitigation advice by Tobias Josefowitz and Michael Markevich of Opera Software.