Las vulnerabilidades de Referencia a Objetos Directos Inseguros (IDOR) siguen estando en la lista Top 10 de OWASP en 2021, y hay razones claras para ello. Las fallas IDOR son frecuentes en las aplicaciones web, especialmente en las APIs. Pero la pregunta crítica es, ¿cómo descubrimos estas vulnerabilidades? ¿Qué estrategias pueden mejorar la eficiencia en el descubrimiento de IDOR? Y más allá de eso, ¿cómo puedes ampliar tus habilidades en seguridad? ¡Sumérgete con nosotros en esta exploración!
Instalando PwnFox
Primeramente se descargó 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 se ingresó a «Settings».
Aquí se encontró la configuración del proxy y se estableció el host en 127.0.0.1 y el puerto en 8080.
Enseguida de habilitó PwnFox. Al habilitarlo se observó como el estado cambió de color rojo a verde indicando que se encontraba habilitado.
Entonces se abrió la herramienta de BurpSuite y se añadió la extensión de PwnFox. Dicha extensión con soporte para Java y con el nombre "PwnFox.jar" se puede descargar desde el siguiente repositorio de GitHub.
https://github.com/yeswehack/PwnFox/releases
Se procedió a agregar la extensión Java "PwnFox.jar" desde el menú extensiones de BurpSuite.
Una vez agregada debería estar activada por defecto.
Utilizando PwnFox
En Firefox se pudieron observar algunos de los contenedores agregados por defecto por el propio PwnFox (Aunque se pueden agregar más de forma manual).
Para abrir un nuevo contenedor de PwnFox en Firefox se debe mantener presionado mas de lo habitual el icono "+" y se desplegarán la lista de contenedores disponibles.
Para este ejemplo se ha elegido "PwnFox-red".
Ahora se puede ver que la pestaña está coloreada de color rojo.
Al navegar a www.google.com se observaron en el historial proxy de BurpSuite todas las solicitudes marcadas de color rojo. Esto es porque se encontraba posicionado 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 se elija.
Para la prueba de concepto de IDOR se utilizó OWASP Juice Shop. Primeramente en el contenedor de Firefox "PwnFox-red" se inició sesión con la cuenta del usuario atacante.
Presionando el icono "+" un tiempo mas de lo habitual, nuevamente se desplegaron los contenedores y se eligió abrir una nueva pestaña "PwnFox-blue".
En el contenedor "PwnFox-blue" se inició sesión con la cuenta del usuario víctima. Se debe recordar que en el contenedor "PwnFox-red" se tiene la sesión iniciada del usuario atacante.
En la pestaña de "proxy history" en BurpSuite se observaron las solicitudes de acuerdo al color elegido en el contenedor de PwnFox.
De esta forma en base a los colores se pueden clasificar las solicitudes HTTP que corresponden al usuario atacante y cuales al usuario víctima.
Instalando Auth Analyzer
Para automatizar el proceso de encontrar vulnerabilidades IDOR se utilizó la extensión "Auth Analyzer" desde la BApp Store en BurpSuite Pro.
Una vez instalada, desde BurpSuite se abrió desde el menú superior "Auth Analyzer".
Análisis de la sesión y permisos de los usuarios
En el contenedor "PwnFox-red" que es la sesión del usuario atacante, se observó que no existe un historial de órdenes de compra, según se muestra en la imagen de a continuación.
Al actualizar la previa URL se obtuvo el token de sesión JWT del usuario atacante. El token es el siguiente:
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdGF0dXMiOiJzdWNjZXNzIiwiZGF0YSI6eyJpZCI6MjEsInVzZXJuYW1lIjoiIiwiZW1haWwiOiJhdHRhY2tlckBkb21haW4uY29tIiwicGFzc3dvcmQiOiI4MjdjY2IwZWVhOGE3MDZjNGMzNGExNjg5MWY4NGU3YiIsInJvbGUiOiJjdXN0b21lciIsImRlbHV4ZVRva2VuIjoiIiwibGFzdExvZ2luSXAiOiIwLjAuMC4wIiwicHJvZmlsZUltYWdlIjoiL2Fzc2V0cy9wdWJsaWMvaW1hZ2VzL3VwbG9hZHMvZGVmYXVsdC5zdmciLCJ0b3RwU2VjcmV0IjoiIiwiaXNBY3RpdmUiOnRydWUsImNyZWF0ZWRBdCI6IjIwMjMtMDYtMTIgMDI6Mjk6MDIuMzY4ICswMDowMCIsInVwZGF0ZWRBdCI6IjIwMjMtMDYtMTIgMDI6Mjk6MDIuMzY4ICswMDowMCIsImRlbGV0ZWRBdCI6bnVsbH0sImlhdCI6MTY4NjUzNzAyNn0.HyKi8HRHHx-b_WwvBcLWKaXEo8ehCXMCSrZl4arqGzmrugoqReDHmRDvCABssl1fwY_qSGG04k5vxO7iFIQs6L-_BfrqDgsaXv3KyF5EO0YCJN5lTONmUCqATFtWNLtCoie3SAa6wEnAaxNhWKxgKEXrtC8yolKUff9yOfhrdqU
Caso contrario, al ingresar al contenedor "PwnFox-blue" que es la sesión del usuario víctima se observó que este si poseía una orden de compra en su historial.
Se dio clic en "Track Order", y la aplicación llevó a la URL "http://192.168.205.129:3000/#/track-result?id=139e-58f19af1f4725935". Se observó que la URL contenía el código de orden "139e-58f19af1f4725935" y que en teoría solo el usuario víctima debería de ver.
Enseguida, al ingresar al historial proxy de BurpSuite se obtuvo el token de sesión JWT del usuario víctima.
Automatizando el ataque de IDOR
Ahora es momento de automatizar el ataque para encontrar vulnerabilidades IDOR en cualquier lugar de la página web. La idea es 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 interés. En el menú Target de BurpSuite se añadió nuestro sitio al "scope" según muestra la siguiente imagen.
Después se ingresó a Auth Analyzer y se pegó el token Bearer de sesión del usuario atacante (el cual se obtuvo previamente) junto con la cabecera Authorization quedando de la siguiente forma.
Obsérvese 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". Enseguida se activó Auth Analyzer y en la siguiente imagen se observa como se encuentra en ejecución.
Para automatizar el proceso para encontrar vulnerabilidades IDOR, como se comentó previamente, se debe 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 al navegar por el review de los productos se observó en color rojo el status con el valor "SAME". Esto indicó que cuando se reemplazó el token de sesión del usuario víctima por el del usuario atacante, el contenido de la respuesta HTTP fue 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.
Al navegar al lado derecho, se observó en la pestaña "Original", la solicitud HTTP donde originalmente el token de sesión del usuario víctima terminaba en "104".
Pero al cambiar a la pestaña "user1" donde se encontraba la solicitud HTTP del usuario atacante, se observó que Auth Analyzer reemplazó de forma automática el token del usuario víctima por el del usuario atacante. Se observó que el token del usuario atacante termina en "dqU".
Así también para cada pestaña en Auth Analyzer "Original" y "User1» se puede visualizar la 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".
Volviendo un poco atrás. Para la poc de IDOR, se actualizó la URL de Track Order en la sesión del usuario víctima.
En Auth Analyzer se observó que en Status se poseía el valor "SAME" en rojo, lo cual 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 se está logrando visualizar el mismo contenido, tanto con el token del usuario víctima como con el del usuario atacante. Ahí originalmente se observó el token de sesión del usuario víctima en la pestaña "Original".
En la respuesta HTTP se observó la información del Track Order lo cual era de esperar.
Al ingresar en la pestaña "User1" se observó que automáticamente Auth Analyzer ha reemplazado el token del usuario víctima por el del usuario atacante.
Y al cambiar a la pestaña Response se visualizó que la respuesta es exactamente igual a la respuesta anterior.
En conclusión, se logró visualizar 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.
Conclusión
Mediante la implementación de estos dos complementos, aumentarás significativamente tus posibilidades de detectar vulnerabilidades de IDOR y problemas de control de acceso inadecuado. Además, te ofrecen la ventaja de automatizar ciertas consultas, lo que te permite concentrar tus esfuerzos en los hallazgos más relevantes e interesantes.