Depending on the SSH Server and the used version, there might some vulnerabilities, which can be used to compromise the server.
If you want to do a man in the middle attack, you must not be in the same lan. It's much easier, because you can use attacks like arp spoofing to redirect the traffic though your mitm server.
When you want to do a man in the middle attack in your scenario you can use BGP route injections.
In the past, some ISPs, countries or large companies (like Facebook) had some errors in their BGP configuration. In some cases the traffic was redirected through other countries or in the case of Facebook, they where kicked out of the internet.
If you want to do a man in the middle attack, you should not use ARP spoofing or BGP route injections. The reason is, that the client complains about server fingerprints. It's better to use another server as honeypot. With such a honeypot the user has to accept an unknown fingerprint, but is not warned about a man in the middle attack and changed fingerprints.
SSH vulnerabilities
The first thing is to find out the server version. This can be done with banner grabbing.
$ nc server 22
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
In this example OpenSSH 8.2 is used. Whit this knowledge you can search for some known exploits.
For the research, you can use exploit databases like https://www.exploit-db.com/
For SSH, you can also use ssh specific vulnerability lists: https://docs.ssh-mitm.at/ssh_vulnerabilities.html
OpenSSH 8.2 was released on 2020-02-14. This date is relevant, because most vulnerabilities have a CVE number including the date, when information was first published. There are some exceptions when a vulnerability was not fixed in later versions like CVE-2016-20012.
CVE-2016-20012 can be used to get information about existing users. If you have some usernames and publickeys, you can verify if a specific combination is valid.
This can be done with SSH-MITM (this is my SSH-MITM tool, which is not related to Joe Testa)
SSH-MITM includes a command to check if a username/publickey combination is valid. If you have collected some public keys during a forensic investigation, this command can be used to proof if the owner is allowed to login on the destination server. This does not require a private ssh key.
With this information it's much easier to do a man in the middle attack, because the man in the middle server known if the intercepted user is able to login with publickey authentication or password authentication.
ssh-mitm audit check-publickey --host HOSTNAME --username USER --public-key PATH_TO_PUBLICKEY
If you want to intercept the connection on a honeypot, you can start SSH-MITM with following arguments to start a mitm server on port 10022
ssh-mitm server --remote-host HOSTNAME
Using port 22 requires "root" privileges on your honeypot. I would recommend to create an iptables rule to redirect all traffic from port 22 to port 10022 (default port of SSH-MITM)
iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 10022
All incoming connections to port 22 are now redirected to port 10022.
Password authentication
SSH-MITM checks if the user is able to login with publickey authentication. If this is not possible, password authentication is used.
When password authentication is used, SSH-MITM is able to read the plain text password. This can be used to login to the destination server.
Publickey authentication
If the client wants to login with publickey authentication, the client must forward the agent. Without a forwarded agent, it's not possible to login, but you can redirect the connection to a honeypot and collect some data, which can be used for further attacks.
ssh-mitm server --remote-host HOSTNAME --falback-host HONEYPOT --fallback-user HONEYPOTUSER --fallback-password HONEYPOTPASSWD
The connection is only redirected to the honeypot, if the user is allowed to login on the destination server, but logging in was not possible because the agent was not forwarded to the mitm server.
If the user was not allowed to login, no connection is redirected to the honeypot. It would be strange to allow a login to the honeypot if the user is not able to login to the destination server ;-)
Bypass FIDO2 tokens (2 factor authentication)
FIDO2 tokens can be used for 2 factor authentication. If the private key is protected with a Fido2 token, each usage must be confirmed. Abusing a forwarded agent is not possible.
CVE-2021-36368 describes a vulnerability, which can be used to bypass the confirmation of a fido2 token during a man in the middle attack, which is required to login to the destination server.
ssh-mitm server --remote-host HOSTNAME --enable-trivial-auth
Presentation about spoofing FIDO2 tokens: https://github.com/ssh-mitm/ssh-mitm/files/7568291/deepsec.pdf
Mitigation
You should use a client, which has a fix against spoofing fido2 tokens.
Dropbear: This vulnerability is patched in Drobear (CVE-2021-36368): mkj/dropbear#128
PuTTY >= 0.71 has trust sigils against spoofing attacks. The trust sigil system was introduced to mitigate a spoofing attack against local passwords (e.g. password protected keys)
Since 0.76, there is also an option for advanced mitigations:
References:
Disclosure
I'm the author of SSH-MITM (https://github.com/ssh-mitm/ssh-mitm/)
