A01:2021 – Broken Access Control

14 de octubre de 2024 Gustavo Genez

El control de acceso en una web define si un usuario tiene permitido acceder a determinado recurso o realizar determinada acción. Este control puede ocurrir de manera horizontal y vertical:

Control de acceso vertical: Un usuario sin privilegios no podría acceder a los recursos de un usuario administrador.

Control de acceso horizontal: Un usuario, por ejemplo, en una web bancaria, puede acceder a sus tarjetas y cuentas, pero no a la de los demás usuarios.

¿Cómo se pierde este control de acceso?

Para que este control funcione correctamente, las medidas de seguridad deben estar bien implementadas, y este no es siempre el caso. Malas configuraciones, versiones vulnerables de software o un mal diseño de la seguridad puede resultar en un control de acceso deficiente, vulnerando así la confidencialidad, integridad y disponibilidad de la información.

Al igual que clasificamos el control de acceso en vertical o horizontal, estas vulnerabilidades pueden resultar en un escalado de privilegios vertical o un movimiento horizontal.

Escalado de privilegios vertical

El escalado vertical de privilegios ocurre cuando un atacante explota una vulnerabilidad para elevar su nivel de acceso, pasando de un usuario con privilegios bajos (como un usuario estándar) a un rol con más privilegios, como administrador. En otras palabras, se obtiene control sobre funcionalidades o datos que deberían estar reservados solo para usuarios con niveles de acceso superiores, comprometiendo la seguridad de la aplicación. Estos son algunos ejemplos de escalado de privilegios:

Acceso no autorizado al panel de administración.

Modificación del rol de un usuario de la plataforma.

Acceso a funcionalidades de administrador (borrar un usuario, modificar la contraseña de un usuario…).

Movimiento horizontal

El movimiento horizontal ocurre cuando un atacante con acceso a una cuenta de usuario del sistema obtiene acceso a otras cuentas de usuario de similares privilegios. Este movimiento horizontal se da tanto si consigue acceder directamente a una cuenta de usuario como si es capaz de acceder a funcionalidades o datos de dicho usuario no privilegiado.

A diferencia del movimiento vertical, donde el atacante obtiene mayores permisos dentro del sistema, el movimiento horizontal se enfoca en comprometer otras cuentas no privilegiadas para descubrir nuevos vectores de ataque en la aplicación. Algunos ejemplos de este movimiento horizontal son:

Descubrimiento de las credenciales de otro usuario del sistema.

Un control de acceso al perfil de usuario basado en un ID predecible.

Acceso a archivos propiedad de otros usuarios del sistema.

De escalado horizontal a escalado vertical

Si bien es cierto que distinguimos estos dos tipos de movimiento, son comunes los casos de movimiento horizontal que derivan en un escalado vertical de privilegios. Esto se da cuando un atacante a través de técnicas de movimiento horizontal logra acceder a un usuario del sistema con privilegios de administración. Por ejemplo, si un atacante cambia el ID de usuario en la URL para acceder al perfil de otro usuario, estaría realizando un movimiento horizontal. Sin embargo, mediante esta técnica termina accediendo a un usuario administrador de la página web.

De esta manera observamos que no es tan sencillo discernir entre qué es un escalado de privilegios y qué un movimiento horizontal, dado que no depende tanto de la técnica o ataque realizado, sino en el resultado obtenido una vez realizado dicho ataque.

Vulnerabilidades de control de acceso

Como hemos explicado en el apartado anterior, debido a la dificultad de clasificar los ataques entre ataques de escalado de privilegios y ataques de movimiento horizontal, en este apartado nos ceñiremos a explicar distintos ataques, como realizarlos y el resultado que se puede obtener.

IDOR (Insecure Direct Object Reference)

IDOR es una subcategoría de control de acceso, donde se utilizan parámetros modificables por el usuario para acceder a recursos. Un ejemplo sería un botón en el perfil de usuario para descargar el histórico de chats.

Este botón realiza una petición a un archivo ejemplo.txt, pero este parámetro es modificable mediante un proxy, por lo que se puede llegar a acceder a los históricos de chats de otros usuarios.

En este ejemplo, al intentar descargar el histórico de chats de nuestro usuario, al interceptar la petición con un proxy, vemos que realiza una consulta a un archivo 2.txt. Tras esta petición GET obtenemos la siguiente respuesta:

Sin embargo, este parámetro es modificable, por lo que si reemplazamos este 2.txt por 1.txt obtenemos el histórico de chats de otro usuario, en el cuál podemos encontrar su contraseña:

Funcionalidad no protegida

Este es un ataque es muy sencillo y requiere de una falta casi absoluta de control de acceso por parte del servidor. Es posible encontrar páginas web donde los recursos de un administrador estén ocultos, pero no protegidos. En ese caso, podemos encontrar estos recursos de distintas maneras:

Un método es acceder al archivo robots.txt. Este archivo suele estar disponible en la raíz de la página web y contiene información sobre qué recursos y directorios tienen permitido recorrer los bots de Google, Microsoft… Muchas veces podemos encontrarnos con directorios ocultos o de administración bajo la etiqueta Disallow, revelando así la localización de paneles de administración o archivos sensibles:
Otra fuente para encontrar este tipo de directorios ocultos es el propio código JavaScript. Es común encontrar referencias a archivos y directorios sensibles en funciones de este lenguaje de programación, como observamos en la siguiente imagen:

De nuevo, pese a la relevancia de la información que podemos encontrar en estas fuentes, si queremos acceder a dichos directorios y recursos como un usuario sin privilegios, la ausencia de control de acceso es indispensable.

Control de acceso basado en parámetros

Existen otros casos en los que los permisos de un usuario se basan en valores almacenados que el usuario puede modificar, como un campo oculto, una cookie o un valor predefinido la hacer las consultas.

En este ejemplo, los permisos del usuario están en manos del propio usuario, ya que se utiliza una cookie almacenada en el navegador con valor false. Tan solo modificando el valor de dicha cookie podemos acceder a recursos sensibles sin necesidad de un usuario administrador:

Podemos ver otro caso en el siguiente ejemplo. Al realizar un cambio de email con nuestro usuario, si interceptamos con un proxy la petición realizada y la respuesta obtenida, observamos que en la petición POST, estamos enviando nuestro email nuevo en formato JSON y recibimos la siguiente información, también, en formato JSON:

Como se presenta en la imagen superior, al hacer el cambio de email recibimos en el JSON de respuesta un parámetro roleid con valor 1. Si al hacer la petición, en lugar de enviar únicamente el email enviamos también un parámetro roleid con valor 2, vemos que el servidor nos devuelve dicho valor, indicando que los privilegios de nuestro usuario han cambiado:

De esta manera, enviando al servidor un parámetro que no esperaba, conseguimos alterar los privilegios de nuestro usuario, convirtiéndolo en un usuario privilegiado.

Mala configuración

En casos de mala configuración, es posible encontrarse con webs que restringen las peticiones en base a la URL, por ejemplo, para que un usuario no tenga permitido hacer un POST a la URL /admin/delete. Sin embargo, si esta misma web permite utilizar cabeceras de reescritura de URL como X-Original-URL o X-Rewrite-URL podemos saltar estos controles de seguridad.

Como vemos en este caso, tenemos restringido acceder a la URL /admin/delete?username=carlos, que nos permitiría borrar el usuario carlos. Pero al introducir la URL raíz de la página, utilizando la cabecera X-Original-URL para reescribir dicha URL, vemos que somo capaces de saltarnos este control de acceso a esa URL:

En otros casos, si la página es flexible en cuanto a los métodos que procesa, si está restringido por método y URL, podemos cambiar el método para y saltar así el control de acceso. En este ejemplo, al intentar cambiar los permisos del usuario carlos con un usuario sin privilegios, vemos que no tenemos autorización para hacer dicha modificación:

Sin embargo, debido a la flexibilidad de la página web, podemos hacer esta misma petición en formato GET, el servidor la procesa correctamente pero no aplica el control de acceso, por lo que conseguimos saltar el control de seguridad:

Discrepancias en la concordancia de URL

Existen también páginas que restringen el acceso a determinadas URL mediante cadenas de caracteres, pero luego internamente mapean resultados “parecidos” a esa misma URL.

Por ejemplo, al escribir una URL en mayúsculas como /ADMIN/DELETEUSER redirige internamente a /admin/deleteuser, pero, al no ser exactamente la misma cadena de caracteres, no aplica el control de acceso. En Spring, por ejemplo, al introducir una URL para acceder a un archivo (que tenga extensión), en caso de no encontrar dicho archivo, resuelve a ese mismo recurso, pero sin la extensión, lo que puede llevar a un bypass del control de acceso:

