¡Hola a todos! Aquí estamos de nuevo y esta vez seguimos preparando la certificación Burp Suite Certified Professional (BSCP), que proporciona una base muy buena de cara a auditorías web y gestión de la presión, sobre todo en el examen para el cual te proporcionan 4 horas y hay que explotar hasta 6 vulnerabilidades. Además, se trata de un examen muy barato (<100€) lo que la hace sumamente atractiva.

Antes de nada, recordad que PortSwigger nos permite probar 30 días su versión profesional de Burp Suite. Os recomendamos que activéis esta versión para poder probar todas las funcionalidades de la herramienta.

En esta entrada explicaremos y solucionaremos todos los laboratorios relativos a Access Control Vulnerabilities. Hay muchos walkthroughs sobre cómo resolver estos laboratorios, pero exponerlos aquí nos sirve para afianzar conceptos y enseñaros además algunos trucos de uso de Burp Suite Professional, así como comentar veces que hemos visto las vulnerabilidades estudiadas en los laboratorios en la vida real. Sin más dilación, ¡comenzamos!

Este tipo de vulnerabilidades surgen la mayor parte de las veces de errores humanos, ya sean a la hora de desarrollar el código de la aplicación, de desplegar configuraciones o de bastionar los sistemas. Dado que tienen un componente humano, son muy prevalentes en entornos reales. Nos hemos encontrado vulnerabilidades relativas al control de acceso en multitud de aplicaciones, la mayoría de ellas con un impacto muy elevado. Por ello, te recomendamos que veas esta entrada del blog y siempre tengas un pensamiento lateral a la hora de hacer tus análisis, ya que muchas veces estos errores no son sencillos de detectar a primera vista, pero son devastadores.

Lab1 (Apprentice) – Excessive trust in client-side controls

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «Solve the lab by deleting the user carlos.». En este laboratorio, por tanto, debemos encontrar el panel de administración y eliminar al usuario «carlos».

Para comenzar con la enumeración en este laboratorio, obtenemos en primer lugar el archivo «robots.txt». Esto es algo bastante útil normalmente si es que la aplicación lo expone, ya que podemos ver algunas rutas y en ocasiones son interesantes:

Simplemente accediendo a la ruta anterior, vemos que el panel de administración se muestra sin exigir ningún tipo de autenticación y, por tanto, el usuario «carlos» puede borrarse sin mayor problema.

Lab2 (Apprentice) – Unprotected admin functionality with unpredictable URL

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «Solve the lab by accessing the admin panel, and using it to delete the user carlos.». En este laboratorio, por tanto, debemos encontrar el panel de administración y eliminar al usuario «carlos».

En este caso, el fichero «robots.txt» no nos divulga la información sobre el panel de administración. Sin embargo, haciendo un análisis simple de las respuestas obtenidas al navegar por la aplicación web, podemos observar que la ruta a dicho panel se incluye directamente en código Javascript:

De nuevo, simplemente accediendo a la ruta anterior, podemos visualizar el panel de administración y borrar al usuario «carlos».

Lab3 (Apprentice) – User role controlled by request parameter

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «Solve the lab by accessing the admin panel and using it to delete the user carlos.». En este laboratorio, por tanto, debemos acceder al panel de administración manipulando nuestro rol y eliminar al usuario «carlos».

Antes de intentar explotar la vulnerabilidad, lo que haremos será mapear la aplicación, accediendo a la funcionalidad con el usuario «wiener:peter» proporcionado. A priori, a nivel de frontal web, no vemos nada relativo al panel de administración. Sin embargo, al realizar la petición al recurso «my-account», descubrimos la cookie «Admin», cuyo valor es «false» para el usuario «wiener». Asimismo, esta cookie es inicializada durante el inicio de sesión.

El siguiente paso consistirá, por tanto, en intentar cambiar el valor de cookie a «true» para intentar ver si en el frontal se producen cambios significativos. Interceptamos, pues, la petición al recurso «my-account» y manipulamos el valor de dicha cookie:

Como vemos, esto desbloquea el menú de acceso al panel de administración web en el frontal:

Finalmente, para borrar el usuario «carlos» debemos acceder al panel de administración. Eso sí, debemos hacerlo utilizando el valor de la cookie «true» en todas las peticiones, dado que en caso contrario no nos permitirá realizar la operación.

Lab4 (Apprentice) – User role can be modified in user profile

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «Solve the lab by accessing the admin panel and using it to delete the user carlos.». En este laboratorio, por tanto, debemos acceder al panel de administración manipulando nuestro rol y eliminar al usuario «carlos».

Del mismo modo que en laboratorios anteriores, lo primero que se hace es mapear el funcionamiento de la aplicación, accediendo a los menús de manera normal para ello. Si nos fijamos, la única funcionalidad interesante es el cambio de correo electrónico del usuario. Procedemos a hacer un cambio normal, visualizando los parámetros de entrada y la respuesta del servidor:

