A lo largo de este post intentaré explicaros este tipo de vulnerabilidad y enseñaros con un ejemplo sencillo cómo funciona. Se tratarán los aspectos necesarios para comenzar a investigar por vosotros mismos más a fondo.
Para entender qué es BROKEN ACCESS CONTROL (en adelante, BAC), debemos primero comprender qué es un control de acceso.
El control de acceso (Access Control) es un mecanismo en el que se especifica qué información, funciones o sistemas serán accesibles para un usuario, grupo o rol en particular. Es decir, es una manera de controlar quién puede acceder a ciertos recursos, generalmente, mediante el uso de políticas para especificar los privilegios de acceso.
En las aplicaciones web, el control de acceso implica usar mecanismos de protección como:
De esto podemos intuir que la vulnerabilidad Broken Access Control ocurre cuando una falla o una ausencia de mecanismos de control de acceso le permite a un usuario acceder a un recurso que está fuera de sus permisos previstos.
Esta vulnerabilidad representa el puesto nº1 en el Top 10 de OWASP. Según esta misma organización, el 94% de las webs testadas tenían alguna forma de BAC.
Debido a la cantidad de errores relacionados con el control de acceso, existen varias vulnerabilidades bajo la categoría de Broken Access Control, algunas de ellas son:
Haré posts sobre estas vulnerabilidades más adelante si estáis interesados.
Para poner un ejemplo llevaremos a cabo el siguiente laboratorio de PortSwigger:
Lab: User role controlled by request parameter
Si se tratase de un escenario real deberíamos de inspeccionar en profundidad todo el sitio web, o al menos todo aquello a lo que podamos acceder (subdominios, rutas, parámetros,...)
Para el ejemplo iremos directamente al grano. Nos loguearemos en la web con las credenciales que nos han proporcionado wiener
eter:
Tras loguearte, deberías ver algo así:
Nos han proporcionado como pista que la web tiene una ruta ‘/admin’ (aunque esto deberíamos haberlo encontrado nosotros, consultar el anexo 1), por lo que nos dirigiremos a ese apartado:
Vemos que no tenemos acceso dado que no somos administradores. En vuestra mente de hacker esto debería de activar vuestro instinto, pues, si nos deniega el acceso es porque de alguna manera tiene que existir en la web un sistema de permisos, al que quizás podamos manipular o engañar.
Investigando la web haciendo uso de BurpSuite, nos encontramos con lo siguiente:
La aplicación guarda una cookie en nuestro navegador que indica si tenemos o no permisos de administrador.
Cambiando el parámetro ‘Admin=false’ por ‘Admin=true’, quizás consigamos engañar al sistema para que nos otorgue privilegios que no está previsto que debamos tener. Por definición, un fallo en el control de acceso (BAC).
Como vemos, hemos podido acceder con privilegios de administrador. Ahora que sabemos que podemos controlar los privilegios a través de esta cookie, podemos automatizar la sustitución que hemos hecho para acceder a todas las partes de la web sin tener que cambiar manualmente esta cookie.
Para ello iremos a Proxy>>Options>>Match and replace y le daremos a ‘Add’.
Rellenaremos con los datos correspondientes, colocando en ‘Match’ el término a reemplazar y en ‘Replace’ el término por el que será reemplazado.
Con esto podremos navegar por la web sin tener que cambiar manualmente la cookie.
Nos dirigiremos a ‘/admin’ y eliminaremos el usuario ‘Carlos’ para dar por finalizado el laboratorio.
Para el caso del post solo utilizaré los parámetros -u (para indicar el target) y -w (para indicar el diccionario):
En unos segundos encontraremos las rutas de la web objetivo. Deberíamos inspeccionar todas ellas.
Si el post os ha gustado y queréis que haga otro detallando mejor esta vulnerabilidad o tratándo otras, hacedlo saber en los comentarios.
Cualquier duda podeis preguntarla e intentaré responderosla de la mejor manera.
Para entender qué es BROKEN ACCESS CONTROL (en adelante, BAC), debemos primero comprender qué es un control de acceso.
El control de acceso (Access Control) es un mecanismo en el que se especifica qué información, funciones o sistemas serán accesibles para un usuario, grupo o rol en particular. Es decir, es una manera de controlar quién puede acceder a ciertos recursos, generalmente, mediante el uso de políticas para especificar los privilegios de acceso.
En las aplicaciones web, el control de acceso implica usar mecanismos de protección como:
- Autenticación (verificar la identidad del usuario)
- Autorización (comprobar si el usuario tiene permiso de acceder a un recurso)
De esto podemos intuir que la vulnerabilidad Broken Access Control ocurre cuando una falla o una ausencia de mecanismos de control de acceso le permite a un usuario acceder a un recurso que está fuera de sus permisos previstos.
Esta vulnerabilidad representa el puesto nº1 en el Top 10 de OWASP. Según esta misma organización, el 94% de las webs testadas tenían alguna forma de BAC.
Debido a la cantidad de errores relacionados con el control de acceso, existen varias vulnerabilidades bajo la categoría de Broken Access Control, algunas de ellas son:
- IDOR (Insecure Direct Object Reference)
- CSRF (Client-Side Request Forgery)
- CORS (Cross-Origin Resource Sharing)
Haré posts sobre estas vulnerabilidades más adelante si estáis interesados.
Para poner un ejemplo llevaremos a cabo el siguiente laboratorio de PortSwigger:
Lab: User role controlled by request parameter
Si se tratase de un escenario real deberíamos de inspeccionar en profundidad todo el sitio web, o al menos todo aquello a lo que podamos acceder (subdominios, rutas, parámetros,...)
Para el ejemplo iremos directamente al grano. Nos loguearemos en la web con las credenciales que nos han proporcionado wiener
eter:
Tras loguearte, deberías ver algo así:
Nos han proporcionado como pista que la web tiene una ruta ‘/admin’ (aunque esto deberíamos haberlo encontrado nosotros, consultar el anexo 1), por lo que nos dirigiremos a ese apartado:
Vemos que no tenemos acceso dado que no somos administradores. En vuestra mente de hacker esto debería de activar vuestro instinto, pues, si nos deniega el acceso es porque de alguna manera tiene que existir en la web un sistema de permisos, al que quizás podamos manipular o engañar.
Investigando la web haciendo uso de BurpSuite, nos encontramos con lo siguiente:
La aplicación guarda una cookie en nuestro navegador que indica si tenemos o no permisos de administrador.
Cambiando el parámetro ‘Admin=false’ por ‘Admin=true’, quizás consigamos engañar al sistema para que nos otorgue privilegios que no está previsto que debamos tener. Por definición, un fallo en el control de acceso (BAC).
Como vemos, hemos podido acceder con privilegios de administrador. Ahora que sabemos que podemos controlar los privilegios a través de esta cookie, podemos automatizar la sustitución que hemos hecho para acceder a todas las partes de la web sin tener que cambiar manualmente esta cookie.
Para ello iremos a Proxy>>Options>>Match and replace y le daremos a ‘Add’.
Rellenaremos con los datos correspondientes, colocando en ‘Match’ el término a reemplazar y en ‘Replace’ el término por el que será reemplazado.
Con esto podremos navegar por la web sin tener que cambiar manualmente la cookie.
Nos dirigiremos a ‘/admin’ y eliminaremos el usuario ‘Carlos’ para dar por finalizado el laboratorio.
Anexo 1.
Una manera de encontrar rutas en una web es a través de fuzzing. Personalmente me gusta usar FeroxBuster. Echandole un ojo a la documentación de esta herramienta comprendereis más a fondo su uso.Para el caso del post solo utilizaré los parámetros -u (para indicar el target) y -w (para indicar el diccionario):
En unos segundos encontraremos las rutas de la web objetivo. Deberíamos inspeccionar todas ellas.
Si el post os ha gustado y queréis que haga otro detallando mejor esta vulnerabilidad o tratándo otras, hacedlo saber en los comentarios.
Cualquier duda podeis preguntarla e intentaré responderosla de la mejor manera.
