Ciberdelincuentes explotan la vulnerabilidad SSHole en OpenSSH horas después de su divulgación

turned on Acer laptop on table near cup — Anete Lūsiņa / Unsplash

Actores de amenazas están intentando explotar una falla de seguridad recientemente divulgada que afecta a OpenSSH, permitiendo iniciar sesión en cuentas que no tienen contraseña configurada, según informó la empresa de inteligencia de amenazas Previdian. La vulnerabilidad, registrada como CVE-2026-123158 con una puntuación CVSS de 8.1 y apodada SSHole, impacta a los sistemas Linux que ejecutan OpenSSH sobre la biblioteca C musl con los Módulos de Autenticación Enchufables deshabilitados, incluyendo la configuración predeterminada del servidor OpenSSH de Alpine Linux.

Un atacante no autenticado puede proporcionar una contraseña de tamaño excesivo para acceder a cuentas configuradas deliberadamente sin contraseñas utilizables, sin necesidad de robar credenciales o claves. El problema, descubierto por el investigador de seguridad Ozgun Kultekin, ha sido corregido en la versión 10.6p2 de OpenSSH. La raíz del problema se remonta a un parche introducido en 2016 para corregir una vulnerabilidad de enumeración de nombres de usuario registrada como CVE-2016-6210. Bajo condiciones específicas, el comportamiento de manejo de contraseñas en OpenSSH interpreta erróneamente una operación de hash de contraseña fallida como una autenticación exitosa al producir el mismo valor, un asterisco, utilizado para indicar que una cuenta tiene la contraseña deshabilitada a nivel de sistema.

Un atacante puede desencadenar la vulnerabilidad para autenticarse en ciertas cuentas con contraseña deshabilitada utilizando una contraseña arbitraria de entre 257 y 1.024 bytes de longitud, lo que provoca que el intento de hash falle y devuelva un asterisco. El demonio sshd luego compara este resultado con el asterisco almacenado en el campo de contraseña de la cuenta, lo que conduce a un inicio de sesión exitoso. Para ser claro, la explotación exitosa requiere al menos una cuenta con un asterisco como hash de contraseña. No permite a los atacantes eludir las contraseñas en cuentas con hashes de contraseña válidos.

Safe Security señaló que un ataque SSHole exitoso otorga acceso con los permisos existentes de la cuenta comprometida. Para las empresas, las consecuencias de SSHole dependen de los privilegios de la cuenta comprometida. Aunque el acceso no autorizado a SSH es el impacto inmediato, los atacantes también pueden obtener acceso a credenciales de despliegue, secretos de aplicaciones e infraestructura conectada, lo que potencialmente permite el movimiento lateral o la interrupción de servicios.

Es importante destacar que la vulnerabilidad no afecta a Dropbear, a las distribuciones Linux basadas en glibc, a los sistemas no Linux y a los sistemas que comprueban las contraseñas a través de PAM. La empresa de inteligencia de amenazas Previdian dijo que observó el primer intento de explotación menos de nueve horas después de la publicación del CVE, y añadió que ha confirmado el acceso exitoso como superusuario en un señuelo que ejecuta Alpine Linux y OpenSSH. Los datos de telemetría muestran un total de ocho intentos de explotación desde una dirección IP geolocalizada en Japón.

Ryan Dewhurst, fundador y director ejecutivo de Previdian, declaró que la dirección IP de origen observada, 89.116.89[.]18, utilizó contraseñas de tamaño excesivo para eludir la autenticación y ejecutó comandos de reconocimiento, incluidos id, uname y hostname, a través de sesiones SSH no interactivas. Se aconseja a los usuarios afectados instalar OpenSSH 10.6p2 o el paquete corregido de su distribución y, a continuación, reiniciar sshd. Alpine también recomienda a los usuarios investigar las entradas de registro que indiquen contraseñas aceptadas para cuentas que no deberían aceptar inicios de sesión con contraseña.

Alpine instó a buscar en el archivo de mensajes del sistema líneas del demonio sshd que indiquen que se aceptó una contraseña para una cuenta sin contraseña, como alpine, root o cualquier usuario solo con clave. Se recomienda revisar el uso de doas y los usuarios, archivos y claves autorizadas creados recientemente en las máquinas expuestas. Si no se puede descartar un inicio de sesión, se debe tratar la máquina como comprometida.