Tal como se puede observar, existe un parámetro «roleid» cuyo valor es «1». En la petición, los parámetros «username», «apikey» y «roleid» no se incluyen. Sin embargo, podemos intentar reenviar la petición incluyéndolos como parte del cuerpo de la misma. Esto es lo que se conoce como «Mass Assignment», que consiste en incluir parámetros que la aplicación no espera a priori para ver cómo reacciona.

Tal como vemos, hemos cambiado el rol del usuario de «1» a «2». Como nos indica en el laboratorio, el rol 2 dispone de acceso de administración. Y, efectivamente, refrescando el frontal web ya vemos que el usuario «wiener» tiene acceso al panel de administración y puede borrar el usuario «carlos», por lo que… ¡¡Laboratorio resuelto!!

Lab5 (Practicioner) – URL-based access control can be circumvented

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, access the admin panel and delete the user carlos.». En este laboratorio, por tanto, debemos acceder al panel de administración y eliminar al usuario «carlos».

Dado que el propio laboratorio ya nos indica que la aplicación web soporta la cabecera «X-Original-URL», estamos ante un bypass en el que muy probablemente hay una regla de bloqueo para acceder a «/admin» que puede ser evadida con dicha cabecera. Intentamos, por tanto, acceder de manera directa a «/admin».

Vemos que, efectivamente, acceso denegado. Vamos a utilizar, por tanto, la cabecera en cuestión. Dado que muy probablemente el acceso a «/admin» se encuentra protegido, debemos lanzar una petición a cualquier otro recurso no protegido y que sea la aplicación quien reescriba la URL como «/admin». Fíjate en la siguiente petición interceptada:

El resultado es que la URL se reescribe a nivel de aplicación y nos proporciona acceso al panel de administración, tal como se puede ver:

Si intentamos borrar el usuario «carlos», vemos de nuevo un error de acceso denegado. Esto es esperable, puesto que la funcionalidad de administración esta limitada. Evaluamos de nuevo la petición:

Finalmente, podemos hacer de nuevo bypass de la autorización sin más que volver a incluir la cabecera X-Original-URL, en este caso con el valor del recurso utilizado para borrar el usuario. Eso sí, debemos incluir el parámetro en la propia URL original, de modo que la aplicación «redirija» al recurso de borrado incluyendo ese parámetro también, tal como puedes ver:

Con la petición anterior, borramos el usuario «carlos» y solucionamos el laboratorio.

Lab6 (Practicioner) – Method-based access control can be circumvented

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.». En este laboratorio, por tanto, debemos acceder al panel de administración manipulando nuestro rol y eliminar al usuario «carlos».

Tal como se indica en la descripción del laboratorio, lo primero que debemos hacer es familiarizarnos con la funcionalidad de «upgrade» y «downgrade» de usuarios. Como podemos ver, tenemos una funcionalidad simple vía POST que realiza esta función:

Teniendo ahora al usuario «wiener» como usuario normal, accedemos a la web con sus credenciales «wiener:peter» e intentamos reproducir ese mismo POST para auto-elevar nuestro rol. Sin embargo, se produce un error lógico porque no tenemos permisos para ello:

Vamos ahora con un pequeño truco. Para cambiar el método, haremos botón derecho en la petición que tenemos capturada en el Repeater y click en «Change request method». Como vemos, se convierte el POST en un GET y los parámetros se añaden en el recurso solicitado. Si lanzamos dicha petición, vemos que tiene éxito dado que solo se comprobaba el nivel de acceso en peticiones POST:

Y… Con esto… Laboratorio finalizado.

Lab7 (Apprentice) – User ID controlled by request parameter

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, obtain the API key for the user carlos and submit it as the solution.». En este laboratorio, por tanto, debemos obtener la API key del usuario «carlos».

Comenzamos accediendo con nuestro propio usuario «wiener:peter» y visualizando la pestaña de «my-account». Como vemos, podemos visualizar a través de ella la API Key propia.

Tal como podemos ver, existe un parámetro denominado «id» que parece obtener los datos asociados al usuario incluido como valor. Si cambiamos «wiener» por «carlos», estaremos accediendo a los datos de este último usuario y, por tanto, resolviendo el laboratorio:

Lab8 (Apprentice) – User ID controlled by request parameter, with unpredictable user IDs

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, find the GUID for carlos, then submit his API key as the solution.». En este laboratorio, por tanto, debemos obtener la API key del usuario «carlos», obteniendo previamente su GUID.

Como vemos si navegamos por el blog, cada autor tiene sus posts asociados a través de un GUID. Este GUID es público si hacemos click encima del propio nombre de usuario. Localizamos un post escrito por «carlos» y, por tanto, su GUID:

Toda vez que tenemos el GUID, seguimos el mismo procedimiento que para el laboratorio anterior, accediendo a sus datos mediante la manipulación del parámetro «id».

