Primero debemos descargar la extensión PwnFox para el navegador de Firefox desde el siguiente enlace.
https://addons.mozilla.org/es/firefox/addon/pwnfox/
Una vez instalado PwnFox debemos ir a «Settings».
Aquí se encuentra la configuración del proxy y debemos establecer el host en 127.0.0.1 y el puerto en 8080.
Una vez realizado esto debemos habilitar PwnFox. El estado cambiará de color rojo a verde indicando que ya está habilitado.
Ahora abriremos BurpSuite y debemos también añadir la extensión de PwnFox. Por lo que primero debemos ir al siguiente repositorio y descargar PwnFox.jar.
https://github.com/yeswehack/PwnFox/releases
Procedemos a agregar la extensión Java PwnFox.jar desde el menú extensiones de BurpSuite.
Una vez agregada debería estar activada por defecto.
En Firefox encontraremos los contenedores agregados por defecto por PwnFox. Si desea puede agregar más.
Para abrir un nuevo contenedor de PwnFox en Firefox se debe mantener presionado mas de lo habitual el icono «+» y se desplegará la lista de contenedores disponibles.
Para este ejemplo he elegido «PwnFox-red».
Ahora puedo ver que mi pestaña está coloreada de color rojo.
Si navegamos a www.google.com podemos ver que en el historial proxy de BurpSuite que todas las solicitudes se han marcado en color rojo. Esto es porque estamos en el contenedor de FireFox «PwnFox-red».
Además cada solicitud HTTP contendrá la cabecera «X-PwnFox-Color: red». El valor de esta cabecera cambiará según el color que elija.
Para la prueba de concepto de IDOR utilizaremos OWASP Juice Shop. Primeramente en el contenedor de Firefox «PwnFox-red» iniciaremos sesión la cuenta del usuario atacante.
Presionando el icono «+» un tiempo mas de lo habitual, nuevamente se despliegan los contenedores y abriremos una nueva pestaña «PwnFox-blue».
En el contenedor «PwnFox-blue» iniciamos sesión con la cuenta del usuario víctima. Recordemos que en el contenedor «PwnFox-red» tenemos la sesión iniciada del usuario atacante.
Si observamos la pestaña de proxy history en BurpSuite podemos observar las solicitudes de acuerdo al color elegido en el contenedor de PwnFox.
De esta forma en base a los colores podremos clasificar las solicitudes HTTP que corresponden al usuario atacante y cuales al usuario víctima.
Para automatizar el proceso de encontrar vulnerabilidades IDOR utilizaremos la extensión Auth Analyzer.
Auth Analyzer se puede instalar desde la BApp Store en BurpSuite Pro.
Una vez instalada, desde BurpSuite podremos abrirla desde el menú superior Auth Analyzer.
Primero en el contenedor «PwnFox-red» que es la sesión del usuario atacante podemos ver que no existe un historial de órdenes de compra.
Actualizamos esta URL para obtener el token de sesión JWT del usuario atacante. Podemos ver que su token es:
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCI6MjEsInVzZXJuYW1lIjoiIiwiZW1haWwiOiJhdHRhY2tlckBkb21haW4uY29tIiwicGFzc3dvcmQiOiI4MjdjY2IwZWVhOGE3MDZjNGMzNGExNjg5MWY4NGU3YiIsInJvbGUiOiJjdXN0b21lciIsImRlbHV4ZVRva2VuIjoiIiwibGFzdExvZ2luSXAiOiIwLjAuMC4wIiwicHJvZmlsZUltYWdlIjoiL2Fzc2V0cy9wdWJsaWMvaW1hZ2VzL3VwbG9hZHMvZGVmYXVsdC5zdmciLCJ0b3RwU2VjcmV0IjoiIiwiaXNBY3RpdmUiOnRydWUsImNyZWF0ZWRBdCI6IjIwMjMtMDYtMTIgMDI6Mjk6MDIuMzY4ICswMDowMCIsInVwZGF0ZWRBdCI6IjIwMjMtMDYtMTIgMDI6Mjk6MDIuMzY4ICswMDowMCIsImRlbGV0ZWRBdCI6bnVsbH0sImlhdCI6MTY4NjUzNzAyNn0.HyKi8HRHHx-b_WwvBcLWKaXEo8ehCXMCSrZl4arqGzmrugoqReDHmRDvCABssl1fwY_qSGG04k5vxO7iFIQs6L-_BfrqDgsaXv3KyF5EO0YCJN5lTONmUCqATFtWNLtCoie3SAa6wEnAaxNhWKxgKEXrtC8yolKUff9yOfhrdqU
En cambio si vamos al contenedor «PwnFox-blue» que es la sesión del usuario víctima y este si tiene una orden de compra en su historial.
Damos en clic en Track Order. Podemos ver que nos lleva a la URL «http://192.168.205.129:3000/#/track-result?id=139e-58f19af1f4725935» que contiene el código de orden «139e-58f19af1f4725935» en la URL y que en teoría solo el usuario víctima debería de ver.
Ahora si vamos historial proxy de BurpSuite podemos ver el token de sesión JWT del usuario víctima.
Ahora es momento de automatizar el ataque para encontrar vulnerabilidades IDOR en cualquier lugar de la página web. La idea es que podamos ir reemplazando el token JWT del usuario víctima por la del usuario atacante en cada una de las solicitudes HTTP cuando se navega en la interfaz web del usuario víctima. Aquí es cuando Auth Analyzer automatiza todo este proceso.
Primero y recomendable por hacer es añadir el sitio web en el scope. Esto es para evitar confusiones y tráfico no deseado de otros sitios web que pasen por el proxy y que no sean de nuestro interés. En el menú Target de BurpSuite podemos añadir nuestro sitio al scope según muestra la siguiente imagen.
Después debemos ir a Auth Analyzer y pegar el token Bearer de sesión del usuario atacante (el cual se obtuvo previamente) junto con la cabecera Authorization quedando de la siguiente forma.
Observese que por defecto el filtro de «Only In Scope» se encuentra activado. Ahí en la pestaña Sessions se encuentra el token del usuario atacante añadido con el formato «Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciO ………….».
En caso de que la sesión se basara en Cookies el formato sería «Cookie: cookieValue».
Ahora activamos Auth Analyzer. En la imagen siguiente se observa como está corriendo.
Para automatizar el proceso para encontrar vulnerabilidades IDOR, como comentamos previamente, debemos navegar por toda la interfaz web de la sesión del usuario víctima (contenedor «PwnFox-blue») para generar el mayor tráfico posible y así poder detectar vulnerabilidades IDOR.
Por ejemplo si navegamos por el review de los productos podremos observar en rojo el status con el valor SAME. Esto indica que cuando se reemplazó el token de sesión del usuario víctima por el del usuario atacante, el contenido de la respuesta HTTP es exactamente el mismo. Esto puede ser algo normal ya que ambos usuarios deberían tener el mismo permiso de visualizar los review de los productos de la tienda.
Si vamos a la derecha, podemos observar en la pestaña «Original» la solicitud HTTP donde originalmente el token de sesión del usuario víctima termina en «104».
Pero si cambiamos a la pestaña «user1» donde se encuentra la solicitud HTTP del usuario atacante, podremos observar que Auth Analyzer ha reemplazado de forma automática el token del usuario víctima por el del usuario atacante. Se observa que el token del usuario atacante termina en «dqU».
Así también para cada pestaña en Auth Analyzer «Original» y «User1» podemos ver su respuesta HTTP. En este caso ambas respuestas deberían ser igual, ya que como se comentó ambos usuarios tienen el privilegio de visualizar la información de reviews de productos, por lo que podemos deducir que esto no es una vulnerabilidad IDOR.
Respuesta HTTP en pestaña «Original».
Respuesta HTTP en pestaña «User1».
Ahora regresemos un poco atrás. Para la poc de IDOR vamos a actualizar la URL que se comentó previamente y es la de Track Order en la sesión del usuario víctima.
En Auth Analyzer podemos ver que en Status tenemos el valor «SAME» en rojo, lo cual nos lleva a pensar que se ha encontrado una vulnerabilidad IDOR, ya que el usuario atacante no debería poder visualizar la URL de consulta de Track Order del usuario víctima y aparentemente estamos logrando visualizar el mismo contenido, tanto con el token del usuario víctima como con el del del usuario atacante. Ahí originalmente podemos ver el token de sesión del usuario víctima en la pestaña «Original».
En la respuesta HTTP se observa la información del Track Order lo cual era de esperar.
Si vamos a la pestaña «User1» podemos ver que automáticamente Auth Analyzer ha reemplazado el token del usuario víctima por el del usuario atacante.
Y si cambiamos a la pestaña Response podemos visualizar que la respuesta es exactamente igual a la respuesta anterior.
En conclusión, logramos ver con el token del usuario atacante la información de un Track Order que solo el usuario víctima debería de ver, por lo tanto existe una vulnerabilidad de Broken Access Control.
https://owasp.org/Top10/A01_2021-Broken_Access_Control/
Habrá casos que en el status de Auth Analyzer se posea el valor «SIMILAR» marcado en color amarillo y habría que ir a inspeccionar detalladamente la respuesta para ver si se trata de una vulnerabilidad IDOR.
Finalmente, en otros casos aparecerá el Status «DIFFERENT» en color verde y en donde efectivamente no habrá peligro de vulnerabilidad IDOR.