¿Y si una contraseña exageradamente larga te dejara entrar a una cuenta que no tiene contraseña? Parece una broma, pero fue noticia la semana pasada en el mundo OpenSSH.
El 5 de noviembre, OpenSSH publicó la versión 10.6p2 con una corrección crítica para sistemas Linux con musl y PAM deshabilitado. La falla se conoce como *sshole, tiene el identificador CVE-2026-123158 y un puntaje CVSS de 8.1. La reportó Özgün Kültekin, de Wakefield.
Las cuentas sin contraseña usable guardan un asterisco en /etc/shadow. Como explica Help Net Security, cuando la librería musl recibe una contraseña de más de 256 bytes, crypt() falla y devuelve también un asterisco. El demonio sshd compara, ambos coinciden, y deja pasar.
Según el resumen de Invadel, tienen que darse cuatro condiciones a la vez:
- sshd corre sobre musl y sin PAM, como el paquete por defecto de Alpine.
- La autenticación por contraseña está habilitada, que es el valor por defecto.
- La cuenta atacada tiene exactamente un asterisco en /etc/shadow.
- Otra cuenta local tiene un hash de contraseña SHA-crypt.
Las distribuciones con glibc, como Debian o Ubuntu, no están afectadas.
Hay un matiz importante, el usuario root solo acepta contraseña si un administrador configuró PermitRootLogin yes. El riesgo más concreto está en el usuario alpine de las imágenes oficiales para la nube, que puede convertirse en root con doas sin contraseña.
Poco después, Previdian informó un primer intento a menos de nueve horas de publicado el CVE. Al 8 de noviembre, registraba 20 intentos desde 13 direcciones IP.
Entonces nos hicimos la pregunta obvia: ¿esto estaba llegando también a nuestra región?
Lo que vimos en nuestra honeynet
En el CSIRT de LACNIC operamos una red de honeypots Cowrie en América Latina y el Caribe. Cowrie simula un servidor SSH y registra las credenciales que recibe. Así que buscamos contraseñas de 257 caracteres o más en los sensores ya integrados a nuestra plataforma de análisis.
Algunos resultados parecían conexiones TLS registradas como credenciales binarias, con un largo inflado por la forma en que se guardan. Por lo tanto, la primera tarea fue limpiar.
Entre el 19 y el 31 de octubre hubo apenas 12 registros largos, y los que revisamos eran ese ruido. Del 1 al 4 de noviembre, ninguno. Desde el 5 de noviembre aparecieron 852 registros, con un pico de más de 600 el día 7.
De esos 852, 849 eran contraseñas en texto, cada una en una sesión SSH distinta.
- 666 medían exactamente 257 caracteres, el mínimo para disparar la falla.
- 768 empezaban con letras A repetidas.
- 773 apuntaban a root y 52 a alpine.
Ese último dato es llamativo: la gran mayoría de los intentos fue a root, que en un Alpine por defecto no acepta contraseña, y muy pocos al usuario alpine. Quien escanea a gran escala no parece afinar demasiado el objetivo.
Una sola dirección IP concentró la mayoría de las sesiones. Otras repartieron sus intentos entre muchos sensores. Entre las más activas, la primera apareció a las 17:17 UTC del 5 de noviembre, cerca de hora y media después de publicado el CVE.
¿Qué hicieron una vez adentro?
Como Cowrie los dejó pasar, pudimos observar el paso siguiente. Del total de sesiones, casi la mitad se fueron sin ejecutar nada, algo esperable si solo estaban validando el acceso. Las otras sí ejecutaron comandos, y vimos cuatro comportamientos:
- Reconocimiento con netstat, lectura de /proc/net/tcp y marcadores para comprobar si la shell era real.
- Descarga de un script que elimina procesos rivales, incluso ocultos, e intenta instalar un bot para 15 arquitecturas, con la etiqueta alpine. En VirusTotal, 30 de 61 motores detectan el script, y ya había sido analizado antes de publicarse el CVE. Su binario para x86_64 aparece etiquetado como gafgyt/mirai.
- Persistencia guardando dos archivos en cada sensor. En los casos que verificamos eran un par de claves SSH, lo que sugiere un acceso preparado para cada víctima. En algunos, además, se intentó abrir un túnel SSH inverso hacia la misma IP desde la que había entrado.
Cada comportamiento vino de orígenes distintos. No podemos afirmar quién está detrás, pero no parece una campaña única.
Qué conviene hacer
Si administras sistemas con musl, o usás imágenes basadas en Alpine con sshd, te recomendamos:
- Actualizar y reiniciar
Instala OpenSSH 10.6p2 o el paquete corregido de tu distribución, y reinicia sshd ya que el proceso en ejecución sigue usando el binario anterior.
- Parchear si no podés actualizar
Deshabilita la autenticación por contraseña con PasswordAuthentication no, como pidió Damien Miller, de OpenSSH.
- Revisar
Buscá Accepted password for en cuentas sin contraseña, y mirá authorized_keys, usuarios recientes y uso de doas, como recomienda Alpine.
Tardó apenas horas en pasar de un aviso público a tráfico real en sensores de nuestra región. Pero lo que más nos llamó la atención fue el script inicial, que ya existía antes del CVE.
Quienes operan esta botnet solo cambiaron el acceso inicial, una de las tácticas de la matriz ATT&CK de MITRE. El resto de la cadena ya lo tenían armado.
Gráfica 1. Contraseñas de 257 caracteres o más registradas por día en la honeynet. El 9 de noviembre es un día parcial. Crédito: elaboración propia, CSIRT de LACNIC.
Lectura adicional
Indicadores de compromiso
