GhostOffensiveMódulo 09Con laboratorio

Búsqueda de exploits públicos

Saber que un servicio tiene una versión concreta no sirve de nada si no sabes si alguien ya encontró (y publicó) cómo atacarla. Este módulo trata solo de eso: encontrar, entre miles de exploits publicados, el que corresponde exactamente a lo que tienes delante. Explotarlo con garantías es el módulo siguiente.

Objetivos de la unidad

Entender el ecosistema de identificadores: CVE, CVSS, EDB-ID, y cómo se relacionan.
Usar searchsploit a fondo para consultar Exploit-DB sin conexión.
Conocer las fuentes públicas y cuándo fiarse de cada una.
Distinguir un exploit aplicable de uno que solo se le parece.
Leer y auditar un exploit ajeno antes de ejecutarlo (seguridad y confianza).
Aceptar que, a veces, la respuesta correcta es que no hay exploit público fiable.

1. El ecosistema de identificadores

Para moverte por las fuentes públicas hay que tener claro quién es quién, porque se confunden constantemente:

Identificador	Qué es	Quién lo asigna
CVE (CVE-AAAA-NNNN)	Nombre único de una vulnerabilidad. Describe el fallo, no cómo explotarlo.	MITRE y CNAs
CVSS (0.0–10.0)	Puntuación de gravedad de un CVE, con un vector que detalla el porqué.	NVD y fabricantes
EDB-ID	Número de un exploit concreto en Exploit-DB. Un CVE puede tener varios EDB-ID (o ninguno).	Exploit-DB

La relación no es uno a uno: una vulnerabilidad (CVE) puede tener cero, uno o varios exploits publicados (EDB-ID), y algunos exploits reales no tienen CVE (lo vemos en la sección 4). Manejar bien esta distinción es la mitad del trabajo de este módulo.

2. searchsploit: Exploit-DB sin conexión

Kali incluye una copia local de Exploit-DB (paquete exploitdb), consultable con searchsploit sin conexión. La buena práctica es buscar por producto y versión, y afinar:

kali@lab (salida real)

$ searchsploit vsftpd 2.3.4
vsftpd 2.3.4 - Backdoor Command Execution               | unix/remote/49757.py
vsftpd 2.3.4 - Backdoor Command Execution (Metasploit)  | unix/remote/17491.rb

El número al final de la ruta es el EDB-ID. Para ver el CVE asociado a cada uno, la salida en JSON (-j) incluye un campo Codes; para leer el exploit sin salir de la terminal, -x; y para copiarlo a tu directorio de trabajo, -m:

kali@lab (salida real)

$ searchsploit -j vsftpd 2.3.4   # incluye el CVE de cada resultado
(JSON con el campo "Codes": CVE-2011-2523)

kali@lab

$ searchsploit -x unix/remote/49757.py   # leer el exploit

kali@lab

$ searchsploit -m unix/remote/49757.py   # copiarlo aquí para adaptarlo (módulo 10)

Un aviso: la copia local se queda desactualizada. Para lo reciente, searchsploit -u la refresca, pero para vulnerabilidades de los últimos meses conviene ir también a las fuentes en línea.

3. Otras fuentes públicas y cuándo fiarse

Fuente	Qué aporta	Fiabilidad
Exploit-DB	Prueba de concepto, a veces funcional tal cual	Alta, pero suele necesitar adaptación (módulo 10)
NVD / MITRE	Descripción oficial, CVSS, versiones afectadas	Máxima para describir; no da exploit
GitHub	PoC que no llegan a Exploit-DB, versiones actualizadas	Variable: audita el código antes de ejecutarlo
Avisos del fabricante	Qué versiones están de verdad afectadas y el parche	La fuente de verdad sobre alcance y versiones
Metasploit	Módulos integrados y probados (`search` en `msfconsole`)	Alta y fácil de usar (módulo 17)

4. Un CVE no es un exploit, y un exploit no siempre tiene CVE

Las dos confusiones más frecuentes, cada una con su consecuencia práctica:

Un CVE identifica una vulnerabilidad: describe el problema, pero no te da necesariamente un método para explotarlo. Un CVE con CVSS 9.8 puede no tener aún ninguna PoC pública.
Un exploit es el código que demuestra o automatiza el ataque. La mayoría referencia un CVE, pero no todos: muchas vías reales —credenciales por defecto, una funcionalidad legítima abusada (como cargar módulos en un Redis sin autenticación), una mala configuración— son explotables y están documentadas sin que nadie les asigne un CVE. Buscar solo por CVE te haría pasar por alto toda esa categoría.

5. Auditar el exploit antes de ejecutarlo

Un exploit descargado es código ajeno que vas a ejecutar, a veces con privilegios, a veces contra el sistema de un cliente. Léelo siempre antes. Dos razones: la primera, de funcionamiento —qué hace, contra qué versión, qué condiciones exige— que es lo que te permite adaptarlo (módulo 10); la segunda, de seguridad —hay PoC públicas con puertas traseras ocultas, cargas que borran datos o que llaman a casa—. Ejecutar a ciegas un exploit de un repositorio desconocido es una forma habitual de que el atacante acabe siendo la víctima. Desconfía especialmente de binarios ya compilados y de one-liners ofuscados.

6. Verificar antes de dar un hallazgo por bueno

Encontrar un resultado que "suena parecido" no es suficiente. Antes de dar un exploit por aplicable, comprueba:

La versión exacta. Muchos servicios tienen varios exploits publicados para rangos de versión distintos; el mismo software en una versión más reciente o más antigua puede no ser vulnerable a ese en concreto.
Las condiciones previas. Algunos exploits requieren autenticación, una configuración concreta, o un módulo específico habilitado.
La plataforma. Un exploit para Linux no sirve contra el mismo software en Windows, y viceversa.
La fecha y las referencias cruzadas. Si el CVE y el EDB-ID no coinciden entre sí, algo no encaja.

La pregunta que de verdad importa no es "¿hay algún exploit para este software?", sino "¿hay un exploit para esta versión exacta, en esta plataforma, en estas condiciones?". Confundir las dos cosas es la forma más habitual de perder tiempo persiguiendo un exploit que nunca iba a funcionar.

7. Cuando la respuesta es que no hay exploit

No todo software desactualizado tiene un exploit público de ejecución remota. Muchos CVE solo permiten denegación de servicio, requieren acceso local previo, o simplemente nadie ha publicado aún una prueba de concepto funcional. Reconocer que no existe una vía pública y pasar a otra cosa es tan valioso como encontrar el exploit correcto: evita perder horas sobre un callejón sin salida, que en una auditoría con tiempo limitado es un error caro.

Para profundizar

NVD (nvd.nist.gov) y cve.org para leer la ficha oficial de un CVE y su vector CVSS.
La guía de Metasploit de Ghost Academy (ver "Herramientas relacionadas") para el mismo trabajo desde search en msfconsole.
Práctica sana: elige un CVE reciente y rastrea su cadena completa —aviso del fabricante → CVE en la NVD → PoC en GitHub o Exploit-DB— para ver cómo se conectan las fuentes.

🧰 Herramientas relacionadas (Ghost Academy)

Guías y laboratorios ya publicados en Ghost Academy sobre las herramientas de este módulo:

Metasploit · GTFOBins

Laboratorio: Quasar Devices

⬇ Descargar laboratorio (ZIP)

Descomprime, lee el LEEME.md y lanza startlab.sh. Aquí no hay nada que explotar: es un informe de reconocimiento ya hecho, con 8 servicios y sus versiones exactas. Busca en fuentes públicas la referencia correcta para cada uno (un CVE, un EDB-ID, o NINGUNO si concluyes que no existe un exploit público fiable) y encuentra las 8 flags GO{...}. Verifícalas en http://localhost:8686/verificador.

Uno de los ocho es una trampa a propósito.

¿Atascado o ya terminado? La solución paso a paso revela todas las flags. Úsala cuando lo hayas intentado.

Autoevaluación

¿Qué diferencia hay entre un CVE, su CVSS y un EDB-ID?
¿Puede un CVE con CVSS 9.8 no tener ninguna PoC pública? ¿Qué implica eso para ti?
Da un ejemplo de por qué un exploit "para el mismo software" puede no aplicar a tu objetivo.
¿Por qué puede existir un exploit real y útil sin ningún CVE asociado?
Da dos razones por las que hay que leer un exploit descargado antes de ejecutarlo.
¿Qué harías si, tras buscar en varias fuentes, no encuentras ningún exploit público para un servicio?