Misconfigured SSH Keys
SSH is a protocol that allows users to securely manage a system remotely. It is widely used because of its ease of use and built-it security. Users can transfer files securely via the SSH protocol if desired. Generally, the SSH protocol requires a user to present a username and password to authenticate.
A more secure option includes the use of something called SSH Keys. SSH keys consist of a public and private cryptographic key. They are randomly generated using high levels of entropy. When a user attempts to login to a computer via SSH keys, the server will first check the ~/.ssh/authorized_keys file to check if the public key is allowed to authenticate. After it is confirmed it is in the file, the server will generate a random string, then encrypt it with the public key. The random encrypted string can only be decrypted with the private key the user holds locally. The message is decrypted and sent back to the server which then checks to see if the random string is the same.
The reason SSH keys are more secure than typical passwords is because they are harder to brute force. A 1024-bit SSH key is the equivalent of using a truly random 12-character password. A 2048-bit key is the equivalent of using a truly random 16-character password. There are pros and cons to using SSH keys. One of the important things to keep in mind when using SSH keys is to set the correct permissions on the file and use a password to protect the SSH key. A lot of users don’t use a password to protect their SSH keys so if the SSH keys are compromised, anyone with the keys can authenticate to the remote server.
How can this be useful to an attacker in terms of privilege escalation? Let’s say the system administrator has a username of admin and allows remote login via SSH using SSH keys. The administrator has sudo access, and has added their public SSH key to the /home/admin/.ssh/authorized_keys file. If the permissions on the authorized_keys file allows write access by anyone, we could add in our own SSH public key and authenticate to the server as the admin user. Let’s see this in action:
After we have initial access to the machine, we check the permissions on the authorized_keys file:
user@target:$ ls -la-rw------- 1 admin admin 1876 Mar 28 09:53 id_rsa-rw-r--r-- 1 admin admin 408 Mar 28 09:55 id_rsa.pub-rw-rw-rw- 1 admin admin 444 Mar 28 11:57 authorized_keys
We notice the authorized_keys file has read/write permissions for all users. So, on our attacking machine, we generate a new SSH key pair:
root@kali:~# ssh-keygen -t rsa -b 4096We then copy the contents of the ~/.ssh/id_rsa.pub file we just created into the authorized_keys file on the remote host.
The server now trusts our SSH Key. From our attacking machine, we SSH to the remote host as the admin user using our new keys:
root@kali:~# ssh admin@192.168.56.101The server should authenticate us as the admin user. Since this user is a part of the sudoer’s group, we can elevate our privileges to the root user:
admin@target:$ whoamiadminadmin@target:$ sudo supassword for admin:root@target:$ iduid=0(root) gid=0(root) groups=0(root)
There are other attacks that can be used against misconfigured SSH keys. If a private key is readable by anyone, this key can be copied to authenticate to any servers that have the key pair added to its trusted list. This is why it is always important to put a password on your SSH keys so even if they are compromised, they will be unusable without the password.
