Aálisis del Falso Positivo CVE-2002-20001 en Escáneres de Vulnerabilidades

Al ejecutar escaneos de puertos completos con herramientas como Nessus, es común encontrar alertas críticas asociadas al servicio OpenSSH bajo el identificador CVE-2002-20001, clasificado como un riesgo de Ejecución Remota de Código (RCE). Sin embargo, al consultar las bases de datos oficiales como NVD o MITRE, este identificador no existe. Se trata de un falso positivo generado por una lógica de detección obsoleta dentro de los plugins del escáner, específicamente relacionada con un mapeo incorrecto de banners y versiones.

Este error suele aparecer en entornos que ejecutan versiones como CentOS 7 con OpenSSH 7.4p1, incluso cuando todos los parches oficiales del proveedor están aplicados. El problema no reside en el servicio SSH, sino en una expresión regular demasiado permisiva en el plugin de detección y una relación de mapeo CVE codificada de forma rígida que ya fue descartada por los desarrolladores del escáner, pero que persiste en instalaciones con bases de datos de plugins desactualizadas.

Identificación y Aislamiento del Plugin Problemático

Cada regla de detección en Nessus opera como un plugin independiente con un identificador único. Para eliminar este falso positivo, es necesario localizar y gestionar el plugin específico que genera la alerta.

Extracción del ID del Plugin desde el Reporte

Al exportar los resultados en formato .nessus (XML), se pueden inspeccionar los metadatos completos de cada hallazgo. Buscando la cadena del CVE en el archivo, se encontrará una estructura similar a la siguiente:

<Vulnerability port="22" service="ssh" protocol="tcp" severity_level="3">
  <output>Detected SSH version: OpenSSH_7.4p1</output>
  <name>SSH Service Version Detection</name>
  <id>10863</id>
  <cve_id>CVE-2002-20001</cve_id>
  <risk>High</risk>
</Vulnerability>

El identificador 10863 corresponde al plugin "SSH Server Type and Version Detection". Este script analiza el banner TCP para determinar la versión, pero en versiones antiguas, asociaba erróneamente ciertos banners (especialmente aquellos con cadenas como libwrap) a este CVE inexistente.

Validación de la Lógica de Detección

El código fuente NASL (Nessus Attack Scripting Language) del plugin revela cómo se propaga el error. Una versión simplificada de la lógica problemática muestra la asignación incondicional de un elemento en la base de conocimientos (KB):

# Lógica simplificada del plugin 10863
if (ssh_banner =~ "OpenSSH[_ ]([0-9]+)\.([0-9]+)") {
  major_ver = eregmatch(ssh_banner, "OpenSSH[_ ]([0-9]+)\.([0-9]+)")[1];
  minor_ver = eregmatch(ssh_banner, "OpenSSH[_ ]([0-9]+)\.([0-9]+)")[2];
  
  if (major_ver == "6" || (major_ver == "7" && minor_ver <= "1")) {
    # Asignación errónea a la base de conocimientos
    set_kb_item(name:"SSH/Host/Fake_CVE_2002_20001", value:TRUE);
  }
}

Plugins secundarios leen este valor de la KB y lo renderizan en el informe final como un CVE válido. La raíz del falso positivo es la manipulación o detección incorrecta del banner, no una vulnerabilidad real en el binario.

Estrategias de Remediación: Supresión del Plugin vs. Actualización del Servicio

Existen dos enfoques técnicos para resolver esta situación sin afectar la disponibilidad del servicio ni interrumpir las sesiones activas.

Opción A: Filtrado del Plugin en la Política de Escaneo

Para entornos donde no se pueden realizar cambios en los servidores de producción, la solución más rápida es ajustar la política de escaneo para ignorar este identificador específico.

