Error Crítico en OpenSSH Amenaza 700,000 Dispositivos Linux

El Error Crítico: ¿Qué Sabemos Hasta Ahora?

Un error crítico en el software OpenSSH, utilizado para conexiones seguras en sistemas Linux, ha sido descubierto y podría permitir a los atacantes tomar el control completo de los dispositivos vulnerables. Se estima que aproximadamente 700.000 dispositivos podrían verse afectados.

Para quienes no estén familiarizados, OpenSSH es un software esencial para las conexiones seguras en sistemas Linux. Permite a los usuarios conectarse de forma remota a sus dispositivos y transferir archivos sin problemas.

El problema surge con el descubrimiento de un error muy peligroso llamado "regreSSHion", que podría permitir a los atacantes ejecutar código malicioso en un dispositivo Linux vulnerable. La vulnerabilidad con el ID CVE-2024-6387, afecta al servidor OpenSSH (sshd), que está integrado en la mayoría de los sistemas operativos, muchos dispositivos IoT y cortafuegos. Aunque la descripción de la vulnerabilidad sugiere una amenaza potencialmente masiva, similar a WannaCry y Log4Shell, la situación es más compleja y es poco probable que la vulnerabilidad sea explotada de forma generalizada.

Sin embargo, es crucial que todos los administradores de servidores que utilizan OpenSSH aborden esta vulnerabilidad con urgencia. Parece que los sistemas con arquitecturas de 32 bits son los más vulnerables, aunque los de 64 bits también podrían estar en riesgo. Es importante destacar que los sistemas OpenBSD no se ven afectados por este problema.

Conoce más sobre: Monitoreo de Servidores Linux con OpManager

700.000 Dispositivos podrían verse afectados por 'regreSSHion'

Se cree que unos 700.000 dispositivos podrían verse afectados por 'regreSSHion'. En un análisis de seguridad, se identificó que esta vulnerabilidad es una regresión de la vulnerabilidad CVE-2006-5051, previamente parcheada en 2006. Una regresión en este contexto significa que una falla, una vez solucionada, ha reaparecido en una versión posterior del software, generalmente debido a cambios o actualizaciones que inadvertidamente reintroducen el problema.

Esta falla está presente en las siguientes versiones de OpenSSH en Linux:

• Las versiones de OpenSSH anteriores a 4.4p1 son vulnerables a esta condición de carrera del controlador de señales, a menos que hayan sido revisadas para CVE-2006-5051 y CVE-2008-4109.
• Las versiones desde 4.4p1 hasta, pero sin incluir, 8.5p1 no son vulnerables debido a un parche transformador para CVE-2006-5051, que mejoró la seguridad de una función crítica.
• La vulnerabilidad resurge en las versiones desde 8.5p1 hasta, pero sin incluir, 9.8p1 debido a la eliminación accidental de un componente crítico en una función.

Teniendo esto en cuenta, ¿qué se puede hacer para protegerse? La medida más importante es actualizar OpenSSH a la última versión lo antes posible. Las actualizaciones ya están disponibles para la mayoría de las distribuciones de Linux. Además, se recomienda limitar el acceso SSH a través de controles basados en la red, segmentar las redes y utilizar sistemas de monitoreo para detectar intentos de explotación.

Por último, y para la tranquilidad de los usuarios, se considera que el error "regreSSHion" es grave pero difícil de explotar. Expertos tardaron entre seis y ocho horas en superar todas las barreras y se necesitaron alrededor de 10.000 intentos. "Esta vulnerabilidad es difícil de explotar debido a su naturaleza de condición de carrera remota, que requiere múltiples intentos para un ataque exitoso", explican.

Te podrá interesar leer: ¿Cómo Priorizar los Parches de Software Eficazmente?

¿Cómo Proteger Servidores contra la Explotación?

Las versiones de OpenSSH hasta la 4.4p1, además de las versiones desde la 8.5p1 hasta la 9.7p1 que se ejecutan en glibc-Linux, son vulnerables. Los servidores basados en OpenBSD no se ven afectados, por lo que los administradores de estos servidores pueden estar más tranquilos; sin embargo, todos los demás deberían actualizar sshd a la versión 9.8.

Si por alguna razón no es posible realizar una actualización inmediata, los administradores pueden establecer el tiempo de espera de inicio de sesión en cero (LoginGraceTime=0 en sshd_config) como una mitigación temporal. Sin embargo, los desarrolladores advierten que esto hace que el servidor SSH sea más susceptible a ataques DDoS. Otra posible mitigación es implementar un control de acceso más estricto para SSH mediante firewalls y otras herramientas de seguridad de red.