14 oct 2024

A01:2021 - Broken Access Control


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:

  1. 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:
  2. 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.

7 oct 2024

OWASP TOP 10


La seguridad en aplicaciones web es una prioridad en el mundo actual, donde las amenazas cibernéticas están en constante evolución. Para ayudar a los desarrolladores y profesionales de seguridad, la Open Web Application Security Project (OWASP) publica una lista conocida como OWASP Top 10, que destaca las vulnerabilidades más críticas en las aplicaciones web. Esta lista es esencial para comprender los riesgos y las medidas necesarias para mitigar estas amenazas.

¿Qué es OWASP Top 10?

El OWASP Top 10 es una clasificación de las vulnerabilidades más graves que afectan a las aplicaciones web. Su objetivo es proporcionar conciencia y conocimiento a la comunidad tecnológica sobre las fallas de seguridad más comunes y peligrosas. Actualizada periódicamente, esta lista ofrece una guía práctica para prevenir, detectar y corregir las vulnerabilidades más críticas.

Las vulnerabilidades en el OWASP Top 10 tienen el potencial de comprometer gravemente la seguridad de una aplicación, exponiendo datos sensibles, permitiendo el acceso no autorizado y causando grandes pérdidas para las organizaciones.

Existen distintas ediciones del OWASP Top 10, clasificadas según el año de su creación o actualización. Esto se debe al cambio en el panorama general de la seguridad web, ya que, según los datos recopilados por la Fundación OWASP, la frecuencia de determinados tipos de vulnerabilidades va aumentando y disminuyendo con el paso del tiempo. A su vez, nuevos tipos de vulnerabilidades emergen, mientras que otras desaparecen, reciben un nombre distinto o se agrupan:


En esta entrada de blog hemos decidido presentar la versión más reciente de OWASP TOP 10 a octubre 2024, es decir, la versión de 2021.

OWASP Top 10 2021


En la edición de 2021, OWASP actualizó su lista con las principales amenazas de seguridad que afectan a las aplicaciones web hoy en día. A continuación, se destacan las 10 categorías de riesgo más relevantes:


A01:2021 - Pérdida de control de acceso

Se refiere a fallos en las restricciones de acceso a datos o funcionalidades. Esto permite a los atacantes realizar acciones no autorizadas, como acceder a datos confidenciales o realizar funciones de administración sin los permisos necesarios. Algunas de las vulnerabilidades relacionadas:
  • Escalada de privilegios: Usuarios normales pueden obtener o realizar acciones que requieren privilegios de administrador.
  • Movimiento lateral: Los usuarios pueden acceder a datos de otros usuarios de la plataforma.
  • Falta de control de acceso en APIs: Las API no protegen correctamente los recursos.

A02:2021 - Fallos criptográficos

Esta categoría cubre los errores en la protección de datos sensibles, como contraseñas o información personal. Si los datos no están debidamente cifrados, los atacantes pueden interceptarlos y leerlos fácilmente. Algunas de las vulnerabilidades relacionadas:
  • Cifrado débil o inexistente: Uso de algoritmos criptográficos obsoletos o falta de cifrado en datos sensibles.
  • Gestión inadecuada de claves: Almacenamiento o transmisión insegura de claves criptográficas.
  • Exposición de datos sensibles: Contraseñas, números de tarjeta o datos personales no cifrados.

A03:2021 - Inyección

Las vulnerabilidades de inyección, como la inyección SQL, permiten que un atacante inserte comandos maliciosos en la entrada de la aplicación para alterar su funcionamiento. Esto puede permitir acceso no autorizado a bases de datos y otros recursos. Algunas de las vulnerabilidades relacionadas:
  • Inyección SQL: Manipulación de consultas SQL para acceder o modificar datos de una base de datos.
  • Inyección de comandos: Ejecución de comandos del sistema operativo a través de entradas inseguras.
  • Inyección de código: Inserción de código malicioso en la aplicación, por ejemplo, código JavaScript.

A04:2021 - Diseño inseguro

Ocurre cuando no se consideran los principios de seguridad durante el proceso de diseño de la aplicación, lo que resulta en fallos estructurales difíciles de solucionar una vez implementada. Algunas de las vulnerabilidades relacionadas:
  • Falta de validación de entrada: No se comprueban adecuadamente los datos introducidos por el usuario. Este tipo de vulnerabilidad puede derivar en otras vulnerabilidades como la inyección de comandos o inyección SQL.
  • Ausencia de controles de seguridad: Falta de autenticación o cifrado en puntos críticos.
  • Arquitectura deficiente: Ausencia de separación de roles o uso de patrones de diseño inseguros.

A05:2021 - Mala configuración de la seguridad

La configuración incorrecta o por defecto de sistemas, servidores y aplicaciones es un problema común que deja expuestas las aplicaciones a ataques. Este riesgo puede evitarse mediante una configuración adecuada y revisiones periódicas. Algunas de las vulnerabilidades relacionadas:
  • Credenciales por defecto: Uso de contraseñas o configuraciones predeterminadas en servidores o aplicaciones.
  • Exposición de archivos sensibles: Archivos de configuración o bases de datos accesibles públicamente.
  • Servicios no necesarios habilitados: Servicios no utilizados que podrían ser explotados.

A06:2021 - Componentes vulnerables y desactualizados

Muchas aplicaciones dependen de bibliotecas o frameworks de terceros. Si estos componentes no se actualizan o contienen vulnerabilidades conocidas, los atacantes pueden explotarlos para comprometer la seguridad de la aplicación. Algunas de las vulnerabilidades relacionadas:
  • Dependencias con vulnerabilidades conocidas: Uso de bibliotecas o frameworks con fallos de seguridad conocidos.
  • Software desactualizado: Falta de actualizaciones de seguridad o parches disponibles.
  • Plugins y módulos inseguros: Uso de extensiones o módulos de terceros que no se han auditado correctamente. (Plugins de WordPress desactualizados, librerías de JavaScript desactualizadas…)

A07:2021 - Fallos de identificación y autenticación

La autenticación deficiente permite a los atacantes eludir la verificación de identidad de los usuarios, lo que resulta en suplantación de identidad o accesos no autorizados. Algunas de las vulnerabilidades relacionadas:
  • Autenticación insegura: Falta de mecanismos como autenticación multifactor (MFA).
  • Sesiones no protegidas: Tokens de sesión expuestos o falta de expiración de sesiones.

A08:2021 - Fallos en el software y la integridad de la información

Esta vulnerabilidad afecta cuando no se verifica adecuadamente la integridad de las actualizaciones del software o los datos almacenados. Esto permite a los atacantes alterar el código fuente o los datos sin ser detectados. Algunas de las vulnerabilidades relacionadas:
  • Actualizaciones no verificadas: Actualización de software sin comprobar su autenticidad.
  • Alteración de código fuente: Inyección de código malicioso en repositorios o pipelines de CI/CD.
  • Manipulación de archivos críticos: Alteración de archivos de configuración o bases de datos sin detección.

A09:2021 - Fallo en el registro de eventos de seguridad y monitorización

Sin un registro adecuado y una monitorización activa, es difícil detectar o reaccionar ante ataques en curso. Este fallo limita la capacidad de respuesta ante incidentes de seguridad. Algunas de las vulnerabilidades relacionadas:
  • Falta de registros de eventos: Falta de registros de acceso, errores o cambios en el sistema.
  • Logs insuficientes: Los registros no contienen información suficiente para diagnosticar problemas.
  • No se detectan ataques en tiempo real: No hay sistemas de alerta o monitorización activa ante incidentes.

A10:2021 - Forzado de peticiones del lado del servidor (SSRF)

El ataque SSRF ocurre cuando una aplicación web es engañada para realizar solicitudes a otros servidores, permitiendo a los atacantes acceder a recursos internos que normalmente estarían protegidos. Algunas de las vulnerabilidades relacionadas:
  • Acceso a recursos internos: El atacante utiliza la aplicación para acceder a servidores internos o bases de datos.
  • Evasión de firewalls: El atacante explota la vulnerabilidad para saltar las restricciones de seguridad de red.
  • Consulta de servicios locales: El atacante accede a servicios en la red interna, como HTTP, FTP o SSH.

Durante los próximos meses iremos publicando entradas sobre cada una de las vulnerabilidades del TOP 10. Indagaremos en todos los tipos de vulnerabilidades relacionadas con cada uno de los riesgos, así como en los ataques para explotar dichas vulnerabilidades.