Vulnerabilidades en el control de acceso y escalada de privilegios
En esta sección, describimos:
- Escalada de privilegios.
- Tipos de vulnerabilidades que pueden surgir con el control de acceso.
- Cómo prevenir vulnerabilidades en el control de acceso.
¿Qué es el control de acceso?
El control de acceso consiste en la aplicación de restricciones sobre quién o qué está autorizado a realizar acciones o acceder a recursos. En el contexto de las aplicaciones web, 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 permite identificar qué solicitudes HTTP posteriores realiza ese mismo usuario.
- El control de acceso determina si el usuario tiene permiso para llevar a cabo la acción que intenta realizar.
Los fallos en los controles de acceso son frecuentes y suelen representar una vulnerabilidad de seguridad crítica. El diseño y la gestión de los controles de acceso constituyen un problema complejo y dinámico que aplica restricciones empresariales, organizativas y legales a la implementación técnica. Dado que las decisiones de diseño de los controles de acceso deben ser tomadas por personas, el potencial de errores es elevado.
Controles de acceso vertical
Los controles de acceso vertical son mecanismos que restringen el acceso a funciones sensibles a tipos específicos de usuarios.
Con los controles de acceso vertical, distintos tipos de usuarios tienen acceso a diferentes funciones de la aplicación. Por ejemplo, un administrador podría modificar o eliminar la cuenta de cualquier usuario, mientras que un usuario común no tendría acceso a estas acciones. Los controles de acceso vertical pueden ser implementaciones más detalladas de modelos de seguridad diseñados para aplicar políticas empresariales como la separación de funciones y el principio de mínimo privilegio.
Controles de acceso horizontales
Los controles de acceso horizontales son mecanismos que restringen el acceso a los recursos a usuarios específicos.
Con los controles de acceso horizontales, diferentes usuarios tienen acceso a un subconjunto de recursos del mismo tipo. Por ejemplo, una aplicación bancaria permitirá a un usuario ver transacciones y realizar pagos desde sus propias cuentas, pero no desde las cuentas de ningún otro usuario.
Controles de acceso dependientes del contexto
Los controles de acceso dependientes del contexto restringen el acceso a la funcionalidad y a los recursos en función del estado de la aplicación o de la interacción del usuario con ella.
Los controles de acceso contextuales impiden que un usuario realice acciones en el orden incorrecto. Por ejemplo, un sitio web de venta minorista podría impedir que los usuarios modifiquen el contenido de su carrito de compras después de haber realizado el pago.
Ejemplos de controles de acceso defectuosos
Las vulnerabilidades de control de acceso defectuoso se producen cuando un usuario puede acceder a recursos o realizar acciones que no debería poder hacer.
Escalada de privilegios verticales
Si un usuario puede acceder a funcionalidades a las que no tiene permiso, se trata de una escalada vertical de privilegios. Por ejemplo, si un usuario sin privilegios de administrador puede acceder a una página de administración donde puede eliminar cuentas de usuario, esto constituye una escalada vertical de privilegios.
Funcionalidad no protegida
En su forma más básica, la escalada vertical de privilegios se produce cuando una aplicación no implementa ninguna protección para las funciones sensibles. Por ejemplo, las funciones administrativas podrían estar enlazadas desde la página de bienvenida de un administrador, pero no desde la página de bienvenida de un usuario. Sin embargo, un usuario podría acceder a las funciones administrativas navegando a la URL de administración correspondiente.
Por ejemplo, un sitio web podría alojar funcionalidades sensibles en la siguiente URL:
https://insecure-website.com/admin
Esto podría ser accesible para cualquier usuario, no solo para los usuarios administrativos que tienen un enlace a la funcionalidad en su interfaz de usuario. En algunos casos, la URL administrativa podría divulgarse en otras ubicaciones, como el archivo robots.txt :
https://insecure-website.com/robots.txt
Aunque la URL no se divulgue en ningún lugar, un atacante podría utilizar una lista de palabras para realizar un ataque de fuerza bruta y descubrir la ubicación de la funcionalidad sensible.
En algunos casos, se oculta la funcionalidad sensible mediante una URL menos predecible. Este es un ejemplo de la llamada «seguridad por ocultación». Sin embargo, ocultar la funcionalidad sensible no proporciona un control de acceso efectivo, ya que los usuarios podrían descubrir la URL ofuscada de diversas maneras.
Imagina una aplicación que aloja funciones administrativas en la siguiente URL:
https://insecure-website.com/administrator-panel-yb556
Es posible que un atacante no pueda adivinar esto directamente. Sin embargo, la aplicación aún podría filtrar la URL a los usuarios. La URL podría revelarse en el código JavaScript que construye la interfaz de usuario en función del rol del usuario:
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', 'https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>
Este script añade un enlace a la interfaz de usuario si el usuario es administrador. Sin embargo, el script que contiene la URL es visible para todos los usuarios, independientemente de su rol.
Métodos de control de acceso basados en parámetros
Algunas aplicaciones determinan los derechos de acceso o el rol del usuario al iniciar sesión y luego almacenan esta información en una ubicación que el usuario puede controlar. Esto podría ser:
- Un campo oculto.
- Una cookie.
- Un parámetro de cadena de consulta preestablecido.
La aplicación toma decisiones de control de acceso en función del valor enviado. Por ejemplo:
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1
Este enfoque es inseguro porque un usuario puede modificar el valor y acceder a funcionalidades para las que no está autorizado, como las funciones administrativas.
Control de acceso defectuoso debido a una configuración incorrecta de la plataforma.
Algunas aplicaciones aplican controles de acceso en la capa de plataforma. Para ello, restringen el acceso a URL y métodos HTTP específicos según el rol del usuario. Por ejemplo, una aplicación podría configurar una regla de la siguiente manera:
DENY: POST, /admin/deleteUser, managers
Esta regla deniega el acceso al método POST en la URL /admin/deleteUser para los usuarios del grupo de administradores. En esta situación pueden surgir diversos problemas que permitan eludir el control de acceso.
Algunos marcos de aplicación admiten varios encabezados HTTP no estándar que se pueden usar para anular la URL en la solicitud original, como X-Original-URL y X-Rewrite-URL. Si un sitio web utiliza controles de interfaz rigurosos para restringir el acceso en función de la URL, pero la aplicación permite que la URL se anule mediante un encabezado de solicitud, entonces podría ser posible eludir los controles de acceso utilizando una solicitud como la siguiente:
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...
Cobalt Strike es una poderosa herramienta de emulación de amenazas que proporciona un agente posterior a la explotación y canales encubiertos ideales para simulaciones de adversarios y ejercicios del Red Team.
Conocer …
Un ataque alternativo se relaciona con el método HTTP utilizado en la solicitud. Los controles de interfaz descritos en las secciones anteriores restringen el acceso según la URL y el método HTTP. Algunos sitios web admiten diferentes métodos de solicitud HTTP al realizar una acción. Si un atacante puede usar este método GET (u otro) para realizar acciones en una URL restringida, puede eludir el control de acceso implementado en la plataforma.
Control de acceso defectuoso debido a discrepancias en la coincidencia de URL.
Los sitios web pueden variar en cuanto a la rigurosidad con la que asignan una solicitud a un punto final definido. Por ejemplo, pueden tolerar mayúsculas y minúsculas inconsistentes, de modo que una solicitud a /ADMIN/DELETEUSER podría seguir asignándose al punto final /admin/deleteUser. Si el mecanismo de control de acceso es menos tolerante, podría tratarlos como dos puntos finales diferentes y, como consecuencia, no aplicar las restricciones correctas.
Pueden surgir discrepancias similares si los desarrolladores que utilizan el framework Spring han habilitado esta opción: useSuffixPatternMatch. Esto permite que las rutas con una extensión de archivo arbitraria se asignen a un endpoint equivalente sin extensión de archivo. En otras palabras, una solicitud a /admin/deleteUser.anything seguiría coincidiendo con el patrón /admin/deleteUser. Antes de Spring 5.3, esta opción estaba habilitada por defecto.
En otros sistemas, puede que encuentre discrepancias sobre si /admin/deleteUser y /admin/deleteUser/ se tratan como puntos finales distintos. En este caso, puede que pueda eludir los controles de acceso añadiendo una barra diagonal al final de la ruta.
Escalada horizontal de privilegios
La escalada horizontal de privilegios se produce cuando un usuario puede acceder a recursos pertenecientes a otro usuario, en lugar de a sus propios recursos de ese tipo. Por ejemplo, si un empleado puede acceder a los registros de otros empleados, además de a los suyos propios, se trata de una escalada horizontal de privilegios.
Los ataques de escalada de privilegios horizontales pueden utilizar métodos de explotación similares a los de la escalada de privilegios verticales. Por ejemplo, un usuario podría acceder a la página de su propia cuenta utilizando la siguiente URL:
https://insecure-website.com/myaccount?id=123
Si un atacante modifica el valor id del parámetro para que coincida con el de otro usuario, podría obtener acceso a la página de la cuenta de ese otro usuario, así como a los datos y funciones asociados.
En algunas aplicaciones, el parámetro vulnerable no tiene un valor predecible. Por ejemplo, en lugar de un número incremental, una aplicación podría usar identificadores únicos globales (GUID) para identificar a los usuarios. Esto puede impedir que un atacante adivine o prediga el identificador de otro usuario. Sin embargo, los GUID de otros usuarios podrían revelarse en otras partes de la aplicación donde se hace referencia a ellos, como en mensajes o reseñas.
En algunos casos, una aplicación detecta cuando el usuario no tiene permiso para acceder al recurso y lo redirige a la página de inicio de sesión. Sin embargo, la respuesta que contiene la redirección aún podría incluir datos confidenciales del usuario objetivo, por lo que el ataque sigue siendo exitoso.
Escalada de privilegios horizontal a vertical
Con frecuencia, un ataque de escalada de privilegios horizontal puede convertirse en una escalada vertical al comprometer a un usuario con mayores privilegios. Por ejemplo, una escalada horizontal podría permitir que un atacante restablezca o capture la contraseña de otro usuario. Si el atacante ataca a un usuario administrador y compromete su cuenta, puede obtener acceso administrativo y, por lo tanto, realizar una escalada de privilegios vertical.
Un atacante podría obtener acceso a la página de cuenta de otro usuario utilizando la técnica de manipulación de parámetros ya descrita para la escalada horizontal de privilegios:
https://insecure-website.com/myaccount?id=456
Si el usuario objetivo es un administrador de la aplicación, el atacante obtendrá acceso a la página de la cuenta administrativa. Esta página podría revelar la contraseña del administrador, proporcionar una forma de cambiarla o brindar acceso directo a funciones con privilegios.
Insecure Direct Object References / Referencias Directas a Objetos Inseguras
Las referencias directas a objetos inseguras (IDOR) son una subcategoría de vulnerabilidades de control de acceso. Las IDOR se producen cuando una aplicación utiliza la entrada del usuario para acceder directamente a objetos y un atacante puede modificarla para obtener acceso no autorizado. Se popularizó al aparecer en el Top Ten de OWASP de 2007. Es solo un ejemplo de los muchos errores de implementación que pueden permitir eludir los controles de acceso.
Vulnerabilidades en el control de acceso en procesos de varios pasos
Muchos sitios web implementan funciones importantes a lo largo de una serie de pasos. Esto es común cuando:
- Es necesario registrar una variedad de datos de entrada u opciones.
- El usuario debe revisar y confirmar los detalles antes de que se realice la acción.
Por ejemplo, la función administrativa para actualizar los datos del usuario podría implicar los siguientes pasos:
- Cargar el formulario que contiene los detalles de un usuario específico.
- Enviar los cambios.
- Revisa los cambios y confírmalos.
En ocasiones, un sitio web implementa controles de acceso rigurosos en algunos pasos, pero ignora otros. Imaginemos un sitio web donde los controles de acceso se aplican correctamente a los dos primeros pasos, pero no al tercero. El sitio web asume que un usuario solo llegará al paso 3 si ya ha completado los primeros, los cuales están debidamente controlados. Un atacante puede obtener acceso no autorizado a la función omitiendo los dos primeros pasos y enviando directamente la solicitud para el tercer paso con los parámetros requeridos.
Control de acceso basado en el referente
Algunos sitios web basan los controles de acceso en el encabezado Referer que se envía en la solicitud HTTP. Los navegadores pueden agregar este encabezado Referer a las solicitudes para indicar qué página inició la solicitud.
Por ejemplo, una aplicación aplica un control de acceso riguroso a la página administrativa principal en /admin, pero para las subpáginas como /admin/deleteUser solo inspecciona el encabezado Referer. Si el encabezado Referer contiene la URL /admin principal, entonces se permite la solicitud.
En este caso, un atacante puede controlar completamente el encabezado Referer. Esto significa que puede falsificar solicitudes directas a subpáginas sensibles proporcionando el encabezado Referer requerido y obtener acceso no autorizado.
Control de acceso basado en la ubicación
Algunos sitios web imponen controles de acceso basados en la ubicación geográfica del usuario. Esto puede ocurrir, por ejemplo, en aplicaciones bancarias o servicios multimedia donde rigen leyes estatales o restricciones comerciales. Estos controles de acceso suelen eludirse mediante el uso de proxies web, VPN o la manipulación de los mecanismos de geolocalización del cliente.
Cómo prevenir vulnerabilidades en el control de acceso
Las vulnerabilidades en el control de acceso pueden prevenirse adoptando un enfoque de defensa en profundidad y aplicando los siguientes principios:
- Nunca confíe únicamente en la ofuscación para el control de acceso.
- A menos que un recurso esté destinado a ser de acceso público, deniegue el acceso por defecto.
- Siempre que sea posible, utilice un único mecanismo para toda la aplicación que permita aplicar los controles de acceso.
- A nivel de código, se debe exigir a los desarrolladores que declaren el acceso permitido para cada recurso y denegar el acceso por defecto.
- Audite y pruebe minuciosamente los controles de acceso para asegurarse de que funcionan según lo previsto.
fuente: portswigger
¿Esta información puede servirle a alguien de tu equipo? Compártela.
