Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco, un grupo de científicos de la Universidad Ruhr de Bochum, Alemania, presentaron los detalles de una nueva técnica de ataque MITM sobre SSH, la cual han bautizado como «Terrapin» y la cual mencionan que podría permitir a un atacante degradar la seguridad de una conexión SSH cuando utiliza la negociación de extensión SSH. El impacto en la práctica dependería en gran medida de las extensiones admitidas, pero «casi todos» son vulnerables.

Terrapin, explota una vulnerabilidad (ya catalogada bajo CVE-2023-48795) la cual un atacante puede aprovechar para organizar un ataque MITM cuando se usa OpenSSH, la vulnerabilidad le permite revertir la conexión para usar algoritmos de autenticación menos seguros o deshabilitar la protección contra ataques de canal lateral que recrean la entrada analizando los retrasos entre las pulsaciones de teclas en el teclado.

«Al ajustar cuidadosamente los números de secuencia durante el protocolo de enlace, un atacante puede eliminar una cantidad arbitraria de mensajes enviados por el cliente o el servidor al comienzo del canal seguro sin que el cliente o el servidor se dé cuenta», mencionan los investigadores

Sobre la vulnerabilidad, se menciona que esta afecta a todas las implementaciones SSH que admiten cifrados en modo ChaCha20-Poly1305 o CBC en combinación con el modo ETM (Encrypt-then-MAC). Por ejemplo, capacidades similares han estado disponibles en OpenSSH durante más de 10 años.

“Lo más común es que esto afecte la seguridad de la autenticación del cliente cuando se utiliza una clave pública RSA. Cuando se utiliza OpenSSH 9.5, también se puede utilizar para desactivar ciertas contramedidas a los ataques de sincronización de pulsaciones de teclas”, escriben los investigadores.

La vulnerabilidad se debe al hecho de que un atacante que controla el tráfico de la conexión (por ejemplo, el propietario de un punto inalámbrico malicioso) puede ajustar los números de secuencia de los paquetes durante el proceso de negociación de la conexión y lograr la eliminación silenciosa de un número arbitrario de mensajes del servicio SSH enviado por el cliente o servidor.

Entre otras cosas, un atacante podría eliminar los mensajes SSH_MSG_EXT_INFO utilizados para configurar las extensiones de protocolo que se utilizan. Para evitar que la otra parte detecte una pérdida de paquete debido a una brecha en los números de secuencia, el atacante inicia el envío de un paquete ficticio con el mismo número de secuencia que el paquete remoto para cambiar el número de secuencia. El paquete ficticio contiene un mensaje con el indicador SSH_MSG_IGNORE, que se ignora durante el procesamiento.

Para realizar un ataque Terrapin en la práctica, los atacantes requieren capacidades de intermediario en la capa de red para interceptar y modificar el tráfico. Asimismo, se deberán acordar métodos de cifrado específicos para garantizar la transmisión segura de los datos durante la conexión.

El ataque no se puede llevar a cabo utilizando cifrados de flujo y CTR, ya que la violación de integridad se detectará en el nivel de la aplicación. En la práctica, solo se utiliza el cifrado ChaCha20-Poly1305 en el que el estado se rastrea únicamente mediante números de secuencia de mensajes, y una combinación del modo Encrypt-Then-MAC (*-etm@openssh.com). ) y los cifrados CBC están sujetos a ataques.

Se menciona que también se detectó en la biblioteca Python AsyncSSH, en combinación con una vulnerabilidad (CVE-2023-46446) en la implementación de la máquina de estado interna, el ataque Terrapin nos permite meternos en una sesión SSH.

La vulnerabilidad se solucionó en la versión de OpenSSH 9.6 y en esta versión de OpenSSH y otras implementaciones, se implementa una extensión del protocolo «estricto KEX» para bloquear el ataque, que se habilita automáticamente si hay soporte en el lado del servidor y del cliente. La extensión finaliza la conexión al recibir cualquier mensaje anormal o innecesario (por ejemplo, con el indicador SSH_MSG_IGNORE o SSH2_MSG_DEBUG) recibido durante el proceso de negociación de la conexión, y también restablece el contador MAC (Código de autenticación de mensajes) después de completar cada intercambio de claves.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.