OPEN REDIRECT

Comenzaremos el post con las vulnerabilidades de redireccionamiento abierto (open redirect), que ocurren cuando un objetivo visita un sitio web y ese sitio web envía su navegador a una URL diferente, potencialmente en un dominio separado. Las redirecciones abiertas aprovechan la confianza de un determinado dominio para atraer victimas a un sitio web malicioso. Un ataque de phishing también puede acompañar a una redirección para engañar a los usuarios creyendo que están enviando información a un sitio confiable cuando, en realidad, su información se envía a un sitio malicioso. Cuando se combinan con otros ataques, las redirecciones abiertas pueden también permitir a los atacantes distribuir malware a las victimas o permitirles robar tokens de OAuth (un tema que exploraremos en más adelante. Debido a que los redireccionamientos abiertos solo redireccionan a los usuarios, a veces se consideran de bajo impacto y no merecen tratamiento especial. Por ejemplo, el programa de recompensas por errores de Google normalmente considera que los redireccionamientos abiertos tienen un riesgo demasiado bajo para recompensarlos. El Proyecto de seguridad de aplicaciones web abiertas (OWASP), que es una comunidad que se centra en la seguridad de las aplicaciones y que lista las fallas de seguridad más críticas en aplicaciones web, también eliminó las redirecciones abiertas de su lista de los 10 principales fallas de vulnerabilidades de 2017
.
Aunque los redireccionamientos abiertos son vulnerabilidades de bajo impacto, son excelentes para aprender cómo los navegadores manejan los redireccionamientos en
general. En este post, aprenderá a explotar redirecciones y cómo identificar parámetros clave, usando tres informes de errores como ejemplos.

como funcionan las open redirects

Los redireccionamientos abiertos ocurren cuando un desarrollador desconfía de la entrada controlada del atacante para redirigir a otro sitio, generalmente a través de un parametro URL, de la tag <meta> de HTML o de la propiedad del DOM window-location. Muchos sitios web redireccionan intencionalmente a los usuarios a otros sitios mediante la colocacion de una URL de destino como parámetro en una URL original. La aplicación usa este parámetro para decirle al navegador que envíe una solicitud GET a la URL de destino. Por ejemplo, suponga que Google tenía la función de redirigir a los usuarios a Gmail visitando la siguiente URL:

https://www.google.com/?redirect_to=https://www.gmail.com

En este escenario, cuando visita esta URL, Google recibe una solicitud GET y utiliza el valor del parámetro redirect_to para determinar dónde redirigir su navegador. Después de hacerlo, los servidores de Google devuelven una respuesta HTTP con un código de estado para instruir al navegador para redirigir al usuario. Normalmente, el código de estado es 302, pero en algunos casos podría ser 301, 303, 307 o 308. Estos códigos de respuesta HTTP le dicen a su navegador que no se ha encontrado la página; sin embargo, el código también informa al navegador de realizar una solicitud GET al valor de parámetro redirect_to , https://www.gmail.com/, que se indica en la respuesta del header Location. El header Location especifica dónde se redirigen las solicitudes GET.

Ahora, suponga que un atacante cambia la URL original a la siguiente:

https://www.google.com/?redirect_to=https://www.attacker.com

Si Google no valida que el parámetro redirect_to sea para uno de sus propios sitios legítimos al que pretende enviar visitantes, un atacante podría sustituir el parámetro por su propia URL. Como resultado, una respuesta HTTP podría indicarle a su navegador que
haga una solicitud GET a https: // http://www.atacker.com /. Después de el atacante te tiene en su sitio malicioso, podrían llevar a cabo otros ataques.
Cuando busque estas vulnerabilidades, esté atento a los parámetros de URL que incluyen ciertos nombres, como url =, redirect =, next =, y así sucesivamente, lo que puede indicar a las URL que los usuarios seran redirigidos. También tenga en cuenta que los parametros de redireccion no siempre pueden tener un nombre obvio; los parámetros variarán de un sitio a otro o incluso dentro de un sitio. En algunos casos, los parámetros pueden estar etiquetados con solo caracteres individuales, como como r = o u =. Además de los ataques basados ​​en parámetros, las etiquetas <meta> y el código javascript pueden hacer redireccion en los navegadores. Las etiquetas <meta> pueden indicar a los navegadores que actualicen una página web y realizar una solicitud GET para una URL definida en el atributo de contenido de la etiqueta. Esto es lo que podría verse así:

<meta http-equiv="refresh" content="0; url=https://www.google.com/">

El atributo content define cómo los navegadores crean una solicitud HTTP de dos formas. Primero, el atributo de contenido define cuánto tiempo el navegador espera antes de realizar la solicitud HTTP a la URL; en este caso, 0 segundos. En segundo lugar, el atributo content especifica el parámetro URL en el sitio web que crea el navegador la solicitud GET; en este caso, https://www.google.com. Los tacantes pueden utilizar este comportamiento de redireccionamiento en situaciones en las que tienen la capacidad de controlar el atributo content de una etiqueta o de inyectar su propia etiqueta a través de alguna otra vulnerabilidad. Un atacante también puede usar JavaScript para redirigir a los usuarios modificando windows-location a través del Modelo de objetos de documento (DOM). El DOM es una API para los documentos HTML y XML que permiten a los desarrolladores modificar la estructura, estilo y contenido de una página web. Ya que la propiedad location indica dónde se debe redirigir una solicitud, los navegadores interpretarán inmediatamente este JavaScript y redirigiran a la URL especificada. Un atacante puede modificar el propiedad location mediante cualquiera de los siguientes codigos JavaScript:

window.location = https://www.google.com/
window.location.href = https://www.google.com
window.location.replace(https://www.google.com)

Por lo general, se presentan oportunidades para establecer el valor window.location. solo donde un atacante puede ejecutar JavaScript, ya sea a través de una vulnerabilidad XSS o donde el sitio web permita intencionalmente a los usuarios definir una URL a la que redireccionar. Cuando busque vulnerabilidades de redireccionamiento abierto, por lo general, supervisará su historial de proxy para obtener una solicitud GET enviada al sitio que está probando que incluye un parámetro especificando una redirección de URL.

shopify theme install open redirect

El primer ejemplo de un redireccionamiento abierto que vemos fue el que se encuentra en Shopify, que es una plataforma de comercio que permite crear tiendas para vender productos. Shopify permite a los administradores personalizar la apariencia de sus tiendas cambiando su tema. Como parte de esa funcionalidad, Shopify ofreció una función para proporcionar una vista previa del tema redirigiendo a los propietarios de la tienda a una URL. La URL de redireccionamiento estaba formateada como tal:

https://app.shopify.com/services/google/themes/preview/supply--blue?
domain_name=attacker.com

El parámetro domain_name al final de la URL redirigía al dominio de la tienda del usuario y añadiendo /admin al final de la URL, Shopify esperaba que el domain_name siempre fuera la tienda de un usuario y no estaba validando su valor como parte del dominio de Shopify. Como resultado, un atacante podría explotar el parámetro para redirigir un objetivo a http://atacker.com/admin/ donde un atacante malintencionado podría llevar a cabo otros ataques, es decir, Shopify no validaba el parametro de redireccion y con ello se podia enviar a la victma a cualquier sitio.

shopify login open redirect

Este segundo ejemplo de redireccionamiento abierto es similar al primer ejemplo de Shopify excepto en este caso, el parámetro de Shopify no redirige al usuario al dominio especificado por el parametro URL; en su lugar, el redireccionamiento abierto agrega el valor del parámetro al final de un subdominio de Shopify. Normalmente, esta funcionalidad se utilizaría para redirigir a un usuario a una página en una tienda determinada. Sin embargo, los atacantes aún pueden manipular estas URL para redirigir el navegador fuera del subdominio de Shopify y al sitio web de un atacante agregando caracteres para cambiar el significado de la URL.
En este error, después de que el usuario inició sesión en Shopify, Shopify usó el parámetro checkout_url para redirigir al usuario. Por ejemplo, digamos que un objetivo visitó esta URL:

http://mystore.myshopify.com/account/login?checkout_url=.attacker.com

Habrían sido redirigidos a la URL: http://mystore.myshopify.com.atacker.com /, que no es un dominio de Shopify. Ya que la URL termina en. .com y las búsquedas DNS usan la etiqueta de dominio más a la derecha, la redirección va al dominio .com. Así que cuando
http://mystore.myshopify.com. .com / es enviado para la búsqueda de DNS, coincidirá con .com, de la que Shopify no es propietario, ni myshopify.com. Aunque un atacante no podría enviar libremente un objetivo a cualquier lugar, podrían enviar un usuario a
otro dominio agregando caracteres especiales, como un punto, a los valores que pueden manipular.

hackerone insterstitial redirect

Algunos sitios web intentan protegerse contra las vulnerabilidades de redireccionamiento abierto mediante la implementación de páginas web intersticiales, que se muestran antes del contenido esperado. Cada vez que redirige un usuario a una URL, puede mostrar una página web intersticial con un mensaje que explica al usuario que abandona el dominio en el que están. Como resultado, si la página de redireccionamiento muestra un inicio de sesión falso o intenta fingir ser el dominio de confianza, el usuario sabrá que están siendo redirigidos. Este es el enfoque que HackerOne toma cuando sigue a la mayoría de las URL fuera de su sitio; por ejemplo, al seguir los enlaces en los informes enviados. Aunque puede utilizar páginas web intersticiales para evitar las vulnerabilidades de redireccion, las complicaciones en la forma en que interactúan los sitios. entre sí pueden conducir a enlaces comprometidos. HackerOne utiliza Zendesk, un sistema de tickets de soporte de servicio al cliente, para su subdominio https://support.hackerone.com/. Previamente,
cuando hackerone.com redirige a /zendesk_session, desde la plataforma de HackerOne a la plataforma Zendesk de HackerOne sin una página intersticial porque las URL que contienen el dominio hackerone.com eran enlaces de confianza. (HackerOne ahora redirige a https://support.hackerone.com a docs.hackerone.com a menos que
está enviando una solicitud de soporte a través de la URL /hc/en-
us/requests/new. Sin embargo, cualquiera puede crear una cuenta de Zendesk y pasarla al parametro /redirect_to_account? State =. La cuenta personalizada de Zendesk podría redirigirse a otro sitio web que no sea propiedad de Zendesk o HackerOne. Ya que Zendesk permitió redireccionar entre cuentas sin páginas intersticiales, un usuario podría ser llevado a un sitio no confiable sin previo aviso. Como solución, los enlaces de HackerOne son identificados para que contengan zendesk_session como enlaces externos,
generando así una página de advertencia intersticial al hacer clic. Para confirmar esta vulnerabilidad, el hacker Mahmoud Jamal creó una cuenta en Zendesk con el subdominio
http://compayn.zendesk.com. Luego agregó el siguiente Código JavaScript al archivo de encabezado usando el tema del edior de Zendesk , que permite a los administradores personalizar su cuenta de Zendesk:

<script>document.location.href = «http://evil.com»;</script>

Usando este JavaScript, Jamal indicó al navegador que visitara http://evil.com. La etiqueta <script> denota código en HTML y document se refiere a todo el documento HTML que Zendesk devuelve, que es la información de la página web. Los puntos y los nombres que siguen al documento son sus propiedades. Las propiedades mantienen información y valores que describen un objeto o pueden ser manipulado para cambiar el objeto. Entonces puedes usar la propiedad location para controlar la página web que muestra su navegador y utilizar la subpropiedad href (que es una propiedad de la ubicación) para redirigir el navegador al sitio web definido. Visitando el siguiente enlace redireccionó a los objetivos a Zendesk de Jamal al subdominio, que hizo que el navegador del objetivo ejecutara el script de Jamal y los redirigió a http://evil.com:

https://hackerone.com/zendesk_session?
locale_id=1&return_to=https://support.hackerone.com/
ping/redirect_to_account?state=compayn:/

Dado que el enlace incluye el dominio hackerone.com, la página web intersticial no se muestra y el usuario no sabe que la página que estaban visitando no es segura. Curiosamente Jamal informó originalmente que faltaba el redireccionamiento de la página intersticial a Zendesk, pero no se tuvo en cuenta y no se marcó como vulnerabilidad. Naturalmente, siguió investigando para ver cómo el intersticial faltante podría explotarse. Eventualmente, encontró el ataque de redireccionamiento de JavaScript que convenció a HackerOne de pagarle una recompensa.

resumen

Mientras busca vulnerabilidades, tenga en cuenta los servicios que usa un sitio porque cada uno representa nuevos vectores de ataque. Esta vulnerabilidad de HackerOne fue posible mediante la combinación de uso de HackerOne y de Zendesk . Además, a medida que encuentre errores, habrá ocasiones en las que las implicaciones de seguridad no son fácilmente comprendidas por la persona. Dicho esto, habrá ocasiones en las que las empresas no estén de acuerdo con usted. Si ese es el caso, continúe investigando como lo hizo Jamal y mira si puedes probar el exploit o combinarlo con otra vulnerabilidad para demostrar impacto. Y si no, vendelo a quien sea si no le hacen caso.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s