Análisis de Vulnerabilidades

Qué es el Análisis de Vulnerabilidades

El análisis de vulnerabilidades es la fase donde correlacionas los servicios y versiones que descubriste con debilidades de seguridad conocidas. Es el puente entre saber qué corre en un sistema y entender qué podría salir mal. El objetivo es construir una lista priorizada de vulnerabilidades reales y relevantes, no una avalancha de ruido.

Esta fase combina herramientas automatizadas con análisis humano. Los escáneres encuentran candidatos rápidamente, pero el pentester valida cada hallazgo, descarta falsos positivos y evalúa el impacto real en el contexto del cliente. La automatización amplifica tu alcance, pero el criterio profesional es lo que convierte datos crudos en hallazgos accionables.

Un buen análisis de vulnerabilidades distingue entre lo teóricamente posible y lo prácticamente explotable. Una vulnerabilidad crítica detrás de varias capas de mitigación puede ser menos urgente que una media directamente accesible desde internet.

Marco ético: valida los hallazgos con criterio y sin causar daño; una prueba de concepto controlada solo cuando el alcance lo permita.

Escáneres de Vulnerabilidades

Los escáneres de vulnerabilidades automatizan la detección comparando sistemas contra bases de datos de fallas conocidas. Nessus es uno de los más usados a nivel comercial: ofrece escaneos profundos, una amplia base de plugins y reportes detallados. OpenVAS (parte de Greenbone) es su alternativa de código abierto, muy capaz para evaluaciones de red.

Para aplicaciones web y descubrimiento moderno, Nuclei se ha vuelto enormemente popular. Usa plantillas (templates) en YAML mantenidas por la comunidad que describen cómo detectar vulnerabilidades y configuraciones incorrectas específicas. Su velocidad y la enorme biblioteca de plantillas lo hacen ideal para escanear muchos objetivos rápidamente y mantenerse al día con fallas recientes.

Cada escáner tiene fortalezas distintas. Nessus y OpenVAS brillan en infraestructura de red; Nuclei destaca en superficie web y verificación dirigida. Combinarlos da cobertura amplia, siempre validando manualmente lo que reportan.

Flujo conceptual de un escaneo autorizado

El flujo de trabajo de un escáner como OpenVAS/Greenbone o Nessus sigue siempre el mismo patrón: defines el objetivo dentro del alcance, configuras la política de escaneo, lanzas la tarea y exportas el reporte para analizarlo. Estos comandos son ilustrativos: muestran el ciclo, no un ataque.

# Flujo conceptual con Greenbone (OpenVAS) vía su CLI gvm-cli.
# 1) Crear un target restringido ESTRICTAMENTE al alcance autorizado
gvm-cli ... --xml '<create_target><name>cliente-scope</name><hosts>10.0.10.0/24</hosts></create_target>'

# 2) Crear una tarea que asocie ese target con una config de escaneo
gvm-cli ... --xml '<create_task><name>eval-trimestral</name><target id="TARGET_ID"/><config id="CONFIG_ID"/></create_task>'

# 3) Lanzar el escaneo (solo tras confirmar la autorización por escrito)
gvm-cli ... --xml '<start_task task_id="TASK_ID"/>'

# 4) Exportar el reporte para correlación y priorización manual
gvm-cli ... --xml '<get_reports report_id="REPORT_ID" format_id="PDF"/>' > reporte.pdf

Nuclei aborda la superficie web con plantillas versionadas por la comunidad. Córrelo solo contra objetivos autorizados y con control de la tasa de peticiones para no degradar el servicio del cliente.

# Escaneo con plantillas de la comunidad, limitado a un host del alcance.
# Las plantillas de cves/ verifican fallas conocidas sin armar exploits.
nuclei -u https://ejemplo.com -t cves/ -rate-limit 20 -o hallazgos.txt

Correlación con Exploit-DB

Una vez identificada una versión concreta, puedes consultar bases de exploits públicos para entender si existe código conocido que confirme la explotabilidad. searchsploit es un cliente local de Exploit-DB que consultas offline. El objetivo aquí es de correlación y validación, no de lanzar nada: saber que un fallo tiene exploit público sube su prioridad real.

# Buscar entradas públicas conocidas para una versión específica.
# Sirve para correlacionar el hallazgo del escáner con exploits documentados.
searchsploit apache 2.4.49

# Ver el detalle y las referencias de una entrada (solo lectura para análisis)
searchsploit -x path/al/archivo.txt

