¿Tu aplicación web es vulnerable a un Ataque de Escalada de Privilegios? Analízalo con la OTG-AUTHZ-003 para que salgas de dudas (+Ejemplo)

La prueba de seguridad OTG-AUTHZ-003 tiene como objetivo determinar hasta qué punto es posible que un usuario pueda modificar sus privilegios o roles dentro de la aplicación web. Este comportamiento se denomina Ataque de Escalada de Privilegios (privilege escalation attack) y puede ser de tipo horizontal cuando es posible acceder a recursos de usuarios con privilegios similares y vertical cuando el usuario adquiere más privilegios que los asignados a este (como los de un administrador).

Para la conducción de la prueba de seguridad debe analizarse si la aplicación web posee algún mecanismo de autorización que tenga como base la información proveniente del cliente. Por ejemplo, puede ocurrir que exista una cookie o parámetro que establezca el nivel de acceso del usuario y por tanto puede ser propensa a su manipulada del lado del cliente. Por las características de la información y comportamiento que se está analizando, es muy difícil que pueda automatizarse de forma genérica esta prueba de seguridad. Por ello su resultado dependerá de la experiencia del especialista y el tiempo disponible para su realización. A continuación, se describirán tres ejemplos para representar como puede ser llevada a cabo.

Un primer ejemplo de lo expuesto puede ser el que aparece en la página 83 de la OTG. En este caso se plantea un proceso de creación de un usuario en una aplicación web:

POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]
userID=fakeuser&role=3&group=grp001

Podemos apreciar que cuando se envía los datos del usuario en el cuerpo de la petición HTTP aparece el campo role y el campo group. La prueba de seguridad en este caso se centraría en modificar estos valores para tratar de registrar un usuario con un rol diferente y acceso a datos de otros grupos que los normales.

Otro ejemplo que propone la OTG ocurre luego que un usuario se ha autenticado en la aplicación web y el servidor le envía la siguiente respuesta HTTP:

HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/;
domain=www.example.com
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/;
domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

<form name=”autoriz” method=”POST” action = “visual.jsp”>
<input type=”hidden” name=”profile” value=”SysAdmin”>
<body onload=”document.forms.autoriz.submit()”>

En este caso podemos ver como en el cuerpo de la respuesta HTTP aparece un campo oculto de formulario con valor SysAdmin. ¿Qué pudiera ocurrir si es modificado este valor en una petición HTTP posterior?

Dentro de las aplicaciones web que vienen en la máquina virtual del proyecto BWA de OWASP se encuentra OWASP Security Shepherd (Figura 1).

Figura 1 - OWASP Security Shepherd

Figura 1. OWASP Security Shepherd. Elaboración propia.

Esta brinda un conjunto de escenarios de pruebas de seguridad dentro de la cual se encuentra el acceso a un código reservado solamente a los usuarios que tengan el rol de administrador (Figura 2).

Figura 2 - Reto de Seguridad

Figura 2. Reto de Seguridad asociado al rompimiento de la Autenticación y Manejo de Sesiones. Elaboración propia.

Supongamos que queremos comprobar hasta qué punto es seguro el mecanismo de autorización de esta funcionalidad. Para ello realizaremos clic en el botón Administrators Only Button para analizar como se conforma la petición HTTP y determinar si hay alguna información sobre roles o privilegios que podamos aprovechar. En la Figura 3 podemos comprobar de una primera mirada que los campos que viajan en el cuerpo de la petición son muy promisorios. Tenemos nombres como adminDetected y upgradeUserToAdmin que resultan más que sugerentes, sin embargo, son una trampa de detección de intrusos debido a que su envió modificado levanta una alerta en la aplicación web.

Figura 3 - Estructura y Contenido de la petición HTTP

Figura 3. Estructura y contenido de la petición HTTP generada por Administrators Only Button. Se muestra la decodificación Base64 de la cookie checksum. Visualizado con OWASP ZAP. Elaboración propia.

Para un especialista familiarizado con las cookies y rutas de la aplicación web OWASP Security Shepherd, no encontrará ninguna información inusual, más allá de la que ya explicamos. No obstante, podemos apreciar una cookie nueva que se denomina checksum con valor dXNlclJvbGU9dXNlcg==, que a todas luces es una cadena codificada con Base64. En la Figura 3 (anterior) puede apreciarse como la decodificación de esta cadena arroja el resultado userRole=user. La pregunta que debemos hacernos es: ¿Qué sucedería si user es sustituido por admin o administrator?

Codificamos por tanto la cadena userRole=administrator en Base64, tomamos el valor resultante, lo asignamos a la cookie correspondiente y reenviamos la petición HTTP con el valor manipulado (Figura 4):

Figura 4 - Codificando la  cadena userRole=administrator en Base64

Figura 4. Codificando la cadena userRole=administrator en Base64. Elaboración propia.

La aplicación web responde entonces como si el usuario fuera administrador, mostrando la información restringida (Figura 5):

Figura 5 - Rompimiento de la autorización en OWASP Security Shepherd.

Figura 5. Rompimiento de la autorización en OWASP Security Shepherd. Elaboración propia.

Los ejemplos mostrados ilustran la necesidad de que la gestión de la autorización se fortalezca en el servidor de aplicaciones. Por muchos mecanismos de verificación que se implementen, si la aplicación web depende de que el usuario envíe datos que describan su rol o privilegios en la aplicación, siempre será vulnerable a que pueda ser manipulada esta información para beneficio de los ciberdelincuentes.

La segmentación de procesos puede ser un aliado importante para evitar estas vulnerabilidades. Por ejemplo, todos los usuarios creados en la aplicación web tienen un rol básico al inicio y por tanto no es necesario enviar este dato en la petición de inserción. Posteriormente un administrador, desde otro formulario puede modificarle el rol o los privilegios correspondientes.

Espero que te haya gustado el post, yo por mi parte me he entretenido bastante escribiéndolo.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

17 comentarios en “¿Tu aplicación web es vulnerable a un Ataque de Escalada de Privilegios? Analízalo con la OTG-AUTHZ-003 para que salgas de dudas (+Ejemplo)

  1. muy buen artículo y la recomendación que comenta en el último parrafo es mas bien una buena práctica de programación que se debe exigir siempre. La segmentación de procesos es muy importante, es algo que siempre le exijo a mis programadores en los proyectos. Actualmente es difícil prescindir completamente de las cookies pero es bueno intentar usarlas lo menos posible.
    saludos.
    Buen trabajo.

    Le gusta a 1 persona

  2. Muchas gracias por tu aporte agattorno, es importante conocer la opinión de expertos como usted, nos alienta a continuar trabajando en nuevos artículos. Un placer nuevamente.

    Le gusta a 1 persona

  3. Pingback: ¿Que es un ataque de tipo “Parameter Tampering” y como puede evitarse? | Behique Digital

  4. Pingback: ¿Qué es lo nuevo en el OWASP Top 10 2017 R1? | Behique Digital

  5. Pingback: Guía de Pruebas de OWASP 4.0 | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s