Reporte Websocket handshake
INTRODUCCIÓN
A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio Manipulating the WebSocket handshake to exploit vulnerabilities de la plataforma Portswigger. El mismo se establece con un análisis de riesgo con respecto a la vulnerabilidad websocket handshake y al impacto que esta puede generar. Esto incluye CWE, Criticidad, CVSS Score & 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 – 1385 | Missing Origin Validation in WebSockets |
IMPACTO | ALTO |
CVSS BASE SCORE | 8.2 |
CVSS 3.1 VECTOR | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N |
COMPONENTES AFECTADOS | https://LAB-Id.web-security-academy.net/chat |
EXPLICACIÓN | Existe un fallo de seguridad con respecto a la validación de datos específicos en el input del chat vía websocket y la cabecera X-forwared-for. De esta manera, un atacante puede aprovecharse de cambiar el valor de dicha cabecera y, a su vez, inyectar código malicioso javascript afectando a los usuarios del sistema. |
RECOMENDACIONES
1) Validación de cabeceras HTTP: Se recomienda realizar una correcta validación de las cabeceras HTTP tanto en las solicitudes iniciales como en las subsiguientes a través de la conexión WebSocket handshake. Solo se deben permitir las cabeceras necesarias y esperadas.
2) Filtrar y validar los datos de entrada: Se recomienda utilizar listas de caracteres permitidos y rechazar cualquier entrada que contenga código o secuencias sospechosas, por ejemplo con JSON se puede codificar sus cadenas utilizando JSON.stringify.
A continuación se detallan algunos ejemplos en Javascript:
Escapes de caracteres especiales: Al mostrar datos en el DOM, se debe asegurar de escapar caracteres especiales para evitar ataques de inyección de código (por ejemplo XSS).
Validación del lado del servidor: Se recomienda implementar una validación más estricta y segura en el lado del servidor para garantizar la integridad de los datos.
3) Políticas de contraseñas y autenticación: Se recomienda llevar a cabo una correcta política de contraseñas para garantizar que solo usuarios autorizados tengan acceso al WebSocket handshake. 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 dias (mínimo). A su vez, una buena capa y práctica de seguridad sería implmentar 2FA vía código (por ejemplo con Authy o Goohle Authenticator)
iptables -A INPUT -p tcp –dport 80 -m recent –update –seconds 1 –hitcount 5 -j DROP iptables -A INPUT -p tcp –dport 80 -m recent –set -j ACCEPT |
5) Configuración adecuada de CORS (Cross-Origin Resource Sharing): Se recomienda configurar adecuadamente las políticas de CORS para prevenir la suplantación de identidad y limitar los dominios que puedan acceder a los WebSockets. Por ejemplo, se puede Implementar la configuración de los mismos en el servidor para que se aplique correctamente a todas las rutas o endpoints que necesiten dicho soporte.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se pudo observar que la misma cuenta con la pestaña “Live chat” la cual refiere a una mensajería instantánea web (websocket handshake).
Si nos dirigimos a la pestaña Live chat veremos lo siguiente.
Por tanto, se procedió a interceptar dichas conexiones a través de Burpsuit para investigar, y verificar, si existe algún fallo de seguridad en la misma.
Se puede apreciar que dichos datos se almacenan y codifican en formato JSON. Por tanto, se utilizó el siguiente payload html <img src=error onerror=’alert(document.domain)’> para verificar si el websocket handshake es vulnerable a un ataque XSS (Cross Site Scripting) de la siguiente manera:
La respuesta del servidor fue la siguiente:
En el navegador veríamos lo siguiente
Como se observa, se puede deducir que el WAF ha alertado al servidor sobre un posible ataque. Por tanto, y de forma automática, la conexión al chat se cierra y se bloquea la dirección IP que envió dicha petición, es decir, la misma se coloca en una lista negra como refiere el mensaje.
Teniendo esto en cuenta, se procedió a utilizar la cabecera http X-forwared-for para “decirle” al servidor que la dirección IP de origen es otra.
Efectivamente se puede observar que cambiando el valor de la cabecera X-forwared-for por una IP que contenga una dirección distinta, o con el DNS de Cloudflare 1.1.1.1, se puede eludir dicho sistema de seguridad.
Por lo tanto, se procedió a utilizar dicha cabecera para enviar mensajes de chats y probar direferentes tipos de payloads, o cargas útiles maliciosas, con el fin de verificar que no se encontrase dentro de la lista negra y pueda ser ejecutada. Para ello, se pudo comprobar que el payload <img src=1 oNeRrOr=alert’1’> no es bloqueado y es enviado normalmente a través de la mensajería de chat.
Como se puede apreciar, dicho payload se utilizó de forma ofuscada para comprobar si la lista negra también bloqueaba caracteres vía Keysensitive.
Por tal motivo, se procedió a conectarse desde otra dirección IP y comprobar si la aplicación es vulnerable a dicho payload xss.
De esta forma, cuando se recarga la página se puede observar lo siguiente.
De esta manera, se puede comprobar que el sitio web es vulnerable a un ataque XSS viía Websocket handshake.
Un atacante podría configurar las cabeceras HTTP y probar una larga lista de payloads maliciosos, como así también atacar desde otra dirección IP una vez encontrada verificada su carga útil.
