SaSSHimi: evading AllowTcpForwarding
OpenSSH AllowTcpForwarding configuration parameter is sometimes used as a measure of SSH servers hardening in order to complicate tunnel creation. This kind of restriction may complicate the task in those circumstances where it is necessary to use a hop machine in order to carry out an audit (or during any pentest phase).
Therefore, a small tool called SaSSHimi has been created in order to evade AllowTcpForwarding easily. SaSSHimi can be downloaded from our GitHub.
0x01 – The problem
It is usual to find restrictions in hardening SSH connections, for example the use of AllowTcpForwarding configuration parameter in order to avoid SSH tunnels use in the connection. But, as it is very well explained in the OpenSSH documents, the use of this parameter does not improve security unless users are also denied shell access, as they can always install their own forwarders.
At low level, by using this parameter, “forwarded-tcpip” and “direct-tcpip” channels creation can be avoided without affecting “session” channels (these are the ones used by SSH in order to carry out TTYs management and commands execution).
For example, if you want to perform a connection from our machine (A) against a machine (B) inside the infrastructure, passing through the bastioned SSH, it is possible to install in the machine (S), where you have logged in, a binary that opens a socket against the target machine (B). Everything in the machine (A) written in STDIN is sent through the socket to the target machine (B), and everything received by this socket is sent to the STDOUT.
So, as an example, the behaviour of a local SSH tunnel (SSH -L) can be emulated. Another shabbier way of emulating a local tunnel might be using netcat and bidirectional pipes.
The way of emulating a dynamic tunnel is very similar to the local tunnel. The only different is that the remote end service should be a proxy socks.
0x02 – Implementing a Custom Forwarder
The main difficulty to solve refers to the possibility of creating dynamic tunnels through an SSH session channel. Therefore, the tool should open remotely a Socks proxy and be able to connect a local socket data stream with socks proxy through SSH channel STDIN and STDOUT streams. Please, see below the final functional diagram.
It might be relatively easy implementing something similar with socat combined with netcat and some light Socks5 server compiled statically. However, the following problem arises: the socat, running in local, will need to open an SSH connection for each incoming connection, executing additionally a remote netcat for each one of these.
Accordingly, the main aim of this project is implementing a simple and self-contained solution which provides the possibility of implementing this kind of tunnels multiplexing a group of connections inside a single SSH session.
0x03 – Golang is the new python
For this task, Golang programming language use has been chosen. It offers a range of advantages regarding python for this type of tools:
- It is fast (although python could also be fast adding co-routines).
- It generates a statically compiled single binary of an acceptable size.
- It allows cross compilation without complications
0x04 – SaSSHimi
SaSSHimi is a tool which covers this functionality in one binary, creating a raw “custom forwarder” using STDIN and STDOUT. On one hand, the binary itself works at the same time as server, opening the SSH connection against the remote host and rising a listening port in local mode. And on the other hand, it works as an agent, creating a Socks5 proxy in the remote machine and injecting the entry by STDIN.
Therefore, when the tool is executed in server mode, it is in charge of copying itself in the remote machine apart from executing itself in agent mode in order to perform the forwarder function. Whenever the agent dies, every file created in the remote system is removed.
SaSSHimi can be found in our GitHub repository together with documents including a user guide.
0x05 – Future steps
This tool has been created in order to cover a very specific need, but hopefully it will evolve over the time adding the following functionalities:
- Local and remote tunnels
- Encoded additional layer in order to complicate PAM type audit tools (Privileged Access Management)
- Implementing a TTY inside this encoded additional layer
- Study the viability of implementing a X11 forwarding
0x06 – Conclusions
SSH sessions hardening can complicate in some degree extent lateral movement in pentests and RedTeam exercises. SaSSHimi aims to be a tool to be considered in order to facilitate work in these environments.