Bug Bounty Hacia instituciones públicas

Author: Félix Sánchez

Bug Bounty en Instituciones Públicas: Vulnerabilidades Reales y VDPs

Charla técnica en un meetup de ciberseguridad, contexto de comunidad Hack the Box Salamanca

Idea principal

Un consultor de ciberseguridad que compite en CTFs habla de su experiencia haciendo bug bounty en instituciones públicas españolas, mostrando vulnerabilidades reales que encontró y defendiendo los programas VDP (Vulnerability Disclosure Programs) como algo que las administraciones deberían adoptar ya.

Conceptos clave

• Bug Bounty = pagar o reconocer a quien encuentre vulnerabilidades en tus sistemas, a diferencia de un pentesting clásico con auditores fijos
• Tres tipos de programas: públicos (cualquiera puede participar), privados (por invitación) y VDP (sin pago, solo reconocimiento)
• Las instituciones públicas tiran más por VDPs porque no tienen pasta para pagar, pero al menos tienen un canal de reporte
• Security.txt: estándar muy sencillo, un archivo en una ruta conocida con un email y clave PGP para reportar responsablemente
  • Casos de éxito en España: Ayuntamiento de Madrid, CCNAT, Educamadrid
• POCs reales que encontró:
  • LFI (Local File Inclusion) en whitebox: leyó credenciales de base de datos en texto claro gracias a un readfile() sin sanitizar
  • SQL Injection basada en tiempo: lo encontró en un parámetro de imagen, usando SLEEP() en el nombre de tabla con un truco de MySQL
  • Dos XSS Reflected bypasseando WAF: uno usando onMouseOver con estilo invisible para que el ratón siempre pase encima
  • CRLF Injection: inyectó saltos de línea en cabeceras HTTP, llegó a convertirlo en XSS metiendo el payload en el body de la respuesta
• CVE-2025-41358: IDOR en CronosWeb (CMS usado en ayuntamientos de toda España), puntuación 8.3 en CVSS porque exponía datos de menores con DNI, cuentas bancarias y teléfonos

Desarrollo/contexto

Lo más interesante de la charla es que no habla de ataques en entornos controlados sino de cosas que encontró de rebote, sin ir buscándolas activamente. Eso refuerza el argumento central: las instituciones públicas tienen una superficie de ataque enorme porque todos los ciudadanos usan sus sistemas, y cualquiera con un mínimo de conocimiento puede toparse con algo.

El CVE es el ejemplo que más impacta. Un IDOR normalmente no puntúa tan alto, pero aquí el contexto lo cambia todo: no era solo acceder a un documento ajeno, sino a expedientes con datos sensibles de menores en múltiples ayuntamientos a la vez, porque el fallo estaba en el software base, no en una instalación concreta. Cuatro meses de gestión coordinada antes de publicarlo.

Términos técnicos

• LFI: Local File Inclusion, leer archivos del servidor a través de un parámetro sin sanitizar
• IDOR: Insecure Direct Object Reference, acceder a recursos de otros usuarios cambiando un identificador
• WAF: Web Application Firewall, proxy que filtra peticiones maliciosas antes de que lleguen al servidor
• CRLF Injection: inyectar saltos de línea (%0d%0a) en cabeceras HTTP para manipular la respuesta
• VDP: Vulnerability Disclosure Program, canal oficial para reportar vulnerabilidades responsablemente
• openbasedir: variable de PHP que restringe qué rutas del sistema puede leer el script

Conclusiones

Me llevo que el Security.txt debería ser obligatorio en cualquier web pública. Es trivial de implementar y marca la diferencia entre que alguien reporte algo o lo deje estar por miedo a represalias. También que las instituciones no necesitan un programa de bug bounty millonario para mejorar su seguridad, con un VDP decente ya están dando un paso grande. Y lo del IDOR con datos de menores es un recordatorio de que los fallos más sencillos a veces son los más graves.

Para investigar más

• Estándar Security.txt (RFC 9116)
• Escala CVSS y cómo se calculan las puntuaciones
• Diferencias entre include() y readfile() en PHP y por qué importan en LFI