Que exista un exploit público no significa que debas ejecutarlo. Significa que la vulnerabilidad tiene mayor probabilidad de ser aprovechada en la práctica, un insumo clave para la priorización.

Entendiendo los CVEs

Un CVE (Common Vulnerabilities and Exposures) es un identificador único asignado a una vulnerabilidad conocida públicamente, con el formato CVE-AÑO-NÚMERO. El sistema CVE, mantenido por MITRE, permite que toda la industria se refiera a la misma falla de forma inequívoca. Cuando un escáner reporta un CVE, puedes investigar exactamente qué es, qué afecta y cómo se remedia.

La National Vulnerability Database (NVD) del NIST enriquece cada CVE con detalles técnicos, versiones afectadas, referencias y puntuaciones de severidad. Consultar la NVD o fuentes como los avisos del fabricante te permite entender el contexto completo de una vulnerabilidad antes de actuar sobre ella.

# Consulta conceptual a la NVD por un CVE concreto (API pública, solo lectura).
# Devuelve descripción, vector CVSS, versiones afectadas y referencias.
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-41773"

No todos los CVEs son iguales ni igualmente relevantes. Algunos requieren condiciones muy específicas para explotarse; otros son triviales y ampliamente aprovechados. Parte del análisis es leer la descripción del CVE con criterio y entender si las condiciones de explotación se cumplen en el entorno que estás evaluando.

Anatomía del CVSS v3.1

El CVSS (Common Vulnerability Scoring System) es el estándar para puntuar la severidad de una vulnerabilidad en una escala de 0 a 10. Se organiza en tres grupos de métricas: base (características intrínsecas e invariables del fallo), temporales (cómo evoluciona con el tiempo) y ambientales (relevancia para tu entorno específico). La puntuación se traduce en categorías: baja, media, alta y crítica.

El vector CVSS codifica todas las métricas en una cadena legible. Por ejemplo:

# Vector base de una vulnerabilidad crítica (puntúa 9.8/10).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cada métrica base describe un aspecto del fallo:

• AV — Attack Vector (N=Network, A=Adjacent, L=Local, P=Physical): desde dónde se puede explotar. N significa accesible por red, el peor caso.
• AC — Attack Complexity (L=Low, H=High): cuánto esfuerzo o condiciones especiales requiere. L significa trivial.
• PR — Privileges Required (N=None, L=Low, H=High): qué nivel de acceso necesita el atacante antes de explotar.
• UI — User Interaction (N=None, R=Required): si hace falta que una víctima haga algo (clic, apertura de archivo).
• S — Scope (U=Unchanged, C=Changed): si el impacto se limita al componente vulnerable o escala a otros.
• C / I / A — Confidencialidad, Integridad, Disponibilidad (N=None, L=Low, H=High): la tríada de impacto sobre los datos y el servicio.

Las métricas temporales ajustan la nota según la madurez del exploit, la disponibilidad de remediación y la confianza en el reporte. Las métricas ambientales te permiten recalcular la severidad según la criticidad del activo en tu organización: un fallo con impacto alto en un sistema aislado sin datos sensibles puede rebajarse, mientras que uno en un servidor de producción expuesto puede elevarse.

CVSS te da un punto de partida objetivo para priorizar, pero no es la palabra final. Una vulnerabilidad con CVSS alto que solo es accesible desde una red interna aislada puede ser menos urgente que una de severidad media expuesta directamente a internet. Como pentester, tu valor está en traducir puntuaciones genéricas en prioridades concretas para el cliente.

Priorización Moderna: EPSS y KEV

CVSS mide severidad teórica, pero no predice si una falla será realmente explotada. Dos insumos modernos completan el cuadro:

• EPSS (Exploit Prediction Scoring System), de FIRST, asigna a cada CVE una probabilidad (de 0 a 1) de que sea explotado en los próximos 30 días, basándose en datos observados de actividad real. Un CVSS alto con EPSS bajo puede esperar; un CVSS medio con EPSS alto merece atención inmediata.
• El catálogo KEV (Known Exploited Vulnerabilities) de CISA lista las vulnerabilidades que se sabe que están siendo explotadas activamente en el mundo real. Si un CVE está en el KEV, deja de debatir: es prioridad máxima, sin importar su nota CVSS.

Combinar CVSS (severidad) + EPSS (probabilidad de explotación) + KEV (explotación confirmada) produce una priorización mucho más honesta que cualquier métrica aislada. Prioriza primero lo que está en el KEV, luego lo de EPSS alto, y usa CVSS para desempatar según el contexto del activo.

