Código Objetivo (Java) y Cobertura
💡 Haz clic en cualquier bloque (B1-B4) para ver detalles técnicos de la fase.
Experimenta en tiempo real cómo funciona un fuzzer guiado por cobertura sobre código Java. Controla CMPLOG, ajusta estrategias y observa cómo los sanitizers revelan corrupciones que de otro modo serían invisibles.
Es una herramienta de pruebas de caja gris automatizada que inyecta entradas mutadas al programa objetivo. Al registrar las rutas de código alcanzadas (cobertura), decide si una mutación es útil: si descubre una nueva rama o bloque de ejecución, esa entrada se guarda como semilla en el Corpus para seguir mutando a partir de ella. Esto permite resolver ramas complejas automáticamente sin conocer de antemano el código fuente.
💡 Haz clic en cualquier bloque (B1-B4) para ver detalles técnicos de la fase.
Se configuran herramientas como CIFuzz o AFL para que ejecuten automáticamente en cada commit un corpus de prueba previamente minimizado. Esto asegura de forma instantánea que ningún parche o refactorización reintroduzca una vulnerabilidad conocida del pasado.
El fuzzer envía ráfagas de paquetes malformados con longitudes incorrectas, campos de opción corruptos o firmas inválidas a los sockets de un servicio activo. Se utiliza para descartar desbordamientos lógicos y fallos de denegación de servicio (DoS) en pasarelas críticas antes del despliegue.
Se fuzzear motores que procesan archivos complejos (como PDF, JSON, XML o imágenes) mutando bytes estructurales. Su objetivo es detectar punteros nulos, divisiones por cero y corrupción de heap antes de que un archivo malicioso pueda evadir la seguridad sandbox.
¿Por qué la cobertura guía la búsqueda? El fuzzer registra qué bloques de código se ejecutan con cada entrada. Si una mutación descubre un bloque nuevo (cobertura incrementada), guarda esa entrada como una nueva "semilla" para mutarla en el futuro. Esto le permite resolver ramas complejas.
El papel de CMPLOG y los Sanitizers: CMPLOG analiza las
operaciones de comparación de datos de manera dinámica y extrae los valores que fallan en los condicionales
(como 0xCAFEBABE), añadiéndolos directamente al corpus de mutación para abrir ramas nuevas en
segundos. Los Sanitizers son fundamentales porque interceptan accesos ilegales a memoria
(desbordamientos lógicos, fugas) en el momento exacto en que ocurren. Si desactivas los sanitizers, la JVM o
el sistema operativo podrían continuar la ejecución con datos corruptos y el bug ocurriría silenciosamente
(sin crash visible en el fuzzer), haciendo imposible su detección automática.
Entrena tu criterio de selección. Arrastra los diferentes tipos de fallas de seguridad a la herramienta o técnica idónea para detectarla. Las técnicas no compiten: se complementan.
Analiza cada uno de los siguientes casos y arrástralos a la zona de la herramienta técnica adecuada para su detección.
userId=123 a userId=124 en la URL HTTP, el
servidor devuelve datos del usuario 124 sin estar logueado.
"SELECT * FROM users WHERE name = '" + name + "'".
Ninguna herramienta de seguridad detecta todo. La defensa en profundidad requiere entender las fortalezas y puntos ciegos de cada técnica:
El fuzzer ha generado una pila de ejecuciones fallidas. Tu trabajo es realizar el triage: agrupar por stack hash para deduplicar, minimizar el caso a su mínima expresión (estilo afl-tmin) y clasificar el tipo de fallo de acuerdo con el sanitizer.
Encontrar un crash con fuzzing es solo la mitad del trabajo. Para dar valor de negocio y cumplir con marcos de seguridad como el SSDF (Secure Software Development Framework - Grupo Respond), debes ser capaz de responder a un incidente de manera organizada:
==10245==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300001fc40
READ of size 96 at 0x60300001fc40 thread T0
#0 0x4012ab in parsePacket PacketParser.java:12
#1 0x4018bc in main PacketFuzzerRunner.java:45
#2 0x7f4b82 in libc_start_main.java:120
Payload raw content (Hex):
43 41 46 45 42 41 42 45 03 E8 41 41 41 41 41 41 41... [1024 bytes]
Sigue esta guía interactiva paso a paso para depurar y resolver el Crash #001 en el simulador:
El fuzzer saca cientos de crashes, pero la mayoría son redundantes. Haz clic en "Deduplicar por
Stack Hash" en la bandeja de entrada. Notarás que el Crash #003 y el Crash #005 se atenúan
porque comparten el hash de stack trace (c1b52a) con el Crash #001, indicando que son el
mismo bug. ¡Esto te ahorra horas de análisis!
El fuzzer mutó bytes de relleno aleatorios (como letras 'A') que ensucian el caso de prueba. Arrastra el
slider de minimización hasta la Zona Verde (entre 12 y 32 bytes). Verás que el payload se
limpia pero el estado permanece en "Crash Activo". Si bajas a menos de 12 bytes, el caso fallará porque
mutilas la firma CAFEBABE.
Lee el log del sanitizer. Se detalla un error heap-buffer-overflow en la copia. Calcula la
gravedad CVSS (Red, Baja, Alta, Alta -> 9.8 Crítica), asocia el CWE-125 (Out-of-bounds
Read) y selecciona la propuesta de parche correcta en Java. Luego, haz clic en "Añadir caso
minimizado al Corpus" para integrarlo en tu suite de regresión.
Dirige tu empresa de desarrollo de software ante un incidente crítico. Enfrenta la presión comercial, el reloj legal del Cyber Resilience Act (CRA) de la Unión Europea y el dilema real del bug de 20 años de SQLite. ¿Qué decisiones tomarás?
Selecciona el contexto bajo el cual quieres operar la respuesta a incidentes de tu organización.