Durante bastante tiempo, he estado buscando vulnerabilidades en la plataforma HackerOne y he estado asignando una cierta cantidad de tiempo fuera del trabajo principal para verificar mis programas favoritos y nuevos. Innumerables veces me encontré con una vulnerabilidad XSS basada en cookies, que se convertirá en el personaje principal de este artículo. Este tipo de vulnerabilidad ocurre cuando el valor del parámetro cookie se refleja en la página. Por defecto, se consideran auto-XSS a menos que, a su vez, demostremos su peligro. En realidad, hoy les diré cómo explotar las vulnerabilidades XSS basadas en cookies, y también daré un ejemplo al probar una compañía de la que recibí $ 7300 en total para el estudio.
Para ejecutar JavaScript en el lado del usuario, debe encontrar una manera de configurar una cookie y, si es necesario, atraer a la víctima a una página donde, a su vez, la cookie está incrustada. Posibles formas de explotar este error:
⠀
1. Inyección de CRLF. Esta vulnerabilidad ocurre cuando no hay una verificación y bloqueo adecuados de los caracteres de salto de línea. Podemos implementar el encabezado Set-cookie en respuesta con el nombre deseado, así como el valor de la cookie y configurarlo en el navegador. Ejemplo de la vida real: inyección de CRLF resbaladizo en twitter.com en una redirección - https://twitter.com/login?redirect_after_login=/jjjkkk 嘊 嘍 Set-Cookie: jjjjj = a; domain = twitter.com
Los informes sobre este tipo de vulnerabilidad se pueden leer en HackerOne
hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection2. Vulnerabilidad XSS en el subdominio. Se requiere que XSS sea de acceso público y esté ubicado en el comodín * .vulnerabledomain.com. Para muchos programas de recompensas de errores, los subdominios están fuera del alcance, es decir, en la mayoría de los casos, los errores no se aceptan o se reciben con la marca "no elegible para la recompensa". En tales casos, no debe retroceder, pero en aras de conectarse con XSS basado en cookies, puede invertir su tiempo en la búsqueda de XSS para obtener una recompensa. Si se detecta XSS, podemos configurar o eliminar la cookie utilizando la función document.cookie.
Mejora del impacto: a menudo, la víctima confía en el dominio principal de vulnerabledomain.com más que, por ejemplo, jira.vulnerabledomain.com, e incluso con la URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . Es más probable que cambie al dominio principal que al subdominio si este subdominio no está asociado con una cuenta personal o autorización. Con base en lo anterior, podemos utilizar la funcionalidad de redireccionamiento en el sitio para redirigir al subdominio
vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path para un mejor efecto.
Si la víctima tiene una sesión activa, la redirección será automática, de lo contrario, se necesita autorización. Cuando el usuario hace clic en dicho enlace, la cookie también se instalará desde el subdominio en el que está presente Reflected XSS, se puede enviar más arriba, a la página con XSS basado en cookies, donde el exploit podría funcionar, lo que, a su vez, capturará el valor CSRF del token y complete la solicitud para cambiar la dirección de correo electrónico. Por lo tanto, una combinación de dos vulnerabilidades XSS puede conducir a una toma de control de la cuenta si no hay problemas asociados, como la confirmación adicional del cambio de contraseña o código de correo electrónico desde el buzón antiguo.
3. Detección de archivos de prueba que permiten configurar cookies. Es suficiente para descubrir la herramienta de detección de contenido (dirb, dirserach, etc.), comenzar a cavar, y si los desarrolladores olvidaron realizar la limpieza, puede tropezar con dichos archivos.
Recientemente, encontré una página html de servlet de prueba en la que era posible instalar una cookie con un nombre y un valor arbitrarios. La protección en la solicitud POST, por supuesto, estaba ausente, por lo que si la víctima visitara el exploit CSRF (o puede cambiar la POST a GET), sería posible instalar la cookie en su navegador.
Este error se calificó como una alternativa insuficiente a la inyección de CRLF, se solucionó eliminando / examples / y pagó $ 150 como un error de baja gravedad. Aunque el h1 triager entregó un medio, los desarrolladores aún estaban inclinados a creer que esto es de baja gravedad.
4. Hombre en el ataque medio (MITM). Este método solo se puede aplicar si no hay una marca segura en la cookie. Si no sabe qué tipo de bandera es o simplemente desea actualizar su memoria, le aconsejo que vea la presentación de Seguridad de cookies con OWASP London 2017
www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .
Para un ataque exitoso, es necesario que la víctima esté en la red del atacante o que la resolución dns pueda verse afectada. Para verificar la vulnerabilidad, es necesario:
1) aloja el archivo index.php con los siguientes contenidos:
<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?>
2) Agregue la siguiente línea a su archivo / etc / hosts /: 127.0.0.1 non-existed-subdomain.vulnerabledomain.com
3) Visite subdominio no existente.dominiovulnerable.com y luego abra la página en la que se refleja la cookie.
Un maravilloso ejemplo de explotación de MITM en e.mail.ru es https://hackerone.com/reports/312548, como puede ver, MITM fue suficiente para demostrar un pequeño peligro de vulnerabilidad, pero el premio no coincidía con el nivel de XSS almacenado, ya que solo se mostró Modo de operación "local", es decir, no "in-the-wild". Si el investigador pasó un poco de tiempo buscando inyecciones XSS o CRLF (que son innumerables) ubicadas en * .mail.ru, la recompensa podría aumentar ligeramente.
Pero no todos los programas de hackerone aceptan XSS basados en cookies a través de MITM. Si las exclusiones del alcance dicen "Self XSS", entonces esta operación puede considerarse como Self XSS y establecer informativo o n / a, que no siempre es agradable. Ahora hablaré sobre un incidente similar que me sucedió durante la próxima búsqueda en la plataforma.
Al probar el sitio, de repente vi que el valor de las cookies redactadas se refleja en uno de los subdirectorios del sitio. Lo primero que hice fue comprobar la visualización de los caracteres '"/ <>. Resultó que solo se filtraron los caracteres <>, y esto nos dice que no podemos ir más allá, pero también queda claro que los caracteres restantes no se filtran Sin pensarlo dos veces, implementamos '-alert (document.domain) -' y se ejecuta js.
Como los desarrolladores no le dieron a la cookie el indicador de seguridad, en este caso el método MITM funciona. Se decidió enviar un informe al programa con el siguiente impacto:
El personal de HackerOne (triager) dejó en claro que esto es self-XSS y tengo que esforzarme más:
Después de eso, comencé a navegar por el sitio y tratar de encontrar la inyección de CRLF o XSS para demostrar el peligro.
⠀ Tuve que expandir la lista de subdominios con la ayuda de un diccionario grande, raspar subdominios con certificados SSL y usar algunos otros trucos. El resultado no tardó en llegar, ya que la mayoría de las herramientas que ejecuto con VPS. De vez en cuando, también se detectaron otros errores en el camino, lo que informé, haciendo que fuera de alcance fuera de alcance, si fuera necesario. Encontré muchos redireccionamientos abiertos e incluso un error de control de acceso incorrecto por $ 5000, pero aún no pude detectar las vulnerabilidades necesarias para el paquete. El error mencionado anteriormente es bastante interesante y peligroso, todo el subdominio se desconectó inmediatamente después del informe, tal vez en el futuro abriré el informe en hackerone.com/w2w, si el programa se hace público.
Una semana después, se verificaron los resultados de la secuencia de comandos para detectar el contenido, donde se encontró el punto final / verificación, a lo que al principio no le di especial importancia, pero aún así configuré la secuencia de comandos: se encontró el subdirectorio / verificacion / inicio de sesión. Después de la transición, se mostró la página /verification/login/?redirect_uri=https://vulnerabledomain.com, que redirigió al valor de redirect_uri después de iniciar sesión o inmediatamente redirigió si hubo una sesión. Después de volar hacia el intruso, se descubrió un bypass de protección de redireccionamiento abierto: vulnerabledomain.com@anotherdomain.com. Intenté desenrollar el error en XSS: la carga útil de javascript: alert (1) falló, javascript: alert (1) // también. Y aquí está la carga útil de JavaScript: // https: //vulnerablesite.com/%250A1? Alert (1): 0 disparos, porque debido a la presencia de
vulnerablesite.com , el parámetro pasó la validación de la lista blanca.
Después de conducir frenéticamente el mouse a través de la ventana de notificación (siempre lo hago), inmediatamente me puse a trabajar en mi XSS basado en cookies. Usando javascript: https: //vulnerabledomain.com/%0A1? Documento% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-alert% 28document% 2edomain% 29-% 5c% 27% 3b% 20expires% 3dFri% 2c% 203% 20Aug% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20path% 3d% 2f% 3b% 20domain% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 La cookie se instaló con éxito en * .vulnerabledomain.com . Después de ir a la página con la cookie, ¡la atesorada alerta despegó! Doble XSS, ¡salud! :) Complementé el informe y esperé una respuesta.
El mismo día, "Buena captura" voló desde el tríada (si se le puede llamar así), y se pagó la recompensa. ¡Dios bendiga a las compañías que pagan en triaje!
Para XSS basado en DOM, con el que instalé la cookie, también llegó la recompensa.
Resultados de prueba
$ 1000 + $ 1000 + $ 200 (OR) + $ 100 (OR) =
$ 2300Este programa ha estado funcionando durante más de un año, pero en menos de un mes pude ocupar el primer lugar e ir bastante con las pruebas.Traté de eliminar la mayoría de los puntos finales, evaluar su reacción, comprender cómo funciona el sitio e incluso probar la aplicación de escritorio. Este programa de recompensas de errores se ha convertido en uno de los más queridos en HackerOne. ¡Espero que algún día tú también encuentres el mismo! :)
Además, fue este programa el que me dio un nuevo impulso (mail.ru - el primero), - con él llegué a 2500 reputación (hola sudadera con capucha) y llegué al 36to lugar en la tabla de clasificación por reputación en 90 días, lo que debería dar nuevos beneficios. . Aunque parece que los injertos llegan independientemente de la presencia en la tabla de clasificación, a menudo cancelo los injertos viejos y espero nuevos en la cola.
Breve breve
- Los XSS basados en cookies son totalmente explotables. Si intenta profundizar un poco más, puede obtener una recompensa en lugar de n / a, destruyendo la señal y la reputación de -5.
- Si el programa es antiguo, esto no significa que no habrá vulnerabilidades en él. Si las frutas cuelgan en el árbol durante mucho tiempo, las frutas bajas se recogerán y se tomarán de inmediato (adquisiciones de subdominios, etc.). Otras frutas continúan colgando, pero más alto. Para obtenerlos, debe hacer un esfuerzo.
- A veces es mejor concentrarse en un programa durante mucho tiempo, encontrar tantas vulnerabilidades como sea posible y monitorearlo. Es mejor encontrar el programa que prefiera y romperlo.
- La perseverancia y el deseo de comprender cómo funciona una aplicación web, así como ciertas funcionalidades y su interacción entre ellos, es la clave para buscar con éxito las vulnerabilidades en una recompensa de errores.
Si desea mantenerse al tanto de mis últimos artículos y noticias, le aconsejo que se suscriba al canal de telegramas / twitter, cuyos enlaces se pueden encontrar a continuación.