Una falla de seguridad permitió entrar a servidores sin conocer la contraseña

Una falla de seguridad permitía acceder sin contraseña a algunos servidores Linux que usan OpenSSH, el programa encargado de proteger las conexiones remotas. Para aprovecharla, un atacante solo debía enviar una contraseña especialmente larga, de entre 257 y 1.024 caracteres. La corrección se publicó

Una falla de seguridad permitía acceder sin contraseña a algunos servidores Linux que usan OpenSSH, el programa encargado de proteger las conexiones remotas. Para aprovecharla, un atacante solo debía enviar una contraseña especialmente larga, de entre 257 y 1.024 caracteres. La corrección se publicó el 5 de noviembre.
La vulnerabilidad, llamada “sshole”, fue hallada por Özgün Kültekin, investigador de la firma de seguridad Wakefield. No afecta a todos los equipos con Linux: se concentra en configuraciones específicas, presentes sobre todo en servidores livianos, servicios en la nube y dispositivos conectados a internet.
El problema alcanza a sistemas que usan una variante de Linux llamada musl, una pieza básica de software que ayuda a los programas a funcionar. También deben tener habilitado el ingreso con contraseña y carecer de una herramienta adicional de autenticación conocida como PAM.
Alpine Linux, un sistema muy utilizado para crear versiones preconfiguradas de servidores y servicios en la nube, traía esa combinación de forma predeterminada. Wakefield también señaló posibles riesgos en OpenWrt, usado en routers, y en Buildroot y Yocto, empleados para crear el software de dispositivos conectados.
Los administradores de Alpine resumieron el riesgo de forma directa: “Un atacante que pueda llegar a tu puerto SSH, la puerta de acceso remoto del servidor, puede entrar sin saber ninguna contraseña”. Según indicaron, basta con una conexión y el intento no requiere repetirse.
La falla no afecta por igual a todas las cuentas
El acceso indebido solo era posible en cuentas configuradas para no pedir una contraseña escrita. En Linux, esas cuentas suelen estar protegidas con una llave digital, un archivo que funciona como credencial de acceso, o se reservan para tareas de administración.

Además, el servidor debía tener al menos otra cuenta con una contraseña protegida mediante una de las formas de seguridad afectadas. En términos simples, el sistema confundía una contraseña inválida y demasiado larga con la señal que usa para reconocer una cuenta sin contraseña.
Wakefield advirtió que algunas imágenes oficiales de Alpine Linux para los servicios en la nube de Amazon y Microsoft incluyen una cuenta llamada alpine. Esa cuenta puede ejecutar tareas de administrador sin pedir contraseña, por lo que una intrusión podía dar al atacante control completo del servidor si se cumplían las demás condiciones.
Los sistemas más habituales, como Debian, Ubuntu y Fedora, no están afectados, de acuerdo con la firma. Tampoco se detectó el problema en OpenBSD, FreeBSD, macOS ni en otro programa de acceso remoto llamado Dropbear. Pruebas citadas por Ars Technica indicaron que la cuenta objetivo debía estar activa y que la cuenta principal de administración queda protegida con la configuración habitual.
Un cambio pensado para proteger la privacidad causó el problema
El origen se remonta a 2016. Ese año, OpenSSH modificó el modo en que responde cuando alguien intenta entrar a una cuenta sin una contraseña utilizable. El objetivo era impedir que un atacante descubriera qué nombres de usuario existen en un servidor al medir el tiempo de respuesta.

Sin embargo, la modificación se combinó con un comportamiento de musl. Cuando alguien enviaba una contraseña de más de 256 caracteres, esa parte del sistema devolvía un asterisco. El problema fue que las cuentas sin contraseña usan la misma señal. OpenSSH podía confundir ambas situaciones y permitir el acceso.
El proyecto OpenSSH afirmó que la causa original está fuera de su código, aunque el ataque utiliza su programa. Por eso incluyó una protección en la versión 10.6p2. La actualización fue descrita como un arreglo de seguridad crítico.
Actualizar OpenSSH o desactivar el acceso con contraseña cierra la falla
Alpine publicó paquetes corregidos para todas sus versiones compatibles el 5 de noviembre, entre ellos 3.21.10, 3.22.8, 3.23.8 y 3.24.4. Sus administradores recomendaron actualizar OpenSSH y reiniciar el servicio, ya que instalar la corrección no modifica por sí solo el programa que ya está funcionando.
Quienes no puedan actualizar de inmediato pueden desactivar el acceso por contraseña. Alpine indicó que cualquiera de las dos medidas elimina el riesgo.
Para detectar un ingreso irregular, el proyecto aconsejó revisar los registros del sistema en busca de mensajes que indiquen un acceso por contraseña en cuentas que no deberían usarla. Si no se puede descartar una intrusión, el servidor debe considerarse comprometido. Al publicarse los avisos, la vulnerabilidad todavía no tenía un identificador CVE, el código que se asigna a las fallas de seguridad conocidas.
También te puede interesar
Cómo recuperar fotos eliminadas del celular: paso a paso para rescatar las imágenes en Android, iPhone y Google Fotos
Los directores financieros asumen la gestión de la inteligencia artificial como nueva responsabilidad corporativa

