Actualizaré la noticia si OpenSSH, Alpine o CISA publican datos nuevos.

◢¿Qué es SSHole?

En Linux, una cuenta puede tener la contraseña desactivada: en su lugar se guarda un asterisco (*), y la idea es que a esa cuenta solo se entre con una clave SSH o no se entre de ninguna manera. Es lo habitual en cuentas de servicio y en muchos servidores donde solo se trabaja con claves.

Según explica The Hacker News, el problema aparece cuando el atacante manda una contraseña muy larga, de entre 257 y 1.024 bytes. En los sistemas que usan la biblioteca musl, la función que calcula el resumen de la contraseña falla con esa longitud y devuelve precisamente un asterisco. OpenSSH compara ese asterisco con el que hay guardado en la cuenta, ve que coinciden y deja pasar. El origen está en un parche de 2016 que corregía otro fallo distinto (el CVE-2016-6210).

El fallo lo descubrió el investigador Ozgun Kultekin, tiene una gravedad de 8,1 sobre 10 y está corregido en OpenSSH 10.6p2, publicado el 5 de noviembre.

◢¿A quién afecta y a quién no?

Según The Hacker News, solo afecta a sistemas Linux que ejecutan OpenSSH sobre musl y con PAM desactivado (PAM es el sistema que en muchas distribuciones se encarga de comprobar las contraseñas). La configuración por defecto del servidor OpenSSH de Alpine Linux cumple esas condiciones.

No afecta a las distribuciones basadas en glibc, que son la mayoría de servidores (Debian, Ubuntu, Red Hat y derivadas), ni a sistemas que comprueban la contraseña con PAM, ni a Dropbear, ni a sistemas que no son Linux. Tampoco permite saltarse una contraseña normal: hace falta al menos una cuenta con el asterisco en lugar de contraseña.

Lo que consigue el atacante son los permisos de esa cuenta. Si esa cuenta puede hacerse administradora sin contraseña, el resultado es control total de la máquina, como recoge BleepingComputer.

◢¿Se está explotando?

Sí. Según BleepingComputer, apareció una prueba de concepto pública unas cuatro horas después de la corrección, los intentos empezaron ese mismo 5 de noviembre y al día siguiente ya hubo ataques con éxito.

La empresa Previdian confirmó un acceso como root en un servidor trampa con Alpine Linux y, a 8 de noviembre, contaba 20 intentos desde 13 direcciones IP de nueve países, según The Hacker News. GreyNoise registró su primer ataque con éxito el 7 de noviembre y, en total, 16 cadenas de ataque con éxito desde seis direcciones IP, según BleepingComputer. Los atacantes miraban qué había en la máquina, intentaban leer los resúmenes de contraseñas y las claves SSH de root y cambiaban los archivos authorized_keys para quedarse dentro. En un caso instalaron un programa de control remoto escrito en Python, aunque su servidor de órdenes no respondía.

La firma watchTowr ha relacionado la explotación con botnets y minería de criptomonedas, según el mismo medio. No hay atribución oficial a ningún grupo ni país. CISA marca como desconocido si se ha usado en campañas de ransomware y ha dado a las agencias federales de Estados Unidos hasta el 12 de noviembre para corregirlo.

◢¿Cómo sé si mi empresa está afectada?

La pregunta útil para el equipo técnico es: ¿tenemos máquinas con Alpine Linux, u otra distribución basada en musl, que tengan el servidor SSH abierto? Eso incluye los contenedores basados en Alpine que lleven el servidor SSH, y también las imágenes antiguas que sigan en marcha. Una imagen que se construyó hace meses no se corrige sola.

Si no sabéis qué sistemas tenéis, pregúntalo hoy a quien lleve los servidores o al proveedor que os los mantiene. Si todo es Ubuntu, Debian o Red Hat, este fallo concreto no os toca.

◢Qué hacer ahora

• ▹Actualizar OpenSSH a la 10.6p2 o al paquete corregido de vuestra distribución, y reiniciar sshd para que el cambio se aplique.
• ▹Si no podéis actualizar hoy, desactivar el acceso con contraseña por SSH (PasswordAuthentication no en la configuración de sshd) y entrar solo con claves.
• ▹Revisar los registros. Alpine recomienda buscar en /var/log/messages líneas de sshd con "Accepted password for" en cuentas que no tienen contraseña (alpine, root o cualquier usuario que solo use claves).
• ▹Revisar en las máquinas expuestas el uso de doas, los usuarios y archivos creados en los últimos días y las claves autorizadas. Alpine es claro: si no podéis descartar un acceso, tratad la máquina como comprometida.
• ▹Reconstruir las imágenes de contenedor basadas en Alpine que lleven sshd, para que incluyan el paquete corregido.

◢Qué aprender de esto

Lo llamativo de SSHole es lo rápido que ha ido: unas horas desde la corrección hasta la primera prueba de concepto pública, y menos de dos días hasta el primer ataque con éxito registrado. Es el mismo patrón que vimos con el fallo de la VPN de SonicWall. El margen entre que sale el parche y que alguien lo aprovecha ya no se mide en semanas.

La otra lección es sencilla: un servidor SSH abierto a internet que acepta contraseñas es una puerta que conviene cerrar aunque no haya ningún fallo conocido. Entrar solo con claves, y mejor aún solo desde una VPN o desde direcciones concretas, habría dejado este ataque sin efecto.

Y saber qué sistemas tienes es la base de todo. Muchas empresas descubren con un aviso como este que tienen máquinas que nadie recordaba. Si quieres que tu equipo entienda por qué importan estas cosas, es lo que trabajo en mis formaciones de ciberseguridad.