Non-Corporate Authentication Key

About Non-Corporate Authentication Keys

Secure Shell (SSH) is a communication protocol used to establish a secure connection with a remote computer. By default, SSH encrypts all communications between a server and a client, making it an ideal choice, even for insecure networks.

There are different ways to authenticate users while performing an SSH login. The simplest is via passwords, which are easy to use and set up, but not the most reliable authentication method. A safer alternative is to use SSH key pairs.

An SSH key pair consists of a private and a public key. Each pair is cryptographically generated, such that messages encrypted with the public key can only be decrypted using the private key. The private key is stored on the client machine and must be kept secret at all times.

The public key is stored in a special file on the remote server, known as the authorized_keys file. As the name indicates, this file contains the public keys of all the authorized users who can access the remote server. Typically, whenever a new public key is added, the creator’s username and email is appended to the file as a comment.

Once a user’s public key has been installed on a remote server, they can use the ssh command to log in without having to enter a password. Behind the scenes, the server tests whether the client has the appropriate private key.

Cloud Risk Description

Even though SSH keys are intrinsically more secure than passwords, their installation needs to be carefully managed and monitored. If a malicious actor succeeds in copying their own public key to the authorized_keys file, they will then have the persistent ability to log in.

Illegitimately added keys usually have non-corporate usernames and email addresses. This is why it’s important to periodically scan the authorized_keys file for non-corporate entries.

How Does Orca Help?

Orca scans your entire cloud estate for exposed keys, passwords in shell history, vulnerabilities, and other information that an attacker can leverage to move laterally in your environment. Orca looks for the use of non-corporate account keys and will alert on this type of issue as shown in the screenshot above.

• Discover and prioritize cloud IAM risk Find out more about Non-corporate Authentication Keys Found in the “authorized_keys” file

Related Risks

• Unused SSH keys can be exploited by cybercriminals to gain unauthorized access to a server.
• Numerous vulnerabilities have been detected in the underlying encryption algorithms used in older versions of the SSH protocol.
• In SSH 2.0 and older, the host key isn’t checked when connecting to localhost. Malicious actors can corrupt the DNS cache of the client and secretly reroute connections to the local host.

Recommended Mitigation Strategies

• Restrict SSH

  Use /etc/ssh/sshd_config to restrict SSH for certain users or user groups.

• Restrict permissions

  Restrict file permissions of the authorized_keys file. Ideally, only administrators should have access to it.

• Monitor

  Detect changes to the authorized_keys and /etc/ssh/sshd_config files, and keep monitoring for any suspicious behavior.

• Remove non-corporate authentication keys

  Remove any non-corporate authentication keys from the authorized_keys file.

Useful Links

• SSH key basics: https://www.ssh.com/academy/ssh/ssh-key-basics
• How to set up SSH keys: https://www.cyberciti.biz/faq/how-to-set-up-ssh-keys-on-linux-unix/
• SSH-Keygen: https://www.ssh.com/academy/ssh/keygen
• Best practices for the authorized_keys file: https://www.ssh.com/academy/ssh/authorized-keys-file
• Public and private key cryptography: https://www.preveil.com/blog/public-and-private-key/
• SSH security vulnerabilities: https://www.cvedetails.com/vulnerability-list/vendor_id-120/product_id-202/SSH-SSH.html