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