Llegamos a la última lección del Módulo 3. En 03-01 abrimos los puertos y en 03-02 los convertimos en un inventario de servicios con versiones: Apache 2.4.29 con PHP 7.2.24 en la tienda, MySQL 5.5.62 expuesto en dev, un Werkzeug de desarrollo en el 54321, SMB con sesión nula, SNMP public... Tenemos software concreto con versiones concretas. Ahora toca la pregunta que lo conecta todo con la explotación: ¿cuáles de estos servicios son vulnerables, con qué gravedad y por dónde conviene empezar?

Detectar vulnerabilidades es cruzar cada servicio/versión con las bases de datos de vulnerabilidades conocidas (CVE, CPE, NVD, exploit-db) y con escáneres automáticos (Nessus/OpenVAS, nmap --script vuln, nuclei), para después validarlos críticamente —separando el falso positivo del hallazgo real—. El entregable es una lista priorizada de vulnerabilidades candidatas que alimenta directamente el Módulo 4. Encuadre de siempre: los escáneres de vulnerabilidades son ruidosos y a veces intrusivos (pueden reiniciar servicios frágiles), así que se lanzan dentro del alcance, en la ventana acordada y avisando; y detectar no es explotar: aquí identificamos y priorizamos, no lanzamos el exploit.

1. Qué es una vulnerabilidad y el ciclo CVE
2. El lenguaje común: CVE, CPE, NVD y CVSS
3. Búsqueda manual: searchsploit y exploit-db
4. Escaneo con Nmap: --script vuln
5. Escáneres de vulnerabilidades: Nessus y OpenVAS/GVM
6. nuclei: plantillas rápidas
7. Lectura crítica: falsos positivos y validación
8. La lista priorizada de vulnerabilidades de TechNova
9. Contrapartida defensiva
10. Errores comunes y consejos
11. Ejercicios
12. Conclusión

Una vulnerabilidad es un fallo (de software, configuración o diseño) que un atacante puede aprovechar para violar la seguridad del sistema. En esta fase nos centramos sobre todo en vulnerabilidades conocidas: las publicadas, con identificador y a menudo con exploit disponible. Su ciclo de vida:

El pentester trabaja en el tramo final: hay sistemas que no han aplicado el parche y siguen expuestos. Nuestro trabajo es detectar esos casos cruzando lo que corre (03-02) con lo que se sabe que es vulnerable.

Para hablar de vulnerabilidades con precisión hay un vocabulario estándar:

El puente clave es el CPE: el identificador de producto+versión que Nmap ya nos dio en 03-02 (cpe:/a:apache:http_server:2.4.29). Con ese CPE se consulta la NVD y salen todos los CVE que afectan a esa versión. El CVSS da una idea rápida de gravedad; usaremos la puntuación solo como orientación para priorizar —el detalle de cómo se calcula (vectores, métricas) es materia de 06-02—.

Antes de los escáneres, la vía más directa y controlada es buscar a mano. searchsploit es la copia local de exploit-db en Kali:

Lectura: destaca Werkzeug - Debug Shell Command Execution. Si el servidor de desarrollo del puerto 54321 tiene el modo debug activo (el famoso PIN de Werkzeug), podría permitir ejecución de comandos. Es una candidata fuerte para el Módulo 4. Para consultar el detalle o el CPE también sirve la web de la NVD filtrando por producto y versión.

La NSE incluye una categoría vuln que comprueba vulnerabilidades conocidas contra los servicios detectados. Es el paso natural tras la enumeración:

Análisis línea a línea:

• http-slowloris-check ... LIKELY VULNERABLE (CVE-2007-6750): posible denegación de servicio Slowloris. Ojo: los scripts DoS pueden tumbar el servicio; muchos solo lo comprueban sin lanzarlo, pero hay que usarlos con permiso.
• http-csrf: posible falta de protección CSRF en /login.php.
• http-sql-injection: Possible sqli for query: /producto.php?id=1': posible inyección SQL en el parámetro id de producto.php —justo el parámetro que el recon marcó en la tienda—. Es un candidato muy prometedor.

Fíjate en las palabras: "Possible", "LIKELY". Nmap señala candidatas, no confirma. La validación es el apartado 7.

Para cobertura amplia se usan escáneres dedicados, que prueban miles de comprobaciones y generan informes con gravedad. Los dos más habituales:

Ejemplo conceptual de resultado de un escaneo autenticado sobre dev:

Cada línea trae CVE, gravedad y una puntuación CVSS orientativa. Muy potente, pero con dos advertencias importantes: son ruidosos (un IDS los detecta al instante) y generan falsos positivos (por eso el apartado siguiente). Los escaneos autenticados (con credenciales que dé el cliente) son mucho más fiables que los no autenticados, porque ven las versiones reales en lugar de adivinar.