/admin/deleteUser.anything → /admin/deleteUser

Cabe destacar, que esta redirección está habilitada por defecto en versiones de Spring anteriores a la versión 5.3.

Proceso de múltiples pasos sin control de acceso

Cuando hay más de una petición o más de un paso para realizar determinada acción, como borrar un usuario, es posible que una de las peticiones sí que esté correctamente asegurada mientras que el segundo o tercer pasos son vulnerables.

En este ejemplo vemos claramente este proceso múltiple para elevar los privilegios de un usuario. Al realizar la petición inicial de cambio de privilegios con un usuario no privilegiado, obtenemos la siguiente respuesta del servidor indicando que no tenemos permiso para realizar esa acción:

Sin embargo, si continuásemos con el proceso de elevación de privilegios con un usuario privilegiado, veríamos una página de confirmación preguntando si estamos seguros de que queremos realizar esa acción.

Si interceptamos esta petición y tratamos de hacer esa misma petición con la cookie del usuario sin privilegios, vemos que nos permite realizar esta acción, saltando el control de seguridad:

Es importante tener en cuenta, que muchas veces necesitamos un conocimiento previo de cuáles son las funcionalidades de un usuario administrador para poder realizar este tipo de ataques. En este caso, como usuario normal no deberíamos de poder acceder nunca a esta página de confirmación, ya que nos bloquearía el proceso desde el principio.

Estas vulnerabilidades son mucho más fáciles de detectar si se posee un usuario administrador de antemano para analizar sus funciones. Por ese motivo, en auditorías web muchas veces es esencial poseer tanto un usuario sin privilegios como uno con privilegios.

Control de acceso basado en la cabecera Referer

A veces, para limitar el acceso a subpáginas como /admin/deleteUser, se comprueba que la cabecera Referer contenga la URL principal /admin. De esta manera, el servidor intenta comprobar que el usuario proviene de un directorio exclusivo de un usuario con privilegios elevados. Sin embargo, al ser esta modificable por el usuario, puede llevar a un salto de este control de acceso.

En el siguiente caso, vemos exactamente eso. Al indicar en el Referer que la petición se hace viniendo previamente de la URL /admin (aunque no sea cierto), el sistema permite realizar una modificación de permisos de usuario utilizando una cookie de usuario no privilegiado, ya que el servidor web solo está comprobando la cabecera Referer:

Ejemplos simples de movimiento horizontal

Para finalizar, presentamos algunas técnicas sencillas de movimiento horizontal. Un caso muy recurrente suele ser el acceso al perfil de usuario a través de un identificador en la propia URL. Tan solo cambiando dicho identificador podemos acceder a perfiles de otros usuarios:

Para evitar esto, es usual la aleatoriedad de estos identificadores para que no sean adivinables. Pero de vez en cuando es posible encontrar referencias a este identificador en algún lugar en la página web.

En este ejemplo, navegando a un blog publicado por carlos, podemos observar que su identificador de usuario se encuentra en la propia URL del blog:

Otro caso bastante común es encontrar información en las redirecciones. Cuando no podemos acceder a un recurso, como el panel de administrador, el servidor nos devuelve un código 302 para redirigirnos, por ejemplo, de vuelta a la raíz de la página. Sin embargo, hay veces que, si interceptamos la respuesta del servidor, podemos encontrar en el cuerpo de la propia respuesta de redirección todo el código HTML del recurso al que queríamos acceder:

Remediación

Todos estos ataques son posibles debido a un deficiente control de acceso por parte de la página web. Por ese motivo, se recomienda seguir los siguientes principios a la hora de implementar un correcto control de acceso:

No confiar únicamente en la ofuscación para el control de acceso.

A menos que un recurso esté destinado a ser de acceso público, denegar por defecto el acceso a dicho recurso.

De ser posible, utilizar un único mecanismo de control de acceso para toda la aplicación.

A nivel de código, declarar el acceso permitido a cada recurso y denegar el acceso por defecto.

Auditar y probar minuciosamente los controles de acceso para asegurarse de que funcionan según lo previsto.

Egoitz San Martín, Pentester en Grupo Zerolynx