Press "Enter" to skip to content

Infrastructure Hacking: SSH Protocol

Last updated on November 9, 2020

This is the second post in the new section of the website where I will explain in detail a specific protocol and show examples of different ways to exploit different vulnerable implementations. To make these posts I have used as an example implementations that can be found in the hackthebox.eu, as well as Ippsec videos.

The Secure Shell protocol allows remote access to a server via a secure channel where all information is encrypted. By default it runs on port 22.

image: ssh.com

The two main forms of authentication are password authentication and public key authentication.

Password authentication

This is the basic authentication, which is performed by the following command:

ssh user@server

Authentication by public key:

A public (id_rsa.pub) and a private key (id_rsa) pair are generated on the server. The public key is saved in the authorized keys section (in linux, it is saved in the authorized_keys file in the .ssh folder in the user’s home).

The private key id_rsa is given to the user who will access it anonymously.

In this way, it is enough to give the private key when accessing by ssh to be able to enter without entering the password:

A server can be configured so that it can only be accessed by public key, as we can see in the following example:

This may give us a hint, since Amazon EC2 servers usually have this configuration by default.

Create public and private key to access a server

If we have access to the home page of a box that runs ssh, we can generate a public and private key, create an .ssh folder in the user’s home page, create a file called authorized_keys with the public key, and access it using the private key:

In this case dali-la is the private key and dali-la.pub is the public key.

We copy and paste it into the .ssh folder of the dali user’s home (in this case using a limited php shell we had):

Now we only have to give 600 permissions to the private key and access it using ssh:

Cracking SSH key

If we have an encrypted id_rsa like this

We can try to decipher it with the John TheRipper tool.

First we modify the format to one that JohnTheRipper understands with the sshng2john.py script that you can download here.

Then we just have to pass it to John with the dictionary we want to use:

After that we only have to assign permission 600 to the file and log in by entering the passphrase of the id_rsa:

It is important to assign permission 600 to the file because if the file has more permissions than necessary, an error will appear:

Obtain private key from public key

There is a vulnerability in RSA, and that is that if you use two primes that are too small to generate the public and private keys, then it is possible to find them out and generate the private key from the public one.

To understand this in detail, it is necessary to have a thorough understanding of the asymmetric cryptography algorithm RSA, and to understand how the public and private keys are generated. In the future I could write a cryptography post explaining it in detail.

We will start from having a public key, like the following one:

We then run the tool RsaCtfTool

Now we just have to copy the private key, give it permissions and log in:

Banner Leak

It is important to pay attention to the banner that returns ssh when we connect. Let’s look at this example where we have launched nmap:

We can see that the SSH service opened on port 2222 reveals that the server is Ubuntu. But it also reveals us the last applied OpenSSH patch, 4ubuntu2.2.

If we search for this information in google, we can find out when this patch was released:

This information can be very valuable in the future in case we can use some kernel exploit.

Bruteforce

We can try to access through ssh using brute force to find out the credentials. For this we can use the hydra tool:

User Enumeration

We can try to list users with the following script:

https://github.com/BlackDiverX/ssh-user-enumeration

Add an old Key Exchange Algorithm

Sometimes a server needs to use some old key exchange algorithm that is not usually offered by default. In those cases, we will receive an error similar to this one:

In these cases what we must do is add some of the algorithms that the server offers us, for example the last one, by means of the parameter -okexAlgorithms=+diffie-hellman-group1-sha1:

SSH via IPv6

Sometimes a server may have the iptables configured so that access via ssh is not possible. However, this only works for IPv4, so you may be able to access it via IPv6.

For this we only need to know the IPv6 of the server:

And connect as we usually would but using that IPv6, with password or private key:

Allow SSH Connection

A server may have the ssh connection disabled by default:

But if we can somehow edit the content of the “/etc/ hosts.allow” file, then we can allow the connection by adding two lines:

And now we can connect without any problem:

I hope that all this information has been useful to you. I haveThere are many more attack vectors and ways to compromise the security of the SSH protocol that you can find here.

Lethani.

2 Comments

  1. […] In fact, the SSH protocol was created specifically to replace Telnet and provide a secure alternative for server maintenance and management. Since decades Telnet has been replaced by Secure Shell. If you want to discover the main SSH vulnerabilities and how to use this protocol to your advantage during pentesting, I recommend that you take a look at this post. […]

Leave a Reply

Your email address will not be published. Required fields are marked *