1 jun 2015

Bug Bounty Programs: cómo ganar dinero con vulnerabilidades

Aprendizaje, recompensas y reconocimiento

En este post les comentaré mi experiencia como Ethical Hacker, participando en distintos Bug Bounty Programs.

Comencé buscando fallas de seguridad sobre aplicaciones Web de compañías que sabía, no pagarían por las vulnerabilidades encontradas. Pero mi primer objetivo, era obtener respuestas a mis reportes por parte de las empresas a las cuales informaba sobre las fallas de seguridad que iba encontrando, aunque no pagaran por mi trabajo y el tiempo invertido.

En base al interés que demostraban por ciertas vulnerabilidades, siendo que algunas no eran interesantes para la mayoría como por ejemplo, un Null Byte Injection, que nos puede llegar a mostrar que versiones de servidores web y sistemas operativos están siendo utilizados, apuntaba hacia aquellas vulnerabilidades por las cuales había mayor interés.
Hay una frase que dice: "No aprendas a hackear, hackea para aprender."
Y claro está que mi tiempo estaba siendo bien invertido, era una muy buena e interesante oportunidad, ya que me permitía entrenarme, aprender y perfeccionarme buscando vulnerar sistemas de forma legal y teóricamente, muy seguros.

Luego de aparecer mi nombre publicado en los Hall of Fame de Sony, eBay, Zynga y recibir agradecimientos por parte de Amazon, probé que efectivanente iba bien encaminado en mi trabajo.
Pero más allá de todo reconocimiento que también es lógicamente bienvenido, lo más valioso es en definitiva, el aprendizaje y el conocimiento que se va adquiriendo en el camino.

Llegué al punto en el cual, decidí dejar de hacer hacking ético como quien dice "por amor al arte" y realizarlo ya pensando también en una recompensa económica.

Pero, ¿quiénes pagan por estas vulnerabilidades?

Empresas de gran envergadura como Google y Facebook entre otras, tienen programas de recompensas para quienes reporten fallas de seguridad en sus sistemas, pidiendo obviamente como en todo programa de este tipo, no hacerlas públicas hasta que sean solucionadas y nos hayan autorizado a publicar lo encontrado.

Pero como no todo lo que brilla es oro, me ha pasado en varias oportunidades que luego de reportar una vulnerabilidad, es cerrada como no válida y días más tarde, la misma es corregida. En otras ocasiones, han cerrado reportes informando que el bug existe, pero que no se estaba pagando en ese momento por el mismo. Puede suceder también que se cierre un reporte como duplicado, indicando que ya había sido detectado, algo que no tenemos forma de comprobar.

Fué entonces cuando encontré varias empresas que a través de sitios como Bugcrowd y Hackerone, permiten reportar las fallas detectadas y ser recompensados. Y también me han cerrado reportes como duplicados, pero se me indicó el número de caso en el cual ya se había informado la existencia de la misma falla de seguridad.

En mi caso personal, me ha sido de gran ayuda en particular Bugcrowd, que además de pagar por las vulnerabilidades validadas, siempre y cuando sea el primero en reportarlas, otorga también Kudos y cuantos más obtengamos, más alta es la posibilidad de ser convocados para programas privados. Es decir que invitan a participar, solo a un grupo selecto y reducido de investigadores en un nuevo programa de recompensas, aumentando de esta forma, las posibilidades de ser el primero en reportar una vulnerabilidad y ser premiado por ello. Los reportes de seguridad con los que más éxito he tenido son Clickjacking y XSS.

Todo reporte sobre fallas de seguridad, debe ir acompañado de lo que se denomina "Proof of Concept" ó "Prueba de Concepto", en donde se explica de qué forma fué encontrada la vulnerabilidad y cuáles son los peligros si es explotada por un atacante. Las compañías no permiten utilizar herramientas automatizadas para la detección de bugs, premiando aquellas vulnerabilidades que demuestren haber hecho uso del conocimiento e imaginación para ser encontradas.

El Clickjacking es quizás, una vulnerabilidad de bajo impacto, pero puede ser detectada muy rápidamente. Se puede saber si una parte de un sitio web es vulnerable a este tipo de ataques en solo unos instantes. Generalmente existe una vulnerabilidad de Clickjacking, cuando se permite embeber partes dinámicas del sitio en los cuales un usuario ingresa datos sensibles, dentro de un iframe.

Por ejemplo, suponiendo que la página http://vulnerableaclickjacking.com nos solicita ingresar usuario y contraseña, podemos crear un archivo index.html con el siguiente contenido en nuestro servidor web para verificar si es ó no vulnerable a Clickjacking:
[html] 
[head]
[title]Clickjacking Test[/title]
[/head] 
[body]
[iframe height="750" src="http://vulnerableaclickjacking.com" width="1250"][/iframe]
[/body]
[/html]
Al ingresar desde un navegador a la IP de nuestro servidor web en el cual fué creado el archivo anteriormente indicado, el sitio http://vulnerableaclickjacking.com no debería poder visualizarse, lo cual indica que no está permitiendo ser embebido y superpuesto sobre otro falso sitio. En ese caso, no es vulnerable a un ataque de Clickjacking.

Si desean probar vulnerabilidades de Cross-site Scripting, conocidas como XSS, Google ha desarrollado un juego pensado para que los desarrolladores tomen conciencia de lo peligroso que puede ser este tipo de fallas de seguridad en una aplicación web. Dejo el enlace: https://xss-game.appspot.com

Un XSS puede ser directo e indirecto, a los cuales se los conoce también con el nombre de persistentes y reflejados respectivamente. El XSS persistente es el más peligroso, ya que el código queda almacenado en el sitio y se ejecuta cuando la aplicación es abierta.

El XSS reflejado es el más común de todos, se modifican los datos que pasa el cliente, provocando que el código enviado a través de la URL sea ejecutado en el servidor web.

Aquí dejo algunos Payloads para prueba de XSS:
[script]alert('XSS');[/script]
"][img src=x onerror=alert(document.cookie);]
[script]var pass=prompt('Sesion finalizada. Ingrese su contraseña.','');password;
[/script]
La paciencia es una virtud, algo que debemos tener para participar en uno o varios Bounty Programs. Puede ocurrir que en algunos casos, la respuesta a un reporte sobre un bug detectado, tenga una demora de veinte días o más en algunos casos. Pero tarde o temprano el esfuerzo será recompensado, sobre todo con aprendizaje.

Las vulnerabilidades, fortalecen el conocimiento de quien las encuentra y demuestran, que nada es cien por ciento seguro y que incluso los gigantes, tienen también sus puntos débiles.

Javier Romero para Segu-Info
Twitter: @xavinux

Suscríbete a nuestro Boletín

1 comentario:

  1. q programa usas para detectar las vulnerabilidades y reportarlas?

    ResponderBorrar

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!