nuclei comprueba vulnerabilidades y exposiciones mediante plantillas (YAML) mantenidas por la comunidad. Es rápido, preciso y muy usado para superficie web:

Detecta el phpinfo.php, confirma PHP fuera de soporte y —hallazgo nuevo— un .git/config expuesto, que podría permitir descargar el código fuente. nuclei brilla por su bajo ruido relativo y su base de plantillas actualizada.

Este es el apartado que separa a un profesional de alguien que pega la salida de un escáner en el informe. Los escáneres se equivocan, en dos direcciones:

• Falso positivo: reporta una vulnerabilidad que no existe (p. ej. marca vulnerable por número de versión aunque haya un parche retroportado por la distribución —muy común en Debian/Ubuntu—).
• Falso negativo: no ve una vulnerabilidad real (configuración a medida, servicio no reconocido).

Por eso toda candidata se valida. Formas de hacerlo sin llegar a explotar:

• Contrastar la versión exacta y el parcheo. Ubuntu suele retroportar correcciones sin cambiar el número de versión visible; un CVE "detectado" por versión puede estar ya corregido.
• Cruzar varias fuentes. Si Nessus, --script vuln y searchsploit coinciden, la confianza sube.
• Comprobación manual ligera. Una petición controlada (p. ej. producto.php?id=1' y ver si el error revela SQL) confirma la sospecha sin lanzar aún un exploit completo.
• Descartar lo inaplicable. Un CVE de una función que el servicio no usa no es explotable en este contexto.

Cada candidata se etiqueta con un nivel de confianza (confirmada / probable / a validar). Sin este filtro, un informe se llena de ruido y pierde credibilidad.

Consolidamos todo en el entregable final del módulo: la lista priorizada de vulnerabilidades candidatas. Combina gravedad (CVSS orientativo), exposición y confianza tras la validación:

Cómo se lee:

• Lo crítico combina alta gravedad, exposición y una vía de acceso plausible: la SQLi en la tienda (objetivo principal, en Internet) y la consola de debug de Werkzeug (posible ejecución de comandos).
• MySQL 5.5 marca CVSS altísimo pero queda "a validar" por el posible retroporte de Ubuntu: se comprueba antes de darlo por bueno.
• Los hallazgos confirmados de configuración (sesión nula SMB, .bak/.git, SNMP public) son sólidos aunque su CVSS sea menor, porque no dependen de una versión y ya están verificados.

Esta tabla es exactamente lo que el Módulo 4 necesita: por dónde intentar entrar primero, con evidencia y confianza asociadas.

Frente a la detección de vulnerabilidades, la defensa se juega en la gestión de vulnerabilidades:

• Parchear y mantener soporte. El grueso de esta lista se evapora actualizando: PHP y MySQL soportados, dependencias al día. No usar software en fin de vida.
• Escaneo propio periódico. El defensor debe pasar Nessus/OpenVAS antes que el atacante y priorizar por CVSS y exposición.
• Corregir configuraciones. Quitar .bak, phpinfo.php y .git de producción; cerrar la sesión nula; cambiar la comunidad SNMP; desactivar el modo debug de Werkzeug.
• Detección: los escáneres de vulnerabilidades son muy ruidosos; un IDS/IPS y la monitorización de logs detectan el aluvión de peticiones y sondas. Que el cliente vea tu escaneo en sus alertas es, de hecho, una buena señal para su SOC.

• Copiar la salida del escáner tal cual. Sin validar, el informe se llena de falsos positivos y pierde credibilidad. Valida siempre antes de reportar.
• Ignorar los retroportes de la distribución. Un CVE "detectado" por versión puede estar ya parcheado en Ubuntu/Debian. Comprueba el estado real del parche.
• Lanzar escáneres sin avisar. Son intrusivos; algunos scripts (DoS, fuerza bruta) pueden tumbar servicios. Ventana acordada y aviso al contacto técnico, siempre.
• Confundir detectar con explotar. Aquí produces candidatas priorizadas; lanzar el exploit es el Módulo 4 y requiere que el alcance lo autorice.
• Obsesionarse con el CVSS. Una SQLi en la web pública pesa más que un CVSS 9.8 en un servicio inaccesible. Cruza gravedad con exposición y confianza.
• Olvidar los hallazgos de configuración. Sesión nula, .git expuesto o SNMP public no tienen CVE pero suelen ser las vías más fiables. No los infravalores.
• Consejo: combina siempre escáner + búsqueda manual + validación. La automatización cubre volumen; el criterio humano decide qué es real y qué importa.

Ejercicio 1. Un escaneo con Nessus marca MySQL 5.5.62 como CRÍTICO (CVSS 9.8) en dev. Describe los pasos que darías para validar si es un hallazgo real o un falso positivo, sin llegar a explotarlo, y menciona al menos una causa habitual de falso positivo en Ubuntu.

Ejercicio 2. Del inventario de TechNova tienes dos candidatas: (a) una posible SQLi en tienda.technova.lab/producto.php?id= (Internet, objetivo principal) y (b) un CVE de OpenSSH 7.6 de enumeración de usuarios en dev (interno). Ambas "detectadas" por escáner. Prioriza para el Módulo 4 y justifica cruzando gravedad, exposición y confianza.

Ejercicio 3. Explica por qué un hallazgo sin CVE como la sesión nula de SMB con el recurso RRHH accesible puede ser más valioso para el Módulo 4 que un CVE con CVSS 9.8 detectado solo por número de versión.

Solución 1. Pasos de validación: (1) confirmar la versión exacta con nmap --script mysql-info y banner, no fiarse solo del escáner; (2) comprobar el estado del parche: en Ubuntu los paquetes conservan el número de versión (5.5.62-0ubuntu…) aunque se hayan retroportado correcciones de seguridad —causa habitual de falso positivo—, así que hay que mirar el changelog del paquete y los avisos de seguridad de Ubuntu (USN); (3) cruzar fuentes: ver si searchsploit y la NVD confirman que ese CVE aplica a esa build concreta y que la funcionalidad afectada está en uso; (4) etiquetar la candidata como "confirmada" o "descartada" según el resultado. Todo sin lanzar el exploit: solo verificamos aplicabilidad.

Solución 2. Prioridad: 1.º (a) la SQLi de la tienda. Aunque ambas las marque un escáner, la SQLi combina gravedad muy alta (acceso potencial a la base de datos), máxima exposición (Internet, objetivo principal del alcance) y una vía de acceso directa; se valida con una comprobación manual ligera (id=1') que sube rápido la confianza. 2.º (b) la enumeración de usuarios de OpenSSH: gravedad media, exposición baja (host interno) y solo aporta nombres de usuario, no acceso; es útil como apoyo (alimenta ataques de contraseñas), no como vía principal. El criterio: a igualdad de "detectado por escáner", mandan exposición e impacto real.

Solución 3. Porque la sesión nula de SMB está confirmada y es directamente accionable: ya sabemos que da acceso a usuarios reales y a documentos de RRHH sin credenciales, es una vía real y verificada. En cambio, un CVE 9.8 "detectado solo por número de versión" es una sospecha sin validar: puede ser un falso positivo (parche retroportado), puede requerir condiciones que no se cumplen, o no tener exploit fiable. En pentesting vale más una vía modesta confirmada que una crítica incierta: la primera es una entrada; la segunda, todavía una hipótesis.

Cerramos el Módulo 3. Empezamos con una lista de hosts vivos y la hemos convertido, paso a paso, en algo accionable: primero los puertos abiertos (03-01), luego los servicios con versiones (03-02) y ahora una lista priorizada de vulnerabilidades candidatas (03-03), cada una con su referencia, su gravedad orientativa y —lo más importante— su nivel de confianza tras validarla. Hemos aprendido el lenguaje común (CVE, CPE, NVD, CVSS), a buscar a mano (searchsploit/exploit-db) y con escáneres (--script vuln, Nessus, OpenVAS, nuclei), y a leer sus resultados con espíritu crítico para no ahogarnos en falsos positivos.

Recapitulando el módulo entero: el reconocimiento nos dijo dónde mirar; el escaneo y la enumeración nos han dicho qué hay exactamente y qué de eso es débil. TechNova ya no es una caja negra: sabemos que su tienda expone una probable inyección SQL y ficheros sensibles, que dev corre una consola de debug y una base de datos anticuada expuesta, y que la red interna regala información por SMB y SNMP. Todo documentado, validado y ordenado por prioridad.

Y aquí termina el trabajo de "identificar". Hasta ahora no hemos explotado nada: hemos dibujado el mapa de puertas débiles. En el Módulo 4: Explotación de Vulnerabilidades, cogeremos la candidata número uno de esta lista y pasaremos —siempre dentro del alcance, con permiso explícito y control del impacto— de "esto parece vulnerable" a "esto es explotable y esto es lo que un atacante conseguiría". La primera lección, 04-01 Introducción a la Explotación, arranca justo aquí: con nuestra lista priorizada de vulnerabilidades candidatas en la mano.