Quizá alguna vez hayas escuchado de los programas denominados Bug Bounty. Bug Bounty hace alusión al dinero destinado por las organizaciones para la corrección de vulnerabilidades de sus activos con el fin de que los hackers estén motivados a realizar una divulgación responsable a través de plataformas que actúan como intermediarias como Bug Crowd, HackerOne, CrowdCurity, BountyFactory, VulnScope, entre otras.
¿Qué necesitas?
No necesitas ningún requisito en la mayoría de plataformas, exceptuando algunas, como VulnScope que sí te piden que firmes un contrato de confidencialidad pero ningún requerimiento alto. Entonces, en resumen, lo único que hace falta es registrarse en alguna de las plataformas antes mencionadas, unirte a un programa(en algunas programas) y comenzar a realizar resportes.
He creado un diagrama en el cual se podrá observar de mejor manera el proceso de Bug Bounty, tanto desde la perspectiva de las empresas como desde los hunters.
El proceso, a groso modo, es el siguiente:
- La compañía decide crear un programa de Bug Bounty.
- La compañía elige la plataforma en donde desea publicarlo[HackerOne, BugCrowd, BountyFactory].
- Esta, realiza las respectivas reglas y políticas para cuando el programa se lance al público.
- Una vez lanzado al público, los hunters(cazadores de recompensas) podrán comenzar a testear las aplicaciones.
- Si un hunter encuentra un fallo, publica el reporte(inicialmente de manera privada) en la plataforma al respectivo programa.
- La compañía, independientemente de como valide las vulnerabilidades, acepta o rechaza de que es una vulnerabilidad.
- El hunter es remunerado de alguna forma.
- La plataforma le concede los respectivos puntos al hunter.
- El reporte se cierra y dependiendo de las políticas de la empresa, se hace público o privado.
Comprendiendo el concepto, creo que es necesario mencionar el por qué no todo es tan sencillo como parece.
Cuando vas en busca de un XSS, una SQLi o un CSRF de una de las aplicaciones que está in-scope(en el alcance) del programa, usualmente, ya ha sido reportada con anticipación. Sin embargo, las hay, pero hay que profundizar más en el aplicativo, debido a que en algún momento, una persona testeó en lo que tú estás testeando ahora: buscador, login, formulario de registro, configuraciones de perfil, entre otras. De hecho, muchos de los vectores de ataque que se han encontrado recientemente en RockstarGames(un XSS en el D0M) debió usar parte de mathml para demostrar que era válido el reporte.
Volviendo a lo que nos compete, daré algunos consejos que de seguro te servirán si deseas entrar al rubro.
Código fuente
Sí, así como lo ves. Sé que muchos que se dedican a la seguridad informática, no conocen o no manejan bien la programación y ahí existe un grave problema. ¿Por qué?. En los programas, muchas veces piden que también se testeen aplicaciones en Android/iOS o incluso en los aplicativos que deseen testear, proveen el código en GitHub. Teniendo acceso al código, se puede hacer mucho: ver cómo se envían/reciben las entradas de usuario desde el cliente al servidor, revisar la longitud con la que se recibe, comprobar si existe algún acceso en el código comentado y otra cantidad de variables que se consideran importantes cuando se está haciendo una auditoría de código. De hecho, muchas veces lo que se suele hacer es montar la aplicación en local, que a pesar de un poco más de trabajo, es mucho mejor. Se hace esto, con el fin de evitar los firewalls, que a pesar de que tiene solución(hacerles bypass), molesta.
Metodología
En primera medida, debes revisar y apuntar los dominios/subdominios que estén en el alcance del programa. Luego, realizar un reconocimiento exhaustivo de estos. Debes usar todo lo que consideres necesario, ya que esto es vital para luego proceder a realizar las pruebas de concepto. Podrás buscar también los subdominios en caso de que ellos lo deseen(*.example.com). Recuerda que para esto, también puedes usar los dorks que son muy útiles. Luego, comienza por cada uno de los objetivos, verificando si tiene un CMS, plugins, servicios que están arriba, entre otros. Haz pruebas de fuzzing, pues son muy útiles para revelar errores y exponer vulnerabilidades. Procede a intentar impactar de una forma más profunda en la vulnerabilidad(¡LEE BIEN LAS POLÍTICAS DEL PROGRAMA!).
Prueba de concepto
Si en los pasos anteriores, encontraste una vulnerabilidad, deberás comprobarla con una pequeña prueba de concepto. Este aspecto es uno de los más fundamentales que pueden existir a la hora de realizar reportes, ya que si una PoC no la pueden replicar, no será considerado como bug. Mis recomendaciones son: intenta varios vectores de ataque, luego captura cómo reproduciste tú la vulnerabilidad y enumeralo por pasos en el reporte.
Deberás adjuntar también capturas de pantalla, para que quede en evidencia de que sí existe tal vulnerabilidad y así evitar un posible cierre de reporte.
Reporte de vulnerabilidad
Aparte de la PoC, deberás saber comunicar de una manera apropiada lo que encontraste. Que los que vayan a recibir el reporte sean técnicos, no quiere decir que vayan a entender lo que les estás comunicando. Por ende, debes hacer un reporte claro y contundente que posea: detalles(de qué trata el reporte), severidad(calificación de la brecha), impacto(cuánto riesgo existe al tener esta brecha), explotabilidad(cómo podría afectar a...) y remediación(posibles correciones que podría tomar la empresa).
Posiblemente, tus primeros reportes sean duplicados, pero no debes desmotivarte, pues eso quiere decir que debes conocer un poco más de la aplicación que estás testeando. Si en algún caso, el reporte es inválido, deberás profundizar más en los conceptos que crees que te hagan falta(sobretodo, técnicos).
A continuación, les dejaré unos plugins que les podrían servir, tanto para Firefox como para Chrome:
Addons Chrome.
Addons Firefox.
A continuación, un vídeo en el cual también doy otros consejos
No hay comentarios:
Publicar un comentario