Recomendaciones sobre regreSSHion, una vulnerabilidad crítica de OpenSSH
Resumen esencial
CVE-2024-6387 es una vulnerabilidad crítica de ejecución remota de código (RCE) en OpenSSH que se deriva de otra regresión registrada en Common Vulnerabilities and Exposures (CVE) en 2006.
Para realizar el ataque, es necesario ganar la condición de carrera, por lo que se podría demorar horas e incluso semanas.
Se recomienda aplicar parches a las versiones no afectadas del servidor OpenSSH en sistemas Linux basados en glibc. Si esto no fuera posible, hemos seleccionado otras opciones de mitigación para reducir el impacto potencial.
También proporcionamos una consulta de osquery para detectar versiones vulnerables de OpenSSH.
Análisis técnico y antecedentes de vulnerabilidades de OpenSSH
La Unidad de Investigación de Amenazas de Qualys ha descubierto recientemente una nueva vulnerabilidad crítica (CVE-2024-6387) en OpenSSH que podría dar lugar a una RCE no autenticada. El 1 de julio de 2024, publicaron los resultados acerca de la regresión de la vulnerabilidad CVE-2006-5051, que se corrigió en 2006 y volvió a aparecer en 2021.
La causa principal de esta CVE es una condición de carrera que se genera por una gestión insegura de las señales cuando se agota el tiempo de espera de autenticación del usuario. Cuando sucede, se genera una señal SIGALRM, que interrumpe el subproceso de ejecución de una rutina de gestión del montón. Si el mismo programa que maneja las señales ejecuta la rutina de gestión del montón, podría producirse un comportamiento inesperado y, en este caso, ejecutar código arbitrario.
Actualmente, existe una prueba de concepto (PoC) pública que aprovecha esta vulnerabilidad y la convierte en una vulnerabilidad explotada conocida (esta PoC no la ofrece un tercero afiliado a Akamai, por lo que debe llevar a cabo su propio proceso de diligencia debida antes de interactuar con el código). A pesar de su gravedad, la PoC pone de relieve algunas limitaciones que impedirían realizar el ataque con éxito. Una de las principales hace referencia al tiempo que tarda en explotarse la vulnerabilidad: en algunos sistemas, sería cuestión de horas, mientras que en otros, podría tardar hasta una semana. El hecho de depender del sistema operativo distribuido, y de la versión y configuración del servidor de OpenSSH también limita su alcance.
¿Quién es vulnerable?
La vulnerabilidad está presente en muchas versiones de OpenSSH, lo que afecta a la mayoría de distribuciones de Linux, que utilizan OpenSSH por defecto.
Esta vulnerabilidad provoca una regresión en el código de OpenSSH: la CVE original afecta a las versiones más antiguas del servidor OpenSSH, a diferencia de otras más recientes lanzadas antes de la regresión.
A fecha de la publicación de este artículo, las versiones de OpenSSH que se sabe que están afectadas por esta vulnerabilidad son las siguientes:
La versión antigua de la vulnerabilidad (CVE-2006-5051) afecta a versiones de OpenSSH anteriores a OpenSSH 4.4/4.4p1 (27/09/2006), a menos que se les haya aplicado un parche para CVE-2006-5051 y CVE-2008-4109.
La regresión de la vulnerabilidad se introdujo en la versión OpenSSH 8.5/8.5p1 (03/03/2021).
Los responsables de mantenimiento de OpenSSH han corregido la vulnerabilidad en la versión OpenSSH 9.8/9.8p1 (01/07/2024).
Una forma de buscar servidores afectados es mediante la siguiente consulta de Insight:
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
A partir de nuestras observaciones, hemos detectado que el 75 % de las redes contaban con máquinas con una versión vulnerable de OpenSSH y, de media, aproximadamente el 35 % de las máquinas de cada red eran vulnerables. Afortunadamente, no hemos detectado ninguna máquina con un puerto SSH abierto arbitrariamente a Internet en nuestros entornos supervisados. Sin embargo, basta con realizar una búsqueda rápida en Shodan para ver más de 6 millones de equipos accesibles con una versión vulnerable (Figura).
Informe Shodan del 2 de julio de 2024 sobre máquinas vulnerables abiertas a Internet
Posible impacto
Dado que la vulnerabilidad actúa sobre OpenSSH de forma predeterminada, el impacto potencial es enorme: la mayoría de las distribuciones de Linux se ven afectadas, especialmente las versiones más recientes debido a la regresión.
Sin embargo, hay tres razones para no entrar en pánico:
La PoC actual es solo para procesadores con arquitectura x86, ya que su explotación en procesadores amd64 (que es el estándar actual) es exponencialmente más compleja, puesto que cuentan con protecciones de memoria más sólidas.
Actualmente se cree que se necesita mucho tiempo y varias conexiones para lograr el ataque. Por lo tanto, se activarían la mayoría de los detectores de ataque de fuerza bruta.
Teniendo en cuenta estos dos aspectos, lo más adecuado para lanzar este ataque sería utilizar Internet como vector de acceso inicial. Aun así, se puede mitigar parte del impacto con una segmentación adecuada para las conexiones SSH de Internet y para el tráfico de máquinas que necesitan tener interfaces SSH orientadas a Internet (como las soluciones de salto).
Mitigación
Aplicación de parches
La mejor opción es aplicar parches al software OpenSSH para actualizarlo a una versión que no tenga vulnerabilidades. Sin embargo, como OpenSSH normalmente viene incluido con las distribuciones de Linux, el proveedor debe sacar los parches para poder aplicarlos, lo que puede llevar tiempo y pruebas adicionales.
Los administradores de redes pueden utilizar la osquery que se proporciona en esta entrada de blog para detectar sus activos vulnerables y realizar un seguimiento de ellos a largo plazo. Los clientes de Akamai Guardicore Segmentation también pueden utilizar consultas programadas con el mismo fin y, tras ello, identificar sus activos en función de los resultados.
Segmentación
Como hemos señalado anteriormente, parece muy probable que se pueda aprovechar esta CVE para una filtración inicial en las redes, ya que ejecutar el ataque puede tardar horas, si no días. Por lo tanto, es crucial analizar todas las instancias de las interfaces OpenSSH de Internet, y cerrar o restringir el acceso a ellas.
Si necesita un acceso SSH arbitrario desde Internet, le recomendamos que aplique una segmentación de la red en las máquinas que utilice para restringir su acceso a la red interna y limitar el alcance de posibles ataques e infiltraciones.
Sensibilidad de las alertas a las amenazas
Como es posible que los parches que necesite no estén disponibles todavía, una opción prudente es aumentar la sensibilidad de las alertas en las cargas de trabajo potencialmente vulnerables y sin parches. De ese modo, incluso si se explota la vulnerabilidad sin detectarse, es posible que pueda conocer sus efectos secundarios. En particular, recomendamos la sensibilidad a los intentos de ataque de fuerza bruta, ya que es la forma más posible en la que se presenten.
No obstante, incrementar la sensibilidad de las alertas también aumentará su saturación. Por ello, también recomendamos ajustarla en función de la importancia de la carga de trabajo afectada para la red o su impacto.
Resumen
En esta entrada del blog, repasamos los últimos datos disponibles y revisados sobre regreSSHion, la nueva vulnerabilidad crítica de OpenSSH.
Para los defensores, una medida fundamental sería determinar la vulnerabilidad de las cargas de trabajo de su red. Además, hemos publicado una osquery con la que tratamos de ayudarle a detectar versiones vulnerables de OpenSSH. También hemos analizado qué se debe hacer para mitigar parte del riesgo (por ejemplo, ajustar la sensibilidad de las alertas a las amenazas) cuando no hay parches disponibles.
Esta publicación de blog ofrece una descripción general de nuestros conocimientos y recomendaciones actuales, dada la información disponible. Nuestra revisión se lleva a cabo de forma continua y cualquier información aquí contenida está sujeta a cambios. También puede visitar nuestra cuenta de X, anteriormente Twitter, para conocer las actualizaciones en tiempo real.