Advanced usage
SSH-MITM proxy server is capable of advanced man in the middle attacks and can be used in scenarios, where the remote host is not known or a single remote host is not sufficient or public key authentication is usded.
Public key authentication
Public key authentication is a way of logging into an SSH/SFTP account using a cryptographic key rather than a password.
The advantage is, that no confidential data needs to be sent to the remote host which can be intercepted by a man in the middle attack.
Due to this design concept, SSH-MITM proxy server is not able to reuse the data provided during authentication.
It you need to intercept a client with public key authentication, there are some options.
Request ssh agent for authentication
SSH supports agent forwarding, which allows a remote host to authenticate against another remote host.
SSH-MITM proxy server is able to request the agent from the client and use it for remote authentication. By using this feature, a SSH-MITM proxy server is able to do a full man in the middle attack.
Since OpenSSH 8.4 the commands scp and sftp are supporting agent forwarding. Older releases or other implementations, does not support agent forwarding for file transfers.
Using agent forwarding, SSH-MITM proxy server must be started with --request-agent.
1$ ssh-mitm --request-agent --remote-host 192.168.0.x
The client must be started with agent forwarding enabled.
1$ ssh -A -p 10022 user@proxyserver
Note
If the client does not forward the agent, but SSH-MITM server requested the agent, the client will get a break in attempt.
Warning: ssh server tried agent forwarding.
Warning: this is probably a break-in attempt by a malicious server.
Using ssh agent forwarding comes with some security risks and should not be used, when the integrity of a machine is not trusted. (https://tools.ietf.org/html/draft-ietf-secsh-agent-02)
6. Security Considerations
The authentication agent is used to control security-sensitive
operations, and is used to implement single sign-on.
Anyone with access to the authentication agent can perform private key
operations with the agent. This is a power equivalent to possession of
the private key as long as the connection to the key is maintained. It
is not possible to retrieve the key from the agent.
It is recommended that agent implementations allow and perform some form
of logging and access control. This access control may utilize
information about the path through which the connection was received (as
collected with SSH_AGENT_FORWARDING_NOTICE messages; however, the path
is reliable only up to and including the first unreliable machine.).
Implementations should also allow restricting the operations that can be
performed with keys - e.g., limiting them to challenge-response only.
One should note that a local superuser will be able to obtain access to
agents running on the local machine. This cannot be prevented; in most
operating systems, a user with sufficient privileges will be able to
read the keys from the physical memory.
The authentication agent should not be run or forwarded to machine whose
integrity is not trusted, as security on such machines might be
compromised and might allow an attacker to obtain unauthorized access to
the agent.
Adding a key with SSH_AGENT_ADD_KEY over the net (especially over the
Internet) is generally not recommended, because at present the private
key has to be moved unencrypted. Implementations SHOULD warn the user of
the implications. Even moving the key in encrypted form could be
considered unwise.
Currently, SSH-MITM only uses the forwarded agent for remote authentication,
but does not allow to rewrite the SSH_AGENT_FORWARDING_NOTICE message.
If a client uses an agent, which displays a warning, when the client is accessed, the original notice will be shown.
Redirect session to a honey pot
If agent forwarding is not possible, the SSH-MITM proxy server can accept the public key authentication request and redirect the session to a honey pot.
When the client sends a command, which requires a password to enter (like sudo), those passwords can be used for further attacks.
SSH-MITM does not support reusing entered passwords for remote authentication, but this feature could be implemented as a plugin.
Transparent proxy
To intercept ssh sessions, where the destination is not known, ssh-mitm proxy server can run in transparent mode, which uses the TProxy kernel feature from Linux.
Transparent proxying often involves “intercepting” traffic on a router. When redirecting packets to a local socket, the destination address will be rewritten to the routers address.
To intercept ssh connections on a network, this is not acceptable. By using TProxy from the Linux Kernel, SSH-MITM proxy server can intercept ssh connections, without loosing the destination address.
Note
To intercept the traffic, a static route can be configured on a router. An alternative to a static route is using arp spoofing.
Router configuration and arp spoofing are not part of this documentation.
Setting up firewall rules
To setup SSH-MITM in transparent mode, the system has to be prepared.
Using iptables:
$ iptables -t mangle -A PREROUTING -p tcp --dport 22 -j TPROXY --tproxy-mark 0x1/0x1 --on-port=10022 --on-ip=127.0.0.1
Using firewalld
firewall-cmd --direct --permanent --add-rule ipv4 mangle PREROUTING 1 -p tcp --dport 22 --j TPROXY --tproxy-mark 0x1/0x1 --on-port=10022 --on-ip=127.0.0.1
Warning
Additional firewall rules may be necessary to maintain device management capabilities over ssh
Note
To process the packets locally further routing needs to take place:
$ echo 100 tproxy >> /etc/iproute2/rt_tables
$ ip rule add fwmark 1 lookup tproxy
$ ip route add local 0.0.0.0/0 dev lo table tproxy
Now only the ssh proxy server needs to be started in transparent mode to be able to handle sockets that do not have local addresses:
$ ssh-mitm --transparent
By using the transparent mode, no remote host must be specified. If the --remote-host parameter is used,
all incoming connections are redirected to the same remote host.
Debug git and rsync
Sometime it’s interesting to debug git or rsync.
Starting with version 5.4, ssh-mitm is able to intercept ssh commands like git or rsync.
Performing a git pull or rsync with a remote server only executes a remote ssh command and the file transfer is part of the communication.
There is also a new plugin debug_traffic to debug the traffic of ssh commands.
ssh-mitm --request-agent --scp-interface debug_traffic
Note
SCP file transfers are executed as ssh command. This is the reason, why this plugin is implemented as a scp-interface plugin.
Intercept git
In most cased, when git is used over ssh, public key authentication is used. The default git command does not have a forward agent parameter.
To enable agent forwarding, git has to be executed with the GIT_SSH_COMMAND environment variable.
# start the ssh server
ssh-mitm --remote-host github.com --request-agent --scp-interface debug_traffic
# invoke git commands
GIT_SSH_COMMAND="ssh -A" git clone ssh://git@127.0.0.1:10022/ssh-mitm/ssh-mitm.git
Intercept rsync
When ssh-mitm is used to intercept rsync, the port must be provided as a parameter to rsync. Also the agent can be forwarded, if needed.
To sync a local directory with a remote directory, rsync can be executed with following parameters.
rsync -r -e 'ssh -p 10022 -A' /local/folder/ user@127.0.0.1:/remote/folder/
Further steps
SSH-MITM has some client exploits integrated, which can be used to audit various ssh clients like OpenSSH and PuTTY.