Historia de una recompensa por $.$$$, Metodología aplicada y bypass de solución WAF
Historia
Hola, mi nombre es Danny Ramírez. Soy investigador de seguridad Ecuatoriano; en mi tiempo libre me dedico a las recompensas por errores, mi plataforma favorita es HackerOne. En este escrito voy a compartir cómo encontré una vulnerabilidad tipo SSRF en un programa privado: les explico mi metodología, que se centra en el reconocimiento y en el hackeo manual. También compartiré una técnica que me permitió evadir el WAF que protegía esta aplicación web, que por cierto, era muy estricto; el WAF me bloqueaba incluso etiquetas HTML inofensivas como <h1>. Así que, manos a la obra.
Metodologia
Seré muy breve en esta parte. En el reconocimiento utilizo herramientas orientadas al descubrimiento de activos y la recolección de información, muchas de ellas creadas por la comunidad. En ocasiones empleo herramientas para tareas específicas: por ejemplo, para recolectar endpoints podría usar waymore; si solo necesito extraer subdominios, usaría subfinder. Cuando no dispongo de mucho tiempo, ejecuto marcos de reconocimiento ya creados que integran múltiples herramientas y flujos útiles para esta actividad.
Herramientas de recon (recomendadas):
- httpx — comprobación rápida de hosts y toma de cabeceras/estatus.
- Wayback Machine / waybackpack — historial de URLs y contenido eliminado.
- waymore — recolección masiva de endpoints a partir de múltiples fuentes.
- amass — enumeración y mapeo de subdominios a gran escala.
- subfinder / assetfinder / sublist3r — descubrimiento rápido de subdominios.
- crt.sh / CertSpotter — búsquedas en certificados para hallar subdominios y SANs.
- Shodan / Censys — búsqueda de hosts expuestos y servicios indexados.
- nmap / masscan — escaneo de puertos y detección de servicios.
- gobuster / ffuf / dirsearch — fuerza/brute-forcing de directorios y ficheros.
- gau / waybackurls — recopilación de URLs históricas y endpoints potenciales.
- dnsenum / dnsrecon — recolección de información DNS y registros públicos.
Marcos de reconocimiento (mis favoritos): Un saludo a sus hackers geniales que las crearon.
- Reconftw
- Osmedeus, en su versión PRO.
Elegir mi objetivo
Como pueden ver, la eficiencia del programa es del 100% según las estadísticas de HackerOne. Esto es algo que siempre tengo en cuenta al momento de hackear, ya que un programa con mala eficiencia en sus respuestas, recompensas, etc., no nos conviene. Elegí este programa, que incluso tenía un gran alcance para hackear.
Wildcard
Este objetivo tenía un wildcard, es decir, todos los subdominios estaban dentro del alcance. Por ejemplo: para company.com, *.company.com. Podemos buscar vulnerabilidades en cualquiera de esos subdominios.
Reconocimiento
Como mencione anteriormente uso en muchas ocasiones osmedeus, ejecute el siguiente comando para recopilar toda la informacion posible de mi activo.
|
|
El comando anterior permite ejecutar el siguiente flujo de reconocimiento totalmente automático. Como dijo mi profesora: «si algo ya existe, no inventes el agua tibia». Si no hubiera usado este flujo de trabajo, seguro me tocaría crear uno propio — quizás unir todas las herramientas mediante un script de Bash — , pero es un trabajo, y en ocasiones mi tiempo es limitado.
Resultados obtenido
Manual Hacking
En la carpeta subdomain se encuentra el listado validado de subdominios. Durante la revisión manual identifiqué varios subdominios relevantes por ejemplo dev.company.com y staging.company.com. Uno de ellos llamó especialmente mi atención: core.company.com, que está implementado con tecnología PHP. A partir de este hallazgo procedí a priorizar core.company.com para pruebas más profundas, puesto que su tecnología y exposición lo hacen un candidato relevante para evaluación de seguridad.
Para resumir el proceso, identifiqué que este aplicativo, utilizado por el programa, pertenecía a un proveedor externo — llamémoslo. Este contaba con un panel de autenticación, pero no permitía realizar pruebas sobre el software, lo cual resultaba completamente lógico considerando que se trata de un entorno productivo o restringido.
Mediante OSINT identifiqué que la empresa desarrolladora del software, que además comercializa la solución como SaaS, mantiene un entorno de pruebas accesible en trial.software.com. Ese entorno permite evaluar funcionalidades completas del producto, por lo que resulta útil para reproducir y analizar comportamientos que en el programa de recompensas no eran accesibles. Me registre y comenze a probar cada funcionalidad.
Luego de probar todas las funcionalidades — un proceso que me llevó aproximadamente 3 horas — descubrí que la mayoría de las peticiones a la API requieren una cookie de sesión (la cual, por supuesto, estaba presente en el entorno de pruebas). Al identificar la vulnerabilidad SSRF que encontré, decidí probar funciones que generan y exportan contenido (PDFs, imágenes, etc.), y fue entonces cuando identifiqué dos aspectos relevantes: la petición al microservicio no requería autenticación y la funcionalidad permitía exportar PDFs con información estadística.
Los SSRF (Server-Side Request Forgery) se caracterizan por aprovechar funcionalidades legítimas del aplicativo, generalmente aquellas que permiten interactuar con URLs externas o servicios internos. Al abusar de estas funciones, como las de exportación de documentos o generación de contenido remoto, un atacante puede lograr que el servidor realice peticiones hacia la red interna y potencialmente obtener información sensible.
En la petición POST enviada, se evidenció que no era necesaria la cookie de sesión para completar la solicitud. Además, se observó que el parámetro html se enviaba en el cuerpo de la petición; como su nombre lo indica, este campo permite generar contenido HTML, el cual posteriormente es renderizado en el archivo PDF generado por el sistema.
PDF exportado
Confirmación de Vulnerabilidad en el VENDOR
Como podemos observar, el PDF exportado muestra una carita :(. En ese momento me emocioné, porque aunque estamos utilizando un iframe, el contenido nunca llegará a cargarse desde Google debido al encabezado de seguridad que este servicio implementa, entonces lo que hice de inmediato es cargar mediante la etiqueta iframe, es /etc/host y funciono de maravilla, pero esto es en el vedor.
Explotando vulnerabilidad en el programa de recompenzas
Vamos al programa, mismo software, pero con una diferencia, aqui existe una solución WAF potente que bloquea incluso hasta las minima etiqueta html.
Primer Intento
Segundo intento
Por algún motivo, el WAF permitía que la petición pasara únicamente cuando se insertaba un espacio, algo que según la RFC no está permitido ni es válido. Como consecuencia, el PDF generado resultaba inválido, ya que la solicitud no cumplía con el formato correcto definido por el estándar.
Tercer intento
Incluso probe alguna técnicas básicas, como encerrar en un div al h1, pero igual no funciono.
Cuarto Intento
Utilizando una caja de texto <div> y agregando estilos directamente en la misma etiqueta, logré que el sistema generara correctamente el PDF exportado, mostrando el texto “hola” dentro del documento.
Resultado PDF exportado
Quinto intento , bloqueo de etiqueta iframe
Confirmación de SSRF, intento de callback mediante la etiqueta a con el atributo ahref
Callback confirmación
Identificación de BYPASS etiqueta embed
Lectura de archivos hostname en Linux
Al tratarse de un SSRF basado en el contexto de la generación de archivos PDF, resulta complicado interactuar directamente con servicios internos. Sin embargo, fue posible realizar la lectura de múltiples archivos del sistema, lo cual representa una limitación del entorno. El servicio no estaba alojado en la nube; de haberlo estado, habría sido posible acceder a la metadata de AWS u otro proveedor correspondiente.
Para aumentar el impacto del hallazgo, se revisaron las cookies de sesión, ya que, si aún no hubieran expirado, podrían haberse utilizado para realizar nuevas peticiones al servicio. Dado que ya se conocían los endpoints utilizados por la aplicación, el impacto potencial habría sido considerablemente mayor.
Algunas captura de lectura de archivos locales
Impacto o Riesgo
Si bien es cierto que la vulnerabilidad no afecta la integridad ni la disponibilidad de la información, este fue el motivo por el cual se determinó una criticidad moderada, de acuerdo con la puntuación obtenida en el CVSS Score.
Recompensa
Bug Bounty Bug Bounty Writeup Infosec Pentesting