Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Blog TuxCareUna explosión del pasado: RegreSSHion
por Joao Correia
12 de julio de 2024 - Evangelista técnico
Es verano, y el año hasta ahora ha sido pródigo en hackeos de alto riesgo que han afectado a empresas de muy alto perfil, como Ticketmaster o Change Healthcare, y sofisticadas operaciones maliciosas como la dirigida contra el proyecto xz. Ahora podemos añadir otro incidente muy significativo a la lista, con la vulnerabilidad RegreSSHion (estos nombres...) que afecta a OpenSSH.
SSH es el de facto herramienta de acceso remoto de elección, está presente en todo, desde servidores hasta tu televisor, y cada vez que se descubren fallos que le afectan, el mundo de la ciberseguridad empieza a hiperventilar.
La vulnerabilidad
RegreSSHion, o CVE-2024-6387 si no lo conoces por su nombre de pila, es una vulnerabilidad revelada el 1 de julio de 2024. Investigadores de seguridad encontraron que el proceso de login al conectarse al servidor OpenSSH (comúnmente sshd) tiene un comportamiento explotable. Es decir, explotable remotamente.
Cuando se inicia una conexión, y el cliente no puede completar el proceso de inicio de sesión, hay un período de tiempo de espera incorporado (controlado por el ajuste LoginGraceTimeout, por defecto a 120s en la mayoría de las instalaciones), después del cual se termina la conexión. Cuando sshd termina la conexión, dispara una señal llamada SIGALRM de forma asíncrona - lo que significa que sshd no se cuelga mientras está procesando - y varios manejadores de eventos la recogen. Estos manejadores de eventos pueden ser pensados como funciones específicas que limpian los recursos ocupados por la conexión ahora extinta o escriben en los registros que un intento de conexión fue realizado pero no completado. La vulnerabilidad real proviene del hecho de que estos manejadores de eventos no están codificados de tal manera que sean asíncronos, y pueden producir un comportamiento inesperado en escenarios muy específicos (y difíciles de desencadenar).
La explotación
Explotar la vulnerabilidad requiere que se den una serie de condiciones en el servidor. Por desgracia para muchos administradores de sistemas y organizaciones, estas condiciones son bastante comunes.
En primer lugar, OpenSSH debe estar ejecutando una versión vulnerable - pero más adelante hablaremos de las versiones afectadas. Segundo, el sistema debe ejecutar glibc, ya que las funciones async inseguras provienen de ahí. En tercer lugar, no debe haber ninguna forma de mitigación; en este sentido, la gente de *BSD se siente bastante bien con su elección de distribución en este momento, ya que ha incluido versiones asíncronas seguras de las funciones desde hace unas décadas.
Para activar la vulnerabilidad, un atacante tiene que intentar el proceso de inicio de sesión y dejar que se agote el tiempo de espera, y repetir este proceso (potencialmente muchos intentos). Las funciones correctas tienen que ejecutarse en el momento adecuado y, en un entorno asíncrono afectado por otros procesos en el sistema, esto no ocurre a menudo. La activación del fallo se convierte en un proceso probabilístico en lugar de determinista. Los investigadores de seguridad responsables del hallazgo estimaron que, en sistemas de 32 bits, esto podría llevar, de media, entre 8 horas y un día. En sistemas de 64 bits, dado que el espacio de direcciones es mucho mayor, podría llevar semanas.
Sin embargo, cuando se ejecuta el conjunto adecuado de funciones en el momento oportuno, un atacante remoto puede engañar al sistema para que ejecute código controlado por el atacante, como abrir un intérprete de comandos, con privilegios de root.
El larguísimo periodo de tiempo que puede tardar el exploit hace improbable una explotación generalizada de esta vulnerabilidad, pero los ataques dirigidos son sin duda una opción para los actores maliciosos. Es importante señalar que los mismos investigadores de seguridad que demostraron este exploit se esforzaron mucho por mencionar que simplemente querían demostrar que se podía explotar, y que su código no estaba optimizado en modo alguno.
Mi SSHD no está expuesto a Internet
Y es una gran elección. Desgraciadamente, un rápido escaneo a través de Internet encontró más de 14 millones de servicios SSH expuestos. Aunque no todos reúnen las condiciones adecuadas para que este ataque tenga éxito, incluso una pequeña parte sigue siendo un número considerable de sistemas que podrían estar abiertos a negocios maliciosos.
Mantener sus servicios críticos fuera de Internet, vinculándolos sólo a direcciones internas, no reenviadas por puerto, o bloqueándolos a nivel de cortafuegos, es una buena opción. De hecho, no debería hacer falta una vulnerabilidad como esta para justificar esa opción, pero cuantos más servicios ayude a alejar de posibles ataques, desde RegreSSHion o el simple rociado de contraseñas, mejor.
Tengo barba canosa y recuerdo algo parecido...
Y también tiene una gran memoria. Resulta que RegreSSHion afecta a las versiones de OpenSSH entre 8.5p1 y 9.8p1 (ya no es vulnerable), ya que el código responsable del fallo se comprometió en 2020.
PERO... también afecta a versiones de OpenSSH anteriores a la 4.4p1, de 2006 (CVE-2006-5051). Resulta que, en 2006, este mismo error había sido encontrado, y corregido. Y luego corregido de nuevo en 2008, porque la primera corrección aparentemente no era correcta (CVE-2008-4109).
¿Cómo es que ha vuelto a la base de código? Bueno, la memoria y el tiempo no son grandes compañeros. Cuando se envió el código en 2020, nadie se dio cuenta de que la misma confirmación de código volvería a hacer a OpenSSH vulnerable a un problema ya solucionado. Se eliminó un "ifdef" del código, que estaba guardando el código para protegerlo del fallo anterior, por lo que podría ser explotado de nuevo.
Esquivar las balas
Las vulnerabilidades explotables remotamente que resultan en acceso privilegiado son algunas de las más peligrosas que existen. Cuando afectan a un software tan ampliamente utilizado como OpenSSH, es un escenario de pesadilla. El lado positivo de RegreSSHion es que tarda mucho en activarse. Esto lo ha hecho significativamente menos peligroso de lo que podría haber sido de otro modo.
Al igual que con xz, donde el backdoor fue capturado justo en el momento adecuado antes de propagarse, es posible que hayamos esquivado otra bala con RegreSSHion debido a su lento tiempo de explotación.
Otra importante bala esquivada es que la versión enviada con CentOS 7 no era, según Redhat, vulnerable. Dado que esta vulnerabilidad se anunció justo después de la fecha de fin de vida de CentOS 7, si hubiera sido vulnerable, no habría recibido ningún parche suministrado por el proveedor, lo que a su vez habría dejado muy expuestos a los miles de sistemas CentOS 7 que todavía funcionan.
Es una perogrullada que no siempre vas a tener suerte. Algún día, como Neo agitando los brazos para esquivar las balas de Matrix, una le dará en el blanco. Tómate un momento para hacer balance de tu infraestructura, y no sólo para ssh. Empieza a bloquear servicios innecesarios de la exposición a Internet y refuerza las conexiones VPN. Son las cosas básicas las más fáciles de manejar, como la aplicación oportuna de parches y el cortafuegos, y el vector más fácil de atacar para los actores de amenazas.
Y hacerlo hoy es mejor que mañana.
[Una nota especial para el equipo de AlmaLinux. Publicaron paquetes actualizados de OpenSSH para gestionar este fallo a las pocas horas de su revelación, y mucho antes que upstream y otros grandes nombres en este espacio. Enhorabuena].
[Una segunda nota: como es habitual con estas vulnerabilidades de alto perfil, a medida que más personas las investigan, se identifican otros fallos. Uno relacionado ya ha sido identificado y divulgado como CVE-2024-6409]
