SaSSHimi: evadiendo AllowTcpForwarding

El parámetro de configuración AllowTcpForwarding de OpenSSH en ocasiones es utilizado como medida de bastionado de servidores SSH para dificultar la creación de túneles. En aquellos escenarios en los que para realizar una auditoría de seguridad de aplicaciones es necesario utilizar una máquina de salto (o bien durante alguna fase de un pentest) este tipo de restricciones pueden dificultar el trabajo.

Para evadir AllowTcpForwarding de manera sencilla se ha creado una pequeña herramienta llamada SaSSHimi que puede ser descargada del GitHub de Tarlogic.

0x01 – El problema de AllowTcpForwarding

Es habitual en conexiones SSH bastionadas encontrar restricciones, como por ejemplo el uso del parámetro de configuración AllowTcpForwarding para evitar el uso de túneles SSH dentro de la conexión. Como bien se explica dentro de la documentación de OpenSSH, el uso de este parámetro es inútil si al usuario no se le priva del acceso a una shell, ya que si no, cualquier usuario puede ejecutar una utilidad que actúe de “forwarder” de tráfico.

A bajo nivel, lo que significa esto es que a través de este parámetro se puede impedir la creación de canales tipo “forwarded-tcpip” y “direct-tcpip” sin afectar a los canales de tipo “session” (que son los utilizados por SSH para el manejo de TTYs y la ejecución de comandos).

Por ejemplo, si se desea realizar una conexión desde nuestra máquina (A) contra una máquina (B) dentro de la infraestructura, pasando a través del SSH bastionado, es posible instalar en la máquina (S), donde se ha iniciado sesión, un binario que abra un socket contra la máquina objetivo (B). Todo lo que en la máquina (A) se escriba en STDIN es enviado a través del socket hacia la máquina objetivo (B), y de igual forma todo lo recibido por este socket es enviado al STDOUT.

De esta forma se puede emular, a modo de ejemplo, el comportamiento de lo que sería un túnel SSH de tipo local (SSH -L). Otra forma, más pedestre, de emular un túnel de tipo local sería utilizando netcat y pipes bidireccionales.

La manera de emular un túnel de tipo dinámico es muy similar a la del túnel local, solo que el servicio al que se apuntaría en el interior debería de ser un proxy socks.

0x02 – Implementando un Custom Forwarder

El principal escollo a resolver es el poder cubrir la funcionalidad de crear túneles dinámicos a través de un canal SSH de tipo “session”. Para ello, la herramienta debe poder desplegar en remoto un Proxy Socks y ser capaz de conectar el flujo de datos de un socket local con el proxy socks a través de los flujos STDIN y STDOUT del canal SSH. El diagrama funcional final sería el siguiente:

Sería relativamente sencillo implementar algo similar con socat en conjunción con netcat y algún servidor Socks5 ligero compilado estáticamente, pero de hacerlo así aparecen un problema: el socat corriendo en local necesitaría abrir una conexión SSH por cada conexión entrante, ejecutando además un netcat en remoto por cada una de estas.

Es por ello que el principal objetivo de este proyecto es implementar una solución simple y autocontenida que permita implementar este tipo de túneles, multiplexando un conjunto de conexiones dentro de una única sesión SSH.

0x03 – Golang es el nuevo python

Para esta tarea se ha elegido el uso del lenguaje de programación Golang. Éste ofrece una serie de ventajas de serie con respecto a python para este tipo de herramientas:

1. Es rápido (aunque python también puede serlo de serie con co-rutinas).
2. Genera un binario único compilado estáticamente de un tamaño aceptable
3. Soporta compilación cruzada de base sin complicaciones

0x04 – SaSSHimi

SaSSHimi es una herramienta que cubre toda la funcionalidad en un único binario, creando un “custom forwarder” en crudo mediante el uso de STDIN y STDOUT. El propio binario funciona a la vez como servidor abriendo la conexión SSH contra el host remoto y levantando en local un puerto a la escucha; y como agente creando un proxy Socks5 en la máquina remota e inyectándole la entrada por STDIN.

De esta manera, cuando se ejecute la herramienta en modo servidor, éste se encarga de copiarse a sí mismo en la máquina remota y ejecutarse en modo agente para hacer la función de forwarder. Cuando el agente muere, todos los ficheros creados en el sistema remoto son borrados.

Puedes encontrar SaSSHimi en el repositorio de GitHub de Tarlogic, donde se encuentra así mismo la documentación con un manual de uso.

0x05 – Futuros pasos

Esta herramienta ha sido creada para cubrir una necesidad muy específica, pero es de esperar que a lo largo del tiempo se evolucione para añadir las siguientes funcionalidades:

• Túneles remotos y locales
• Capa adicional de cifrado para dificultar la auditoría de herramientas tipo PAM ( Privileged Access Management)
• Implementar una TTY dentro de esta capa adicional de cifrado
• Estudiar la viabilidad de implementar un forwarding de X11

0x06 – Conclusiones

El bastionado de sesiones SSH puede dificultar en cierto grado el desplazamiento lateral en pentests y ejercicios de RedTeam . La herramienta SaSSHimi pretende ser un utensilio más a tener en cuenta para facilitar el trabajo en estos entornos.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/