1. Crear una nueva política de escaneo basada en la plantilla "Advenced Scan".
2. Navegar a la sección de "Plugins" y deshabilitar temporalmente todos los plugins.
3. Buscar el ID 10863 y asegurarse de que permanezca deshabilitado, o utilizar la función de "Plugin Filters" para excluirlo permanentemente.
4. Configurar el filtro: Plugin ID | is | 10863 | Disable.

Esto elimina el falso positivo sin afectar la detección de algoritmos de cifrado débiles u otras configuraciones inseguras de SSH.

Opción B: Actualización Segura de OpenSSH con Transición Atómica

Si las políticas de cumplimiento exigen la eliminación de cualquier alerta de alto riesgo o si la versión de OpenSSH es genuinamente antigua, se debe realizar una actualización. Para evitar la interrupción de sesiones SSH activas, se utiliza un enfoque de doble demonio.

Preparación y Respaldo:

# Respaldo de binarios y configuraciones críticas
tar -czvf /opt/ssh_binaries_backup.tar.gz $(rpm -ql openssh-server | grep -E 'bin|sbin')
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%F)

Instalación y Validación en Puerto Alternativo:

# Instalación del paquete sin ejecutar scripts de post-instalación
rpm -Uvh --noscripts openssh-8.9p1-1.el8.x86_64.rpm

# Configuración del puerto alternativo para pruebas
cp /etc/ssh/sshd_config /etc/ssh/sshd_config_alt
sed -i 's/^#Port 22/Port 2022/' /etc/ssh/sshd_config_alt

# Inicio del demonio secundario
/usr/sbin/sshd -f /etc/ssh/sshd_config_alt -p 2022

# Validación de conectividad
ssh -p 2022 localhost "echo 'Conexion exitosa'"

Transición al Puerto Principal:

# Detener el servicio original (las sesiones activas no se cierran)
systemctl stop sshd

# Reemplazar configuración y ajustar puerto
mv /etc/ssh/sshd_config_alt /etc/ssh/sshd_config
sed -i 's/Port 2022/Port 22/' /etc/ssh/sshd_config

# Iniciar el nuevo servicio
systemctl start sshd

Vulnerabilidades Reales y Críticas en OpenSSH

Es fundamental redirigir los esfuerzos de seguridad hacia vulnerabilidades reales y explotables. A continuación, se detallan identificadores CVE críticos que requieren atención inmediata:

Para verificar la exposición a CVE-2023-48795 (Terrapin), se puede utiliazr el siguiente comando de extracción de versión:

# Verificación de versión vulnerable a Terrapin
ssh -V 2>&1 | awk '{print $1}' | grep -E "OpenSSH_[1-8]\.|OpenSSH_9\.[0-5]"

Implementación de una Línea Base de Seguridad Persistente

Para mantener un entorno robusto, se deben aplicar configuraciones endurecidas y mecanismos de monitoreo continuo.

Plantilla de Configuración sshd_config Endurecida

La siguiente configuración equilibra los requisitos de seguridad estrictos con la operatividad del sistema, deshabilitando algoritmos obsoletos y restringiendo métodos de autenticación:

# Configuración endurecida para sshd
Port 22
AddressFamily inet
Protocol 2
PermitRootLogin prohibit-password
MaxAuthTries 4
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server

# Algoritmos criptográficos robustos
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

Monitoreo de Comportamiento en Tiempo de Ejecución

La seguridad proactiva requiere la detección de anomalías operativas. Los siguientes scripts permiten identificar intentos de fuerza bruta, modificaciones no autorizadas en claves y procesos hijo sospechosos:

# Detección de intentos de fuerza bruta (más de 10 fallos por IP)
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | awk '$1 > 10 {print $2}'

# Auditoría de modificación de claves autorizadas mediante auditd
auditctl -w /root/.ssh/authorized_keys -p wa -k ssh_key_modification

# Identificación de shells interactivos o scripts bajo el árbol de procesos de sshd
pstree -p $(pgrep sshd) | grep -E "(bash|sh|python|perl)"