
Artículos en Osint relacionados con este post:
Bug Bounty
El ecosistema de la seguridad ofensiva ha evolucionado de auditorías cerradas hacia un modelo de colaboración abierta conocido como Bug Bounty. En este entorno, la capacidad de un investigador para identificar activos vulnerables no depende únicamente de su conocimiento de exploits, sino de su metodología de reconocimiento y su habilidad para encadenar fallos técnicos. La diferencia entre un reporte exitoso y un duplicado reside en la profundidad del análisis y la precisión en el uso de herramientas de automatización.
El reconocimiento es el pilar fundamental de cualquier investigación. Antes de intentar una inyección de código, es imperativo conocer la superficie de ataque completa. Muchas organizaciones poseen cientos de subdominios, algunos de los cuales pertenecen a entornos de desarrollo o pruebas que carecen de las medidas de seguridad del dominio principal.
La enumeración efectiva se divide en dos vertientes: el scraping pasivo y el bruteforce activo. El scraping utiliza fuentes de terceros como motores de búsqueda, archivos históricos de la web y registros de certificados SSL (Certificate Transparency logs) para identificar nombres de host existentes sin interactuar directamente con el servidor del objetivo.
Un investigador puede utilizar herramientas para consultar registros de certificados. Si una empresa ha generado un certificado para dev-api.objetivo.com, este quedará registrado públicamente. Al identificar este subdominio, el investigador puede encontrar una API que no requiere autenticación multifactor, a diferencia de la API de producción, abriendo una puerta de entrada crítica que de otro modo hubiera pasado desapercibida.
Una vez obtenida una lista masiva de subdominios, el siguiente desafío es la clasificación. No todos los subdominios alojan servicios web interesantes. El uso de herramientas de identificación visual permite al investigador tomar capturas de pantalla automáticas de cientos de sitios para identificar rápidamente paneles de administración, servicios desactualizados o páginas de error que revelen información del sistema.
Simultáneamente, el escaneo de puertos permite identificar servicios que no se ejecutan en los puertos estándar 80 o 443. La identificación de puertos como el 8080 (servidores de aplicaciones), 3306 (bases de datos expuestas) o 22 (SSH) es vital para determinar el vector de ataque más prometedor.
Más allá de los fallos técnicos tradicionales, las vulnerabilidades de lógica de negocios son altamente valoradas en los programas de recompensas. Estas ocurren cuando una aplicación permite realizar acciones para las que el usuario no debería tener permiso debido a un diseño defectuoso en el flujo de trabajo.
Un ejemplo común es el IDOR (Insecure Direct Object Reference). Esto sucede cuando la aplicación utiliza un identificador para acceder a recursos y no verifica si el usuario tiene permiso para ver ese identificador específico.
Supongamos que al editar tu propio perfil, la URL es https://api.objetivo.com/v1/user/1234/settings. Un investigador probará cambiar el número 1234 por 1235. Si la respuesta del servidor devuelve los datos privados de otro usuario, se ha confirmado una vulnerabilidad de IDOR de alta criticidad. La automatización mediante intrusores que recorren rangos numéricos permite escalar este hallazgo rápidamente.
La vulnerabilidad XXE ocurre cuando una aplicación procesa entradas XML que contienen referencias a entidades externas. Esto puede permitir a un atacante leer archivos locales del servidor, realizar peticiones internas (SSRF) o, en casos extremos, ejecutar código de forma remota.
Si una aplicación permite subir archivos SVG (que son basados en XML) o procesa documentos de oficina, un investigador puede insertar un código malicioso en la definición del tipo de documento (DOCTYPE). Al enviar un payload que define una entidad vinculada al archivo /etc/passwd en un sistema Linux, el servidor podría renderizar o devolver el contenido de dicho archivo en la respuesta, exponiendo a todos los usuarios del sistema.
Los JWT se utilizan ampliamente para la autenticación y gestión de sesiones. Sin embargo, si no se implementan correctamente, pueden ser manipulados. Los ataques comunes incluyen cambiar el algoritmo de firma a “none”, lo que a veces engaña al servidor para que acepte un token no firmado, o realizar ataques de fuerza bruta sobre la clave secreta si esta es débil.
Un investigador intercepta su propio token y observa que en el cuerpo del JSON aparece admin: false. Utilizando herramientas de depuración de JWT, cambia el valor a admin: true. Si el servidor no verifica correctamente la integridad de la firma con una clave secreta robusta, el investigador podría obtener acceso a funciones administrativas con tan solo modificar un archivo de texto en su navegador.
A pesar de ser una de las vulnerabilidades más antiguas, la inyección SQL sigue presente. El enfoque moderno en Bug Bounty se centra en SQLi ciegas (blind) o basadas en tiempo, donde el servidor no muestra errores directamente, pero su tiempo de respuesta cambia según la veracidad de la consulta inyectada.
La extracción de información comienza por determinar el número de columnas y luego utilizar operadores de unión para volcar nombres de tablas y columnas de la base de datos de configuración del sistema (como information_schema).
SSRF es una vulnerabilidad crítica donde un atacante induce al servidor a realizar peticiones HTTP hacia destinos arbitrarios. Esto se utiliza frecuentemente para atacar la infraestructura interna de la empresa que no es accesible desde internet, como servicios de metadatos en instancias de la nube (AWS, Google Cloud o Azure).
En una instancia de AWS, un investigador podría intentar que una función de la web que carga imágenes desde una URL externa apunte a http://169.254.169.254/latest/meta-data/iam/security-credentials/. Si el servidor es vulnerable, devolverá las credenciales temporales de la instancia, permitiendo al investigador tomar control de otros recursos en la nube de la empresa.
El XSS sigue siendo la vulnerabilidad más reportada. La clave para encontrar XSS en programas competitivos es buscar “sinks” o puntos de salida en el DOM donde el contenido introducido por el usuario no se filtra adecuadamente. Esto no se limita a alertas de JavaScript, sino que puede escalar al robo de cookies de sesión o a la redirección de usuarios hacia sitios de phishing.
Un aspecto a menudo descuidado es la configuración de las cabeceras HTTP. La falta de cabeceras de seguridad como Content-Security-Policy (CSP) o el uso incorrecto de Cross-Origin Resource Sharing (CORS) puede permitir ataques de intercambio de datos entre sitios no autorizados.
La investigación de cabeceras como X-Forwarded-For también puede revelar vulnerabilidades donde el servidor confía ciegamente en la IP proporcionada por el cliente para omitir restricciones de acceso geográfico o de red interna.
El éxito en Bug Bounty no termina con la explotación. Un reporte de alta calidad debe incluir:
Resumen del impacto: Explicar claramente qué riesgo corre la empresa.
Pasos para reproducir: Una guía detallada y sencilla para que el equipo de seguridad pueda validar el fallo.
Prueba de concepto (PoC): Evidencia visual o técnica del hallazgo.
Recomendaciones de mitigación: Sugerir cómo corregir el problema de raíz.
La caza de errores es una carrera de resistencia. Requiere una combinación de automatización para las tareas repetitivas y un análisis manual profundo para las vulnerabilidades lógicas. Al dominar herramientas de enumeración, técnicas de manipulación de tokens y comprensión de protocolos web, un investigador puede transformar una superficie de ataque aparentemente segura en un mapa detallado de oportunidades de mejora para la seguridad organizacional. La clave reside en nunca dejar de explorar los rincones oscuros de la infraestructura y entender que, en seguridad, el eslabón más débil suele ser aquel que se consideró demasiado pequeño para ser protegido.