MITRE ATT&CK y Threat Modeling

El análisis de vulnerabilidades no termina en una lista de CVEs: alimenta el modelado de amenazas. MITRE ATT&CK es una base de conocimiento de tácticas y técnicas que usan los adversarios reales, organizada por fases (acceso inicial, ejecución, persistencia, movimiento lateral, exfiltración, etc.).

Mapear tus hallazgos contra ATT&CK convierte vulnerabilidades sueltas en escenarios de ataque coherentes. Por ejemplo, un servicio web vulnerable puede ser un vector de acceso inicial (TA0001), que combinado con credenciales débiles habilita movimiento lateral. Este encuadre ayuda al cliente a entender no solo qué está roto, sino cómo un atacante encadenaría los fallos para alcanzar un objetivo. El threat modeling prioriza rutas de ataque completas, no debilidades aisladas.

Falsos Positivos y Validación

Los escáneres automatizados son propensos a falsos positivos: hallazgos que el escáner marca como vulnerables pero que en realidad no lo son, por ejemplo porque la versión fue parcheada sin cambiar el banner, o porque una mitigación neutraliza el riesgo. Reportar falsos positivos al cliente daña tu credibilidad y le hace perder tiempo.

Por eso, la validación manual es indispensable. Antes de incluir un hallazgo en el reporte, confirma que la vulnerabilidad existe y es relevante en el contexto real. Esto puede implicar revisar configuraciones, comprobar versiones exactas o, cuando el scope lo permite, una prueba de concepto controlada que demuestre el problema sin causar daño.

La validación también funciona en la otra dirección: los escáneres producen falsos negativos, omitiendo vulnerabilidades reales. Por eso el análisis humano complementa siempre a la automatización, buscando lo que las herramientas no ven, como lógica de negocio defectuosa o cadenas de fallos menores que combinadas son críticas.

Mini-escenario: descartar un falso positivo

Supongamos que Nessus reporta CVE-2021-41773 (path traversal en Apache 2.4.49) sobre un servidor del alcance. Antes de escribirlo como crítico, sigue un flujo de validación sin causar daño:

1. Confirma la versión exacta. El banner dice Apache/2.4.49, pero el paquete del sistema puede tener un backport de seguridad que corrige el fallo sin cambiar el número de versión visible.
2. Revisa la configuración relevante. El CVE solo aplica si la directiva require all denied no protege los directorios y mod_cgi está habilitado. Si la config del cliente ya mitiga esas condiciones, el hallazgo no es explotable.
3. Contrasta con EPSS y KEV. Este CVE sí está en el KEV de CISA, lo que sube su prioridad si resulta ser real.
4. Concluye con evidencia. Si la versión está parcheada por backport, lo documentas como falso positivo con la evidencia (salida del gestor de paquetes), y no lo reportas como vulnerabilidad activa.

Ese criterio, aplicado sistemáticamente, es lo que separa un reporte confiable de un volcado de escáner.

De los Hallazgos a la Acción

El producto de esta fase es una lista de vulnerabilidades validadas, priorizadas y documentadas que alimenta tanto la fase de explotación como el reporte final. Cada entrada debe incluir el activo afectado, la vulnerabilidad, su severidad, la evidencia y una hipótesis de impacto. Esta estructura facilita decidir qué explotar y qué recomendar remediar primero.

Mantén el análisis enfocado en lo que aporta valor real. Es tentador reportar cada hallazgo menor que arroja un escáner, pero un reporte saturado de ruido de baja prioridad diluye los hallazgos críticos. La priorización inteligente — apoyada en CVSS pero guiada por EPSS, el KEV y el contexto — es lo que distingue un análisis profesional de un volcado automático de resultados.

Checklist de Cierre

Antes de dar por cerrada la fase de análisis, verifica:

• [ ] Todos los objetivos escaneados están dentro del alcance autorizado por escrito.
• [ ] Cada hallazgo del escáner fue validado manualmente y los falsos positivos, descartados con evidencia.
• [ ] Cada vulnerabilidad tiene su CVE, vector CVSS y categoría de severidad documentados.
• [ ] La priorización cruza CVSS + EPSS + KEV y el contexto real del activo.
• [ ] Los hallazgos relevantes están mapeados a MITRE ATT&CK cuando aporta claridad al escenario de ataque.
• [ ] Cada entrada incluye activo afectado, evidencia e hipótesis de impacto reproducible.
• [ ] Ninguna prueba de concepto causó daño ni excedió el alcance acordado.