Parte: 5 — Explotación de sistemas y binarios · Fuente: Dowd, McDonald, Schuh, The Art of Software Security Assessment ⏱️ Duración estimada: 120 min · Nivel: Avanzado
Aprender a encontrar vulnerabilidades de forma sistemática combinando auditoría manual de código, análisis estático automatizado (SAST) y razonamiento sobre superficies de ataque. Complementa el fuzzing (clase 136) con la revisión dirigida que detecta bugs lógicos y patrones peligrosos que el fuzzer no alcanza fácilmente. Cerrarás con la práctica de divulgación responsable.
⚠️ Ética: audita código propio, open source o con autorización. Reporta de forma responsable (coordinated disclosure), nunca publiques 0-days de terceros sin proceso.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Superficie de ataque y fuentes de entrada | Dónde entran los datos no confiables |
| 2 | Patrones peligrosos en C/C++ | Dónde suelen estar los bugs |
| 3 | Taint / seguimiento de datos | Del input a la operación peligrosa |
| 4 | SAST (cppcheck, clang, Semgrep) | Automatizar la detección |
| 5 | CodeQL | Consultas semánticas de vulns |
| 6 | Falsos positivos/negativos | Interpretar con criterio |
| 7 | Priorización por explotabilidad | Enfocar el esfuerzo |
| 8 | Reporte y disclosure | Cerrar el ciclo con ética |
memcpy,
índices, system). Clave: fuente→sumidero.sudo apt install -y cppcheck clang-tools
pip install semgrep
# CodeQL CLI: descargar de github.com/github/codeql-cli-binaries
Entorno propio.
Modela la superficie de ataque de un proyecto C pequeño: lista funciones que reciben datos externos (argv, ficheros, red) y márcalas como fuentes.
Ejecuta SAST y compara resultados:
bash
cppcheck --enable=all --inconclusive src/ 2> cppcheck.txt
scan-build make # clang static analyzer
semgrep --config p/c src/
Sigue una advertencia real (p. ej. memcpy con tamaño controlado) desde la fuente del dato hasta el
sumidero, confirmando si es explotable o falso positivo.
Escribe una consulta CodeQL sencilla que localice llamadas a strcpy con origen no acotado (o parte
de una query de ejemplo del repo de CodeQL) y ejecútala sobre la base del proyecto.
Prioriza los hallazgos en una tabla: bug, fuente, sumidero, explotabilidad (alta/media/baja), impacto.
Redacta un mini-reporte de una vulnerabilidad como si fueras a enviarlo al mantenedor: descripción, PoC mínima, versiones afectadas, mitigación y una propuesta de plazo de divulgación.
sprintf sin límite y explica el riesgo.gets(.Audita un proyecto C pequeño (propio o open source con permiso), identifica una vulnerabilidad real, demuéstrala con una PoC mínima y redacta el reporte de divulgación.
Criterio de aceptación: entregas la ubicación exacta del bug (archivo:línea), una PoC que lo dispara y un reporte con impacto, versiones y mitigación propuesta.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| SAST ahoga en falsos positivos | Filtra por severidad y valida con taint manual |
| No encuentras nada | No modelaste bien la superficie de ataque; empieza por los parsers |
| CodeQL no compila la base | La query necesita una DB creada con codeql database create |
| Reportas sin PoC | Debilita el reporte; incluye reproducción mínima |
| Publicas un 0-day de terceros | Viola la ética; sigue disclosure coordinada |
❓ ¿SAST reemplaza al fuzzing? No: SAST ve patrones sin ejecutar; fuzzing ejecuta y halla bugs de runtime. Son complementarios.
❓ ¿Cómo reporto responsablemente? Contacta al vendor/security.txt, aporta PoC, acuerda plazo (p. ej. 90 días) y coordina la publicación.
❓ ¿Todo hallazgo es una CVE? No: muchos son de baja explotabilidad o requieren condiciones irreales; prioriza.
Clase 136 — Fuzzing con AFL++ y libFuzzer