SSH Hijacking para movimiento lateral

SSH Hijacking para movimiento lateral

Que es el SSH? Y el SSH Hijacking?

Secure Shell (SSH) es un medio estándar de acceso remoto en sistemas Linux y Mac. Permite que un usuario se conecte a otro sistema a través de un túnel encriptado, comúnmente se autentica a través de una contraseña, certificado o el uso de un par de claves de cifrado asimétrico.

Para moverse lateralmente desde un host comprometido, los adversarios pueden aprovechar las relaciones de confianza establecidas con otros sistemas a través de la autenticación de clave pública en sesiones activas de SSH mediante el secuestro de una conexión existente a otro sistema. Esto puede ocurrir al comprometer al propio agente SSH o al tener acceso al socket del agente. Si un adversario puede obtener acceso raíz, entonces el secuestro de sesiones SSH probablemente sea trivial.123 Comprometerse con el agente SSH también proporciona acceso para interceptar credenciales SSH.

SSH Hijacking difiere del uso de los Servicios remotos porque se inyecta en una sesión SSH existente en lugar de crear una nueva sesión usando Cuentas válidas.

Diferentes implementaciones del SSH Hijacking

Tenga en cuenta que al secuestrar aquí nos referimos a que alguien abusa de las sesiones existentes sin tener acceso a las claves de autenticación. Entonces, sin usar credenciales robadas o claves privadas.

ControlMaster

ControlMaster de SSH es una característica que permite conexiones multiplexadas. En cuanto a rendimiento, esto es excelente, ya que solo tiene que autenticarse en el sistema de destino en la primera sesión de SSH y luego, dependiendo de la configuración del daemon de SSH, puede abrir múltiples sesiones de SSH nuevas a través de la conexión ya establecida. Esto puede ajustarse en el lado del servidor con las dos directivas siguientes.

MaxSessions
Specifies the maximum number of open sessions permitted per
network connection. The default is 10.

MaxStartups
Specifies the maximum number of concurrent unauthenticated
connections to the SSH daemon. Additional connections will
be dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10.

Al establecer MaxSessions en 1, puede desactivar ControlMaster/multiplexación de sesión y cada sesión nueva requerirá una conexión nueva completa que incluya el paso de autenticación. Sin embargo, si no lo hace, independientemente de qué tan fuerte sea el método de autenticación que esté empleando para sus usuarios, un atacante solo tiene que obtener la ejecución del código en uno de los puntos finales de su usuario y esperar a que el usuario llegue al SSH. El atacante puede buscar las conexiones abiertas inspeccionando el directorio especificado por la directiva ControlPath por parte del cliente o simplemente utilizando herramientas comunes como netstat. Entonces, si el atacante intenta abrir una sesión SSH a un host que ya está en el ControlMaster, no requerirá autenticación ni establecerá una nueva conexión ya que está reutilizando la existente. Tenga en cuenta que ControlMaster está habilitado de manera predeterminada.

Autenticación del agente

Para reducir la fricción y simplificar de la experiencia, muchas organizaciones emplean el agente SSH, que es un servicio que permite la autenticación a través de un archivo de socket local. Cuando te conectas a un sistema remoto, puedes elegir si quieres que tu agente ssh también esté disponible allí usando la directiva ForwardAgent. Al reenviar el agente puede moverse por los sistemas sin tener que copiar claves en todas partes o volver a autenticarse manualmente. Sin embargo, esto tiene un inconveniente también. Si un atacante tiene acceso de administrador en cualquiera de los sistemas desde los cuales ha reenviado su agente, puede reutilizar ese archivo de socket para abrir nuevas sesiones de SSH con su información. Aquí hay una breve descripción de cómo se hace esto.

# Attacker finds the SSHd process of the victim
ps uax|grep sshd
 
# Attacker looks for the SSH_AUTH_SOCK on victim's environment variables
grep SSH_AUTH_SOCK /proc/<pid>/environ
 
# Attacker hijack's victim's ssh-agent socket
SSH_AUTH_SOCK=/tmp/ssh-XXXXXXXXX/agent.XXXX ssh-add -l
 
# Attacker can login to remote systems as the victim
ssh remote_system -l vicitm

Si está utilizando OpenSSH, puede mitigar esta amenaza utilizando la directiva AllowAgentForwarding para asegurarse de que solo los hosts que lo necesitan lo tendrán, en lugar de todo el entorno.

En ambos casos, el atacante nunca tuvo acceso directo a los detalles de autenticación. Sin embargo, al abusar de las características de SSH, un atacante puede moverse lateralmente al medio ambiente sin causar mucho ruido. Ya di algunas directivas SSH nativas que se pueden usar para mitigar esta amenaza, pero, por supuesto, dependiendo de sus requisitos, puede que tenga que idear algo diferente.