Infraestructure Hacking: SSH Protocol – Part II

This is the continuation of last week’s post, which you can find here. I recommend that you take a look at it before continuing reading if you haven’t seen it yet.

In this post I’ll show you different methods that can be useful when it comes to vulnerating a server where the SSH protocol is running. I will also show you ways to use this protocol to your advantage in order to discover hidden services through techniques such as port forwarding.

Port Forwarding

With SSH it is possible to redirect ports. This is useful for pivoting and reaching machines that are out of reach. Let’s take a basic example:

Infraestructure Hacking: SSH Protocol - Part II

From our local machine we can connect to the machine 172.24.0.253 (from now on “ezra”) through port 22. From that machine it is possible to access the machine 172.24.0.2 through port 80, because it is in its local network. 

However, from our local machine we cannot access the machine 172.24.0.2, as it is not in our network.

Let us now assume that we have hacked the erza machine, and we want to hack the 172.24.0.2 machine.

From ezra we do not have the full set of tools that we have on our local machine to try and hack into. For example, nmap is not installed.

We could install them once we gain access as administrators, but this is not always possible, and would be very tedious. That’s what the Port Forwarding technique is for, which will allow us to redirect the traffic coming from our local machine to the 172.24.0.2 machine via the ezra machine.

Let’s look at the basic commands for doing this with ssh:

-L (Local)

With this method we listen in a port of our localhost, and whenever we send something there it will be redirected wherever we want, either locally or remotely.

Example: redirect the traffic we send on port 8081 of our localhost to port 80 of the server 172.24.0.2 via ezra

— (127.0.0.1:8081) => (172.24.0.2:80)

In ezra we execute the following command: -L 8001:172.24.0.2:80

On the local machine we check that port 8081 is listening:

Now if we open the browser on the local machine and enter 127.0.0.1:8001 we will be accessing the web page on port 80 of the server 172.24.0.2 through ezra

Note: We could execute this same command from our local machine with the following command: ssh -i id_rsa -L8081:172.24.0.2:80 172.24.0.253)

 

-R (Remote)

Ezra is listening in on a port, and forwards what he receives to the port we want from our local machine.

Example: ezra is listening on port 8002 and forwards what it receives to port 8003 on our local machine

— (SSH.Target:8002) => (127.0.0.1:8003)

In ezra we execute the following command: -R 8002:127.0.0.1:8003

Infraestructure Hacking: SSH Protocol - Part II

If we listen now on our local machine:

Infraestructure Hacking: SSH Protocol - Part II

And we send the traffic to ezra on port 8002:

Infraestructure Hacking: SSH Protocol - Part II

We see that whatever is received by ezra port 8002 is received by our local machine at port 8003:

Infraestructure Hacking: SSH Protocol - Part II

-D (Dynamic)

With this method we will manage to pivot both outgoing and incoming traffic. It would be like doing the Local and the Remote at the same time.

On erza we execute the following command: -D 1080

We can configure the proxychains program in the dynamic port we have created, and thus launch tools through the tunnel easily and quickly:

In this way we achieve our initial objective, to run nmap from our local machine to the 172.24.0.2 machine.

Port Forwarding on Windows

We can perform Port Forwarding in Windows using the plink program.

To do this, we indicate with -l the user we want to connect to via ssh, with -pw the password, then we indicate the type of port forwarding we want with the commands shown above, and finally the IP of the machine we want to connect to. By indicating port 2222 with -P we are indicating that the ssh service is running on that port. If we do not set anything by default it will assume that ssh is running on port 22.

In this case, traffic from port 8888 on the Windows machine is forwarded to port 8888 on our local machine.

Infraestructure Hacking: SSH Protocol - Part II

It should also be noted that for the connection to be possible we have to configure the ssh server on our local machine by modifying the /etc/ssh/ sshd_config file, since by default the root user cannot access it through ssh.

Detect a hidden SSH server

In the nmap results of this machine we can see that port 8888 is filtered:

This is interesting because it means that when nmap sends the packet to that port, it does not return anything. When a port is simply closed, it usually returns a response indicating this. When it doesn’t return anything, it means that there is some kind of firewall that is throwing off the packets we send.

Once we have managed to access the machine, we access it via ssh and check what is happening on port 8888 using the netstat tool:

Something interesting is happening. In the first line we see that the machine we are on (10.10.10.87) is listening on all the interfaces on port 8888, and in the second line we see that we ourselves (we are the ip 10.10.14.2) are connected to that port.
Given that the only connection we have with this machine is through ssh, that means that somehow by connecting us through ssh to port 22 of the machine, it is secretly reconnecting us to port 8888.

We can verify that this is true by creating another ssh connection and doing a netstat again:

By making an ipconfig we see that this machine has a docker:

Therefore we can assume that the logical scheme of what is happening would be 10.10.14.2:38734 -> 10.10.10.87:22 -> 172.17.0.1:8888

If on the machine 10.10.10.87 we try to make an nc on port 22, this banner appears:

However, the banner that appears when we connect from our machine is different:

This means that there is a hidden ssh server, and if we know the password or have the necessary private key, we can access that server:

Make a copy of a physical disk to the local machine using SSH and dd

In this example we copy the physical disk /dev/sda from the ip 10.10.10.111 using the SSH service:

It should be noted that this access via SSH has not required a password because we had the private key needed to enter 10.10.10.111 in the .ssh folder of the root user of our machine.

Perform a packet capture by ssh without touching the disk

We can use ssh to capture the machine’s traffic without even having to touch the disk. To do so, just execute the following command:

Note that it is necessary to set the rule “not port 22” in order not to capture the encrypted ssh traffic.

For example, in this case we get a user and password hash from LDAP when analyzing the traffic obtained:

Debian SSH Key Compromise

The OpenSSL PRNG key for Debian can be predicted between 2006 and 2008 due to a modification in the code.

In this link you can find the repository where the vulnerable keys are located:

https://github.com/g0tmi1k/debian-ssh

The OpenSSL PRNG key for Debian can be predicted between 2006 and 2008 due to a modification in the code.

First, the SSH public key must be obtained:

Using the following command we can see what type of ssh key it is and obtain the md5 fingerprint:

Download the github and look for the file that corresponds to the type of key, in this case as it is a 4096 bit key we find it in uncommon_keys/debain_ssh_rsa_4096_x86.tar.bz2

Once extracted, we simply have to search the folder for the md5 of our ssh key, and we will get two results, the public key and the private key:

Breaking a restricted shell with SSH

If you are in a restricted shell that prevents you from executing most commands, you have to find a way to “break the cage”. One of the ways to do this is with ssh.

As you can see, in this restricted bash it is not possible to execute most commands. However, if we connect through ssh using the -t bash parameter it is possible to get out of this restricted shell, because we start bash instead of rbash.

Login via SSH Agent

SSH agents are programs that keep track of a user’s identity keys and password. You can find more information about them aquí 

To activate them, go to /etc/ssh/etc_config and activate the ForwardAgent yes option

So if we hack a machine and we have a user with few privileges, we can run an ssh agent, which is a kind of ssh single sign-on, and maybe there is some agent that has root access.

In the next case we find a folder called ssh-zfnclcXPf0 that contains an “agent.1440”:

We can use this agent to access by ssh, in this case to a docker image that was inside this machine.

Find files modified between two dates

As a curiosity to close this section, I’m going to show you an interesting way to discover a ssh key that I found in a machine.

If we look at the following SSH directory:

We see that the date of creation of the id_rsa is 05/05/2019. It can be interesting to observe the files modified by that date to see if we get some information:

Note that the 01-ssh.sh file was also created that day. Let’s see what it contains.

We can see that in this file the instructions of an ssh agent are shown, in which we can see that the password of the private key file is Gk0cz221Ftb3ugog.

Now we only have to connect by ssh with the private key and enter that password:

I hope that the techniques I have shown you in this post are useful to you. I recommend you to have a look also to the post I made showing pentesting techniques with the FTP protocol.

Also, if you liked it and want to be informed when I publish the following protocols, I recommend you to subscribe to my telegram channel.

Lethani.

4/5 - (49 votes)

7 thoughts on “Infraestructure Hacking: SSH Protocol – Part II”

  1. Great site you’ve got here.. It’s hard to find good quality writing like yours nowadays.
    I seriously appreciate people like you! Take care!!

    Reply

Leave a comment