Acess Control
PreviousLaboratorio: SSRF básico contra el servidor localNextLaboratorio: funcionalidad de administración desprotegida
Last updated
En esta sección, describimos:
Escalada de privilegios.
Los tipos de vulnerabilidades que pueden surgir con el control de acceso.
Cómo prevenir vulnerabilidades en el control de acceso.
El control de acceso es o son las restricciones que se tiene sobre a que cosas o quien puede acceder a ciertos elementos o interfaces, el control de acceso controla ello, el control de acceso depende de la autenticación y la gestión de sesiones:
La autenticación: Confirma que el usuario es quien dice ser.
La gestión de sesiones: identifica que solicitudes HTTP posteriores hace ese usuario.
El control de acceso: Determina si el usuario puede realizar o no tales acciones, tales como solicitudes HTTP especificas.
Los controles de acceso rotos son comunes y a menudo presentan una vulnerabilidad de seguridad crítica. El diseño y la gestión de controles de acceso es un problema complejo y dinámico que aplica restricciones comerciales, organizativas y legales a una implementación técnica. Las decisiones de diseño del control de acceso deben ser tomadas por humanos, por lo que el potencial de errores es alto.
¿Qué son los modelos de seguridad de control de acceso?
Los modelos de seguridad de control de acceso son independientes de la tecnología de una aplicación web y se implementan en los servidores, sistemas operativos, redes, sistemas de gestión de Bases de Datos. y son un conjunto de reglas definidas de control de acceso para los diferentes entornos de una aplicación web.
Control de acceso programático: Este tipo de control de acceso se basa en una matriz de privilegios a la cual se accede mediante programación, y dentro de ella se almacenan todo tipo de grupos, usuarios, registro y el flujo como tal, ahora bien, esto con el fin de que se controla el acceso especifico para cada persona o grupo dentro de la aplicación, lo que este tipo de modelo de seguridad conlleva es que es muy granular.
Control de acceso discrecional (DAC): Con control de acceso discrecional los accesos están a recursos o funciones están restringidos según el tipo de usuario, o grupos con permisos elevados, cada lider de grupo o que tenga permiso a una funciones o recurso especifico puede otorgar acceso a otro usuario, este tipo de control de acceso resulta ser muy granular en complejidad por ende es un poco complejo de implementar en diseño y gestión.
Control de acceso obligatorio (MAC): Este sistema de control está controlado centralmente y tiene restringido el control a todo tipo de usuario o grupos los cuales a diferencia del sistema DAC que podía dar permisos de acceso a sus recursos o delegarlos en este caso ningún usuario puede delegar permisos ni modificar reglas de acceso, en este caso todos están restringidos al acceso y todo es mediante autorizaciones centrales, tipo a lo militar mamaguevo.
Control de acceso basado en roles (RBAC): Este modelo de control de acceso está basado especificamente en la creación de diferentes roles con permisos especificos y se otorgan los roles a cada tipo de usuario dependiendo de que proposito tienen X usuario dentro de la aplicación, También cabe mencionar que a algunos usuarios se les definen multiples roles dependiendo de las funcionalidades que tengan que ejercer dentro de la aplicación, Este tipo de control y rol otorgado a un usuario o grupo puede ser removido en caso tal de que ya no sean parte más de la aplicación o funcionalidad especifica, esto hace que el modelo sea simplemente eficaz, simple y facil de implementar, sin embargo se debe mantener el nivel para los casos en los que se creen muchos roles no sería muy efectivo, debe ser regulado y equilibrado.
Son los controles de acceso que restringen el acceso valga la redundancia a todo tipo de funciones confidenciales para ciertos tipos de usuarios especificos.
Ahora bien con los controles de acceso vertical se le puede dar a un usuario diferentes funcionalidades dependiendo de la jerarquía de permisos que tenga por ejm: Un Admin puede tener varías funcionalidades como eliminar o modificar a otro usuario, sin embargo un user no podría hacer eso.
Por eso para un user normal se restringe el acceso a las funciones confidenciales de eliminar o modificar un user, sin embargo un Admin si puede modificar o eliminar, esto porque el acceso vertical se aplica diferente dependiendo del tipo de usuario.
Los controles de acceso horizontales son mecanismos que restringen el acceso a recursos a usuarios especificos.
Con controles de acceso horizontal, diferentes usuarios tiene acceso a un subconjunto de funcionalidades o recursos del mismo tipo, Por ejm: una aplicación bancaria permitirá ver las transacciones y realizar pagos desde sus propias cuentas, eso si un usuario no podría hacer esto para la cuenta de otros usuarios solo para la propia, en este caso se aplica la restricción a recursos para cada usuario especifico y a su vez se mantiene el acceso del mismo tipo para muchos usuarios con las mismas caracteristicas.
Las vulnerabilidades de control de acceso roto existen cuando un usuario puede acceder a recursos o realizar acciones que se supone que no debería poder realizar.
Si un usuario puede acceder a recursos o funcionalidades a las cuales no tiene permiso, en ese caso estariamos hablando de una escalada de privilegios vertical, por ejm: un usuario común y corriente que obtiene acceso a la interfaz de administrador y puede eliminar cuentas de usuario, entonces se trata de una escalada de privilegios vertical.
Son esas funciones las cuales se deben restringir y esconder de los usuarios normales, ya que son privadas y contienen caracteristicas mucho más avanzadas y de más acceso a la aplicación, un usuario normal no debe saber porque se puede prestar para malos actos o cosas malas, por ello es mejor prevenir que lamentar.
¿Cuales son algunos ejemplos?
Por ejm una interfaz de admin/ en la misma aplicación para poder modificar/eliminar usuarios de la misma aplicación, esto se consideraría una funcionalidad confidencial la cual debe ser restringida para ciertos tipos de usuarios especificos, y solo los usuarios con permisos pueden acceder a ella.
En su forma más basica una funcionalidad desprotegida para una escalada de privilegios vertical ocurre cuando una aplicación no protege adecuadamente las funcionalidades confidenciales que tiene o no aplica las protecciones adecuadas.
Por ejm: la interfaz de administrador se supone debería estar accesible desde la pagina de bienvenida de administrador, sin embargo muchas veces está accesible es desde la pagina de bienvenida de User normal, lo cual no está bien, se supone debería estar separada la interfaz admin/ de usernormal.
Por ejemplo, un sitio web puede alojar funciones confidenciales en la siguiente URL:
Cualquier usuario puede acceder a esto, no solo los usuarios administrativos que tienen un enlace a la funcionalidad en su interfaz de usuario. En algunos casos, la URL administrativa puede revelarse en otras ubicaciones, como el robots.txtarchivo:
Incluso si la URL no se divulga en ninguna parte, un atacante puede usar una lista de palabras para forzar la ubicación de la funcionalidad confidencial y a esto se llama FUZZING.
Los controles de acceso dependientes del contexto restringen el acceso a los recursos o funcionalidades al usuario según el estado de la aplicación o la interación del usuario con la misma, en este caso si un usuario hace algo que no debía hacer su acceso queda restringido.
Los controles de acceso dependientes del contexto restringen e impiden que un usuario realice acciones en el orden incorrecto, EJM: un usuario desde una pagina minorista de compras facilmente la aplicación puede restringir a un usuario que intenta realizar una accion en el orden incorrecto como puede intentar modificar los productos del carrito de compras cuando ya compró y pagó los productos del carrito de compras.
Este es un concepto en el hacking el cual trata de volver las cosas de forma mucho más impredecible añadiendo elementos impredecibles u “oscuros” dificiles de acertar o adivinar por un hacker o atacante, por ejm para el caso de lo que estamos viendo:
Una pagina que intenta ocultar las funciones confidenciales de la misma, en este caso la url del panel de admin mediante una URL con un nombre de interfaz impredecible, asi →
https://insecure-website.com/administrator-panel-yb556
Este concepto ya lo tenía en la cabeza pero referente a criptografía, lo que hablaba el profe Jorge Ramios.
Entonces con la URL es posible que un atacante o hacker no pueda adivinar directamente la url eso es cierto, sin embargo es posible que la aplicación aún filtre la URL a los usuarios, además la URL puede divulgarse en JavaScript que construye la interfaz de usuario según la función del usuario.
Aqui vemos como se construye un enlace simbolico para un usuario si ese usuario es usuario de tipo Administrador, el problema recae en que la URL “Impredecible” de la interfaz de admin se divulga en el mismo Script de JS para todos.
Algunas aplicaciones determinan los derechos de acceso o la función del usuario al iniciar sesión y luego almacenan está información en una ubicación controlable por el usuario. Esto podría ser:
Un campo escondido, puede ser dentro del mismo codigo HTML de la aplicación.
O puede ser una cookie, la cual puede ser modificada.
O un parametro de consulta preestablecido en la URL de la pagina, que facilmente puede ser modificable.
Veamos un ejemplo →
La aplicación toma decisiones de control de acceso en función del valor enviado en el parametro preestablecido en la URL:
https://insecure-website.com/login/home.jsp?**admin**=true
https://insecure-website.com/login/home.jsp?**role**=1
Este enfoque claramente es inseguro porque un atacante puede facilmente modificar los valores de los parametros y acceder a funciones las cuales no está autorizado, como funciones administrativas.
Algunas aplicaciones imponen controles de acceso en la capa de plataforma, lo hacen restringiendo el acceso a URL’s especificas y métodos HTTP según la función del usuario.
Por ejm una aplicación podría configurar una Regla de restricción de la siguiente manera:
Esta regla niega el acceso al POSTmétodo en la URL /admin/deleteUsera los usuarios del grupo de administradores. En esta situación, varias cosas pueden salir mal y provocar omisiones en el control de acceso.
Esto porque algunas aplicaciones permiten varios marcos de encabezados HTTP no estándar que se pueden utilizar para omitir o anular las URL’s en la solicitud original como pueden ser los encabezados: X-Original-URLy X-Rewrite-URL Pero si un sitio web utiliza controles frontales rigurosos para restringir el acceso según la URL, pero la aplicación permite que la URL se anule mediante un encabezado de solicitud, entonces es posible omitir los controles de acceso mediante una solicitud como la siguiente:
React, Django, Express JS, Ruby on Rails y Laravel son marcos de desarrollo web de uso común.
Las aplicaciones pueden ser facilmente eludidas, hay aplicaciones que permiten diferentes métodos de solicitudes HTTP en la plataforma, y los controles de restricción de frontend que vimos anteriormente pueden ser eludidos usando estos metodos, por ejm una URL que está restringida por el control de acceso si un atacante puede lograr hacer diferentes metodos GET o POST en la aplicación, puede eludir el control de acceso que se implementa en la capa de la plataforma.
Vamos a ver un LAB para entender bien el concepto y entender como podemos eludir el control de acceso a la URL o URL’s.
Los sitios web pueden variar en cuanto a cuán estrictamente coinciden con la ruta de una solicitud entrante a un punto final definido. Por ejemplo, pueden tolerar mayúsculas inconsistentes, por lo que una solicitud /ADMIN/DELETEUSERaún puede asignarse al /admin/deleteUserpunto final. Si el mecanismo de control de acceso es menos tolerante, puede tratarlos como dos puntos finales diferentes y, como resultado, no aplicar las restricciones correctas.
Pueden surgir discrepancias similares si los desarrolladores que utilizan el marco Spring han habilitado la useSuffixPatternMatch opción. Esto permite asignar rutas con una extensión de archivo arbitraria a un punto final equivalente sin extensión de archivo. En otras palabras, una solicitud /admin/deleteUser.anything seguiría coincidiendo con el /admin/deleteUser patrón. Antes de Spring 5.3, esta opción estaba habilitada de forma predeterminada. Ahora en otros sistemas, puede encontrar discrepancias sobre si /admin/deleteUser y /admin/deleteUser/ se tratan como puntos finales distintos. En este caso, es posible que pueda evitar los controles de acceso agregando una barra diagonal a la ruta.
Esta escalada de privilegios nos permite poder acceder a recursos los cuales son propiedad de otros usuarios y no de nosotros, a diferencia de la escalada de privilegios vertical que accede es a funciones confidenciales con usuarios que no tienen permitido el acceso.
Por ejemplo, si un empleado puede acceder a los registros de otros empleados además de a los suyos propios, entonces se trata de una escalada de privilegios horizontal.
Los ataques de escalada de privilegios horizontales pueden utilizar tipos de métodos de explotación similares a los de la escalada de privilegios vertical. Por ejemplo, un usuario podría acceder a la página de su propia cuenta utilizando la siguiente URL:
Si un atacante modifica el idvalor del parámetro por el de otro usuario, podría obtener acceso a la página de la cuenta de otro usuario y a los datos y funciones asociados.
El IDOR es un tipo de vulnerabilidad que ocurre cuando una aplicación le permite a un usuario acceder directamente a objetos (como recursos, funciones o archivos) en función de la consulta que éste realice, sin realizar el debido control de acceso.
Un sitio web utiliza la siguiente URL para acceder a una página con información de un usuario:
El número de usuario (el valor del parámetro user_id) se utiliza directamente como índice de registro en las consultas que se realizan en la base de datos.
Si no se implementa un control de acceso, un atacante puede simplemente modificar el valor del número de usuario desde la URL y ver la información personal de otros usuarios.
Una aplicación mobile utiliza el siguiente endpoint de su API para modificar la contraseña de la cuenta del usuario, actualizando la información de una base de datos en el back-end:
Si no se implementa algún un control de acceso, un atacante puede simplemente modificar el valor del parámetro user_id dentro del cuerpo de la solicitud POST para modificar la contraseña de otro usuario.
También, si el atacante cambiara la contraseña de una cuenta administrativa (o cualquier otra con altos privilegios), podría realizar un movimiento vertical de privilegios. Debido a que accede a una función confidencial la cual es administrador.
Supongamos que una empresa de transporte genera certificados de emisión de boletos referidos a sus clientes, los cuales tienen información personal de los mismos.
Sin embargo, los archivos se guardan usando un nombre de archivo incremental, por lo que los clientes acceden a su certificado visitando una URL como la siguiente:
En este escenario, un atacante puede simplemente modificar el nombre del archivo para acceder a certificados de otros usuarios y obtener su información personal.
El problema con esto recae en que no valida nada, solo toma el User ID de la pagina y lo almacena para procesarlo, no se valida ni se confirma el ID con algun Token o cookie de sessión, esto hace que sea vulnerable al IDOR siendo facilmente manipulable el ID de user por otro diferente pudiendo acceder a otros recursos de otro users.
En el inicio de sesión debes implementar un sistema de cookies y crear las variables de la sesión. En este caso, especificando la siguiente variable:
Luego, se debe cambiar el elemento afectado por la vulnerabilidad, cambiando el origen del parámetro para que no lo tome de una entrada proveniente del usuario, sino que recupere el valor del parámetro de la sesión actual.
Aqui ya estamos procesando el ID de user con la cookie unica generada para ese ID unico en especifico, por lo cual si se modifica el ID no coincidirá con la Cookie de sessión original que había sido creada en un principio.
Los JWT tienen la característica de poder estar firmados digitalmente, con el fin de verificar la integridad de la información contenida en los mismos.
Por ejemplo, si se implementan JWT para administrar las sesiones de esta API, se utilizaría un código similar a este:
Resultando en una cadena de caracteres que conforman el JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MTExLCJleHAiOjE2MjE4OTE2NDZ9.Uzv_kQpY649Rvdm96iPWNEaJ457jbIHanVtVF4V6jcM
Ahora bien, debe implementarse en la autenticación de la API y utilizarse como token de sesión. Luego, debe modificarse el elemento con código vulnerable para que utilice el valor suministrado por el JWT. Entonces, el código quedaría similar a lo siguiente:
Vamos a ver un lab para entender bien el concepto de IDOR y la escalada de privilegios Horizontal:
⚠️ Nota
Este es un ejemplo de una vulnerabilidad de referencia directa a objetos (IDOR) insegura. Este tipo de vulnerabilidad surge cuando los valores de los parámetros del controlador de usuario se utilizan para acceder a recursos o funciones directamente.
En algunas aplicaciones, el parámetro explotable no tiene un valor predecible. Por ejemplo, en lugar de un número creciente, una aplicación podría utilizar identificadores únicos globalmente (GUID) para identificar a los usuarios. Esto puede impedir que un atacante adivine o prediga el identificador de otro usuario. Sin embargo, los GUID que pertenecen a otros usuarios pueden revelarse en otras partes de la aplicación donde se hace referencia a los usuarios, como mensajes o reseñas de usuarios.
Con esto en mente, podemos intentar ver y descubrir en el siguiente LAB el GUID del user que nos pida el lab:
A menudo un ataque mediante una escalada de privilegios Horizontal se puede llegar a convertir en una escalada de privilegios Vertical, esto porque cuando un atacante lograr acceder al recurso de password de un usuario o logra restablecerla ahi sabemos que accedemos a un recurso, pero si ese usuario llegase a tener permisos de super usuario o fuese administrador, ya estariamos cambiando a una escalada vertical de privilegios ya que estariamos accediendo a funciones confidenciales las cuales se suponen no son accesibles para todo tipo de usuario.
Un atacante podría obtener acceso a la página de la cuenta de otro usuario utilizando la técnica de manipulación de parámetros ya descrita para la escalada de privilegios horizontal:
Si el usuario objetivo es un administrador de aplicaciones, el atacante obtendrá acceso a una página de cuenta administrativa. Esta página puede revelar la contraseña del administrador o proporcionar un medio para cambiarla, o puede proporcionar acceso directo a una funcionalidad privilegiada.
Vamos a ver un laboratorio de PoC:
Las referencias directas a objetos inseguras, son un tipo de vulnerabilidad de control de acceso que surge cuando una aplicación utiliza entradas que son proporcionadas por el usuario, me explico por ejm: una url que mantiene un ?id=9083 con un numero de 4 digitos en ese caso esa es una entrada que es proporcionada por el user porque dependiendo del user ese numero cambiará por otro, y por ello es que por ahí se puede iniciar un ataque ya que facilmente un user puede llegar a cambiar el ID de user por otros digitos diferentes que sean de un user de tipo admin.
El término IDOR se popularizó por su aparición en el Top Ten de OWASP 2007. Sin embargo, es sólo un ejemplo de muchos errores en la implementación del control de acceso que pueden llevar a que se eludan los controles de acceso .
Las vulnerabilidades de IDOR se asocian más comúnmente con la escalada de privilegios horizontal, pero también pueden surgir en relación con la escalada de privilegios vertical.
Hay muchos ejemplos de vulnerabilidades de control de acceso en las que se utilizan valores de parámetros controlados por el usuario para acceder a recursos o funciones directamente.
Considere un sitio web que utiliza la siguiente URL para acceder a la página de la cuenta del cliente, recuperando información de la base de datos back-end:
Aqui por ejm vemos que la pagina usa una URL con un customer_number=132355 fque es el indice de registro directo que se indexa para la busqueda directa en la base de datos del backend, para este caso concreto podemos darnos cuenta como tan solo con cambiar el numero de indice del customer_number por otro podríamos estar accediendo a otro registro de la cuenta de otro cliente, y en ese caso ya estaríamos aplicando una escalada de privilegios horizontal evitando los controles de acceso.
Y otro caso significativo podría ser que nosotros cambiasemos al usuario por otro usuario con privilegios y en ese caso ya estaríamos creando una escalada de privilegios tanto horizontal como vertical, otras explotaciones podrían ser explotar la filtración de contraseñas o modificar parametros una vez que uno como atacante haya llegado a la paginas de las cuentas de usuario.
Las vulnerabilidades de IDOR a menudo surgen cuando los recursos confidenciales se encuentran en archivos estáticos en el sistema de archivos del lado del servidor. Por ejemplo, un sitio web puede guardar las transcripciones de mensajes de chat en el disco usando un nombre de archivo incremental y permitir a los usuarios recuperarlas visitando una URL como la siguiente:
En esta situación, un atacante puede simplemente modificar el nombre del archivo para recuperar una transcripción creada por otro usuario y potencialmente obtener credenciales de usuario y otros datos confidenciales.
Muchas aplicaciones implementan procesos seguidos unos de otros que son fundamentales para lo que se quiere lograr, y en cada proceso se validan y se crean controles de acceso asignados, ahora bien muchas veces los programadores en la aplicación llegan a validar los primeros 2 controles “pasos” con los requeridos controles de acceso sin embargo dejando despejado y vulnerable el paso 3, que vamos a ver detalle un ejemplo que puede ser vulnerable y que pasos son o pueden ser en una aplicación:
Por ejemplo, la función administrativa para actualizar los detalles del usuario podría implicar los siguientes pasos:
Cargue el formulario que contiene detalles para un usuario específico. (paso rigurosamente protegido)
Envíe los cambios. (paso rigurosamente protegido)
Revisar los cambios y confirmar. (paso vulnerable)
De esta forma una aplicación podría llegar a implementar los pasos y controles de acceso rigurosos pero para los 2 primeros pasos con el pensamiento de: “Si ya hizó los 2 primeros pasos ya se validó el acceso de ese usuario”, sin embargo puede ser para un atacante facil en estos casos, ya que se podría buscar la forma para llegar directamente a la solicitud que contiene el paso 3 que es el vulnerable e intentar de esta forma eludir el control de acceso, obteniendo acceso NO autorizado.
Algunos sitios web implementan en los controles de acceso el encabezado referer que es el que indica la pagina que inició la solicitud, ahora bien este encabezado HTTP puede enviarse en las solicitudes.
Y por ejm una aplicación puede mantener de forma solida el control de acceso a la interfaz de /admin sin embargo sub interfaces de esta interfaz como admin/deleteUser puede ser que se inspecciones con el referer y en ese caso si añadimos al referer la interfaz /admin, podemos entonces permitir la solicitud (aunque tecnicamente no es correcto, claro).
En este caso, Refererun atacante puede controlar completamente el encabezado. Esto significa que pueden falsificar solicitudes directas a subpáginas confidenciales proporcionando el Refererencabezado requerido y obtener acceso no autorizado.
Algunos sitios web imponen controles de acceso basados en la ubicación geográfica del usuario. Esto puede aplicarse, por ejemplo, a aplicaciones bancarias o servicios de medios donde se aplican la legislación estatal o restricciones comerciales. Estos controles de acceso a menudo pueden eludirse mediante el uso de servidores proxy web, VPN o la manipulación de mecanismos de geolocalización del lado del cliente.
Las vulnerabilidades de control de acceso se pueden prevenir añadiendo un enfoque de defensa, aplicando algunos principios que vamos a ver:
Nunca confiar en la ofuscación para el control de acceso, en este caso debemos fiarnos de proteger los controles de acceso que creemos ante cualquier ataque que involucre ofuscaciones de cualquier tipo en cualquier tipo codificación.
A menos que un recurso esté creado para ser accesible publicamente, se debe crear un control de acceso de forma predeterminada, no importa que tipo de recurso o pagina publica a como de lugar debe tener un control de acceso de forma predeterminada ya que es la forma de garantizar de que no se pueda acceder por ninguna parte o recurso de una pagina o empresa.
Utilizar un unico mecanismo de control de acceso, en la medida de lo posible en todos los recursos o subdominios de una pagina principal o recurso principal de una organización, esto con el fin de mantener un control centralizado respecto a los controles de acceso en la organizacion o pagina principal, ya que si se usan diversos controles de acceso en diferentes recursos puede caber la posibilidad muy alta de que uno de esos controles de acceso contenga un pequeño fallo o vuln, lo mejor es usar un unico control de acceso enfocarse bien en ese y que sea robusto, por supuesto.
A nivel de código, haga obligatorio que los desarrolladores declaren el acceso permitido para cada recurso y deniegue el acceso de forma predeterminada.
Auditar constante y de forma detallada periodicamente los controles de acceso creados con el fin de garantizar que funcionen según lo diseñado.
Vamos a ver un LAB para poner en practica la teoría:
Eso es todo por esta vulnerabilidad comunmente conocida como Control de Acceso
Gracias por leerme, un abrazo y que la fuerza te acompañe!