Lab9 (Apprentice) – User ID controlled by request parameter with data leakage in redirect

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, obtain the API key for the user carlos and submit it as the solution.». En este laboratorio, por tanto, debemos obtener la API key del usuario «carlos».

Al igual que en casos anteriores, retransmitiremos la petición para la obtención de datos, manipulando el «id» y cambiándolo de «wiener» a «carlos». Fíjate cómo aunque la aplicación nos redirige al login de nuevo, en esa respuesta tras invalidar la sesión se divulga igualmente la información del usuario «carlos». Por ello, debemos analizar siempre las aplicaciones con Burp Suite Professional además de visualizando el frontal, dado que a priori solo visualizando el frontal podría darnos la sensación de que todo es correcto cuando no lo es:

Lab10 (Apprentice) – User ID controlled by request parameter with password disclosure

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, retrieve the administrator’s password, then use it to delete the user carlos.». En este laboratorio, por tanto, debemos obtener la clave de acceso como administrador para borrar al usuario «carlos».

Para resolver el laboratorio, accedemos en primer lugar como el usuario «wiener» con la contraseña «peter». Vemos que en el panel mostrado en «my-account» nos permite cambiar la contraseña, teniendo una prefijada. Analizando la respuesta HTML vemos que dicha contraseña es nuestra contraseña de acceso:

Manipulando de nuevo la petición, podemos acceder ahora a la contraseña del usuario «administrator».

Y, finalmente, con dicha contraseña podemos acceder a la web y borrar el usuario «carlos».

Lab11 (Apprentice) – Insecure direct object references

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «Solve the lab by finding the password for the user carlos, and logging into their account.». En este laboratorio, por tanto, debemos obtener la clave de acceso de «carlos».

Como podemos ver, la web ahora tiene un chat en vivo que utiliza tecnología WebSockets para comunicarse con un supuesto agente virtual. Podemos probar a enviar y recibir mensajes, visualizando en Burp Suite Professional que toda la comunicación se realiza en WebSockets:

Lo relevante de esta aplicación web es la opción de ver la transcripción del chat que proporciona. Si se hace click en ella, se puede observar la petición realizada:

Hemos remarcado el nombre de fichero porque es «2.txt». Parece, por tanto, que las transcripciones se almacenan en ficheros con números correlativos. Por tanto, podemos explotar el IDOR y obtener los datos del fichero «1.txt», estando en ellos la contraseña del usuario «carlos», tal como podemos ver:

Finalmente, con dicha contraseña accedemos a la web como «carlos» para resolver el laboratorio, tal como nos indicaban.

Lab12 (Practicioner) – Multi-step process with no access control on one step

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.». En este laboratorio, por tanto, debemos escalar nuestros privilegios verticalmente.

Para comenzar, evaluamos cómo se realiza el cambio de rol a través del usuario «administrator:admin» que nos proporcionan. Como podemos ver, el proceso de elevación de privilegios del usuario se hace en dos peticiones separadas:

Tal como se puede apreciar, la primera petición es lanzada a través del formulario presente en el frontal web y puede parecer que es la que realiza la acción a nivel de backend. Sin embargo, es la segunda petición la que, tras confirmar los cambios, realiza dichos cambios. Probamos ahora a hacer estos pasos desde el usuario «wiener», intentando escalar sus privilegios. Primero de todo, intentaremos reproducir el primer paso:

Como vemos, obtenemos un error de acceso. Esto es lo esperable, puesto que el usuario no debería poder escalar sus propios privilegios. Sin embargo, vamos a probar también con la segunda petición, dado que es la que en realidad produce los cambios a nivel de backend:

En este caso, como vemos, la petición tiene éxito ya que el patrón de la respuesta es idéntico a cuando lo hacemos con «administrator». Por tanto, hemos resuelto el laboratorio.

Lab13 (Practicioner) – Referer-based access control

Lo primero de todo, lanzamos el laboratorio y configuramos en la pestaña «Scope» para que solamente se capturen peticiones a dicha web, ya que es la que tenemos bajo alcance. Esto es muy recomendable siempre en auditorías reales, pues se eliminará todo el ruido del navegador y nos centraremos solo en lo realmente importante: el alcance de la auditoría.

En segundo lugar, tomemos como referencia el objetivo que nos proponen: «To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.». En este laboratorio, por tanto, debemos escalar nuestros privilegios verticalmente.

Comenzamos, de nuevo, evaluando el proceso con las credenciales de «administrator:admin» proporcionadas. A priori, el proceso no tiene grandes complicaciones y se hace en una sola petición enviada al backend. Sin embargo, vemos que se añade la cabecera Referer a la petición. Al quitarla, esta funcionalidad ya no tiene éxito, por lo que se presume totalmente necesaria:

Repetimos el procedimiento, por tanto, con el usuario «wiener». Eso sí, lógicamente, retransmitiremos la petición con la cabecera Referer bien implementada en la petición:

Y, con esto… Damos por finalizados todos los laboratorios de control de acceso.

~km0xu95