Un grupo de investigadores de la Universidad Ruhr de Bochum (Alemania) ha presentado una nueva técnica de ataque MITM sobre SSH llamada Terrapin, que explota una vulnerabilidad (CVE-2023-48795) en el protocolo. Un atacante capaz de realizar un ataque MITM puede interrumpir el envío de un mensaje de configuración de extensiones del protocolo durante el proceso de establecimiento de la conexión, permitiendo así reducir el nivel de protección de la conexión. Un prototipo de la herramienta para llevar a cabo el ataque ha sido publicado en GitHub.
En el contexto de OpenSSH, esta vulnerabilidad, por ejemplo, permite revertir la conexión para usar algoritmos de autenticación menos seguros y desactivar la protección contra ataques de canal lateral que recrean la entrada analizando el tiempo entre las pulsaciones de teclas. En la biblioteca de Python AsyncSSH, combinada con la vulnerabilidad (CVE-2023-46446) en la implementación de la máquina de estado interno, el ataque Terrapin permite intervenir en una sesión SSH.
La vulnerabilidad afecta a todas las implementaciones de SSH que admiten ChaCha20-Poly1305 o cifrados en modo CBC combinados con el modo ETM (Encrypt-then-MAC). Por ejemplo, estas capacidades han estado disponibles en OpenSSH durante más de 10 años. La vulnerabilidad ha sido corregida en la versión actual de OpenSSH 9.6, así como en las actualizaciones de PuTTY 0.80, libssh 0.10.6/0.9.8 y AsyncSSH 2.14.2. En Dropbear SSH, la corrección ya se ha añadido al código, pero la nueva versión aún no se ha generado.
La vulnerabilidad se debe a que un atacante que controla el tráfico de la conexión (por ejemplo, el propietario de un punto de acceso inalámbrico malicioso) puede ajustar los números de secuencia de paquetes durante el establecimiento de la conexión y lograr la eliminación silenciosa de un número arbitrario de mensajes SSH enviados por el cliente o el servidor. Entre otras cosas, el atacante puede eliminar mensajes SSH_MSG_EXT_INFO, que se utilizan para configurar las extensiones del protocolo aplicadas. Para que la otra parte no detecte la desaparición de un paquete debido a los desajustes 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 eliminado. El paquete ficticio contiene un mensaje con la señal SSH_MSG_IGNORE, que se ignora durante el procesamiento.
Un ataque no puede llevarse a cabo al utilizar cifrados de flujo y CTR, ya que cualquier violación de la integridad se detectará a nivel de aplicación. En la práctica, solo el cifrado ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) es vulnerable, donde el estado se sigue únicamente mediante los números de secuencia de los mensajes, y la combinación del modo Encrypt-Then-MAC (*-etm@openssh.com) con cifrados CBC.
En OpenSSH 9.6 y otras implementaciones, se ha implementado una extensión del protocolo 'strict KEX' para bloquear ataques, que se activa automáticamente si hay soporte por parte del servidores y el cliente. Esta extensión termina la conexión al recibir cualquier mensaje anómalo o adicional (por ejemplo, con la bandera SSH_MSG_IGNORE o SSH2_MSG_DEBUG), recibidos durante el proceso de negociación de conexión, y también restablece el contador MAC (Código de Autenticación de Mensajes) tras cada intercambio de claves.
Fuente: opennet.ru
