Lathack

Reporte Broken Authentication

Broken Authentication        

 

INTRODUCCIÓN

A continuación se presenta de forma detallada un reporte técnico sobre la vulnerabilidad Broken Authentication con respecto a la Resolución del laboratorio Broken brute-force protection, multiple credentials per request de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score, CVSS Vector y sus Componentes afectados. Sumado a ello, se especificarán las mitigaciones pertinentes, detalles técnicos del pentest y los links de referencias.

 

ANÁLISIS DE RIESGO

CWE – 287

Improper Authentication

IMPACTO

ALTO

CVSS BASE SCORE

6.5

CVSS 3.1 VECTOR

AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

COMPONENTES AFECTADOS

https://LAB-Id.web-security-academy.net/login

EXPLICACIÓN

Existe una falla de seguridad en la Identificación y Autenticación de usuarios en el endpoint login. La cual permite a un atacante iniciar sesión en el sitio web como cualquier usuario y acceder a dicha cuenta sin establecer contraseñas.

 

RECOMENDACIONES

1) Políticas de contraseñas y autenticación: Se recomienda llevar a cabo una correcta política de contraseñas con respecto a la cantidad y tipos de caracteres a establecer. Por ejemplo se podría implementar un mínimo de 8 caracteres los cuales contengan letras mayúsculas, números y caracteres especiales (!”#$%&/), como así también que se cambien cada 30 días (mínimo) para evitar posibles Broken Authentication en la aplicación.

2) Implementar 2FA: Se recomienda implementar un segundo factor de autenticación a través de código vía aplicaciones como Authy o google authenticator.

3) Implementar Tokens de Sesión: Se recomienda implementar tokens de sesión seguros, preferiblemente con técnicas como JSON Web Tokens (JWT) o Secure Cookies, y evitar la transmisión no segura de información de sesión. A se vez, se debe asegurar de que los tokens de sesión se generen de manera aleatoria y sean lo suficientemente complejos para resistir ataques de fuerza bruta. Por ejemplo, para la generación de Tokens durante la Autenticación se puede usar el siguiente código Javascript:

//1. Cuando un usuario se autentica correctamente, genera un JWT que incluya 

//la información necesaria (como el ID del usuario, roles, etc.).

//2. Firma el token con una clave secreta conocida solo por el servidor.

const jwt = require(‘jsonwebtoken’);

const payload = { userId: 123, username: ‘usuario’, roles: [‘user’] };

const secretKey = ‘tu_clave_secreta’;

const token = jwt.sign(payload, secretKey, { expiresIn: ‘1h’ });

«`

4) Validar datos en el servidor: Se recomienda realizar validaciones de acceso en el servidor, incluso si la información del cliente parece válida. Para ello, se pueden establecer cabeceras de seguridad como Content Security Policy (CSP) con los valores default-src ‘self’; script-src ‘self’; object-src ‘none’; frame-src ‘none’; base-uri ‘none’; . Esta política especifica qué recursos como imágenes y scripts, solo pueden cargarse desde el mismo origen que la página principal. Sumado a esto, también se recomienda minimizar el uso de intercambio de recursos entre orígenes (CORS).

5) Gestión de sesiones: Se recomienda llevar a cabo, y de forma periódica, una correcta gestión de vulnerabilidades y Hardening en la aplicación web. Como así también, parchear y actualizar los frameworks y sistemas que la aplicación requiera para evitar posibles Broken Authentication.

6) Controles de seguridad: Siempre se aconseja llevar a cabo, y de forma periódica, una correcta gestión de vulnerabilidades y Hardening en la aplicación web. Como así también, parchear y actualizar los frameworks y sistemas que la aplicación requiera.

 

DETALLES TÉCNICOS

Una vez dentro de la aplicación web, se pudo observar que la misma cuenta con una pestaña de inicio de sesión “My account”.

Figura 1: Home del sitio web


Teniendo en cuenta que la aplicación provee el username “carlos”, se procedió a analizar la forma en la que se transmiten los datos cuando se intenta acceder a dicha cuenta.

Figura 2: Envío de credenciales en formato json

Con dicha captura se puede verificar que los datos se codifican y almacenan en formato JSON y, cuando no se coloca un valor de password, el servidor responde con el mensaje “Missing Parameter”. Por lo tanto, se procedió a llevar a cabo un ataque de fuerza bruta con posibles credenciales (cuyo link está en las referencias) a través de la herramienta Burpsuit de la siguiente manera:

Figura 3: Ataque de fuerza bruta vía Intruder


Como se ve en la captura anterior, se envió la petición a la pestaña del Intruder (Ctrl+i), se debe seleccionar el tipo de ataque “snipper” y finalmente hacer click en “Start attack”.

Figura 4: Content-Length diferente en tercera petición


Se puede apreciar que el ataque de fuerza bruta no tubo éxito debido a que, a partir de la tercera petición, el tamaño (length) de las peticiones fueron todas iguales. Esto quiere decir que posiblemente halla un Firewall por detrás limitando la cantidad de intentos de sesión. Por tanto, se procedió a llevar a cabo las siguientes prácticas para su verificación.

Paso 1: Se procedió a enviar tres peticiones de intentos de sesión a través de los caracteres “a”, luego “ab” y finalmente “abc” cuya respuesta por parte del servidor fue un “Invalid Username o Password”, indicando el error de las mismas.

Broken Authentication
Figura 5: Envío de tres peticiones con passwords diferentes


Paso 2: Sumado a lo anterior, se agregó una cuarta petición “abcd” cuyo mensaje por parte del servidor refiere a una cantidad máxima de intentos de sesión, en este caso tres. De esta manera, se pudo comprobar porqué el ataque de fuerza bruta no funcionó ya que la aplicación solo permite tres intentos seguidos y luego se debe esperar un minuto para volver a probar contraseñas.

Broken Authentication
Figura 6: Aplicación del WAF en cuarta petición


Paso 3: En esta captura, y no muy distinta a la anterior, se puede verificar que por detrás seguramente halla un Firewall bloqueando a cualquier dirección IP que haga una determinada cantidad de peticiones, o intentos de sesión, en un tiempo determinado.

Broken Authentication
Figura 7: Envío de varias credenciales vía formato json


Por lo tanto, teniendo en cuenta que los datos se transmiten en formato JSON, se procedió a colocar una lista de posibles contraseñas (como se muestra en la captura del paso 3) como valor de una sola clave.

Broken Authentication
Figura 9: Envío de múltiples contraseñas en un solo campo

Como se puede apreciar, se tubo éxito con dicho ataque y, por lo tanto, se tiene acceso al sitio web como usuario carlos. De esta manera, un atacante puede romper de forma fácil la autenticación de un usuario e iniciar sesión en la aplicación sin saber sus contraseñas.


Cabe mencionar que en las referencias hay un script en Python, cuya función es romper dicha autenticación a través de los mismos pasos.

De esta manera hemos resuelto el laboratorio y aprendido cómo podemos generar un Broken Authentication en sistemas json a través del envío de credenciales.

Si quieres aprender sobre otras vulnerabilidades puedes acceder al siguiente enlace donde se explica cada una de ellas con sus respectiva resolución de laboratorio, mitigaciones, impacto y mucho más.

 

REFERENCIAS

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

uno + dieciocho =

Lathack
Scroll al inicio