A continuación se presenta de forma detallada un reporte técnico sobre la Resolución del laboratorio Exploiting HTTP request smuggling to perform web cache poisoning 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-444
Inconsistent Interpretation of HTTP Requests (‘HTTP Request/Response Smuggling’)
La desincronización entre los servidores y/o componentes del sistema, permite que un atacante pueda generar un ataque de contrabando de peticiones HTTP en la aplicación web. De esta manera, puede obtener acceso a datos sensibles de otros usuarios (como la API Key) a través de la caché web.
RECOMENDACIONES
1) Priorizar el Header Transfer-Encoding sobre Content-Lenght: Se recomienda configurar el servidor para priorizar la cabecera de codificación de transferencia (TE) sobre la longitud del contenido (CL). Esto se debe a que las cabeceras TE pueden cubrir solicitudes estáticas y , por lo que usarlas para solicitudes con dos cabeceras es la primera línea de defensa contra los ataques de CL.TE y TE.CL.
2) Rechazar cualquier tipo de solicitud con doble Headers: Se recomienda responder con un código de error HTPP 400 a cualquier solicitud que contenga en las cabeceras CL-TE, TE-CL y TE-TE. Este error informa al cliente que el servidor no procesará la solicitud HTTP debido a la sintaxis de solicitud malformada. Esto hace cumplir la interpretación consistente de las cabeceras HTTP tanto en el servidor de gama frontal como en el backend.
A continuación se muestra un ejemplo de Node.js con Expres:
const express = require(‘express’);
const app = express();
app.use((req, res, next) => {
// Verificar si la solicitud contiene la cabecera «doubleHeaders»
if (req.headers.doubleHeaders) {
// Si la cabecera está presente, responder con un código de error 400
return res.status(400).send(‘Solicitud no válida: doubleHeaders no permitido’);
}
// Si la cabecera no está presente, continuar con el manejo normal de la solicitud
next();
});
// Resto de la configuración y rutas del servidor aquí
const PORT =3000;
app.listen(PORT, () => {
console.log(`Servidor escuchando en el puerto ${PORT}`);
});
3) Utilizar la última versión de HTPP: Se recomienda utilizar HTTP/2 ya que utiliza un mecanismo robusto para determinar la duración de las solicitudes y, cuando se utiliza de un extremo a otro, está inherentemente protegido contra el contrabando de solicitudes. En caso de no poder utilizarlo, asegúrese de validar la solicitud reescrita con la especificación HTTP/1.1. Por ejemplo, rechace solicitudes que contengan nuevas líneas en los encabezados, dos puntos en los nombres de los encabezados y espacios en el método de solicitud.
4) Nunca asuma que las solicitudes no tendrán cuerpo: Esta es la causa fundamental de las vulnerabilidades de desincronización tanto de CL.0 como del lado del cliente.
5) No permitir encabezados TE con formato incorrecto y procesar correctamente múltiples valores TE: Para evitar ataques TE:TE y garantizar que varios valores del mismo se procesen correctamente, asegúrese de que se rechacen los siguientes tipos de variación de encabezado:
Encabezados con espacios extra o en blanco.
Encabezados que proporcionan un valor «chunk» en lugar de «chunked» (ya que el servidor normaliza esto como codificación fragmentada).
Encabezados con valores citados (ya sean comillas simples o dobles) y valores con caracteres no válidos.
Encabezados sin espacio antes del valor «chunked”.
Encabezados que comienzan con caracteres finales y caracteres CR-LF antes del calor “chunked”. Los caracteres CR y LF son caracteres ASCII especiales que significan «Retorno de carro» y «Salto de línea» (valores hexadecimales 0D y 0A).
6) Realizar una correcta gestión de vulnerabilidades: Se recomienda realizar esta tarea en la etapa de prueba, es decir antes de que el código salga a producción.
7) Educar en Materia de Seguridad informática: Se recomienda educar al personal y/o trabajadores en la seguridad de los datos con respecto a la confidencialidad, integridad y disponibilidad de los mismos a través de talleres o cursos pertinentes.
DETALLES TÉCNICOS
Una vez dentro de la aplicación web, se procedió a estudiar la forma en la que se transmiten los datos. Para ello, se utilizó la herramienta Burpsuit con el fin de estudiar las Peticiones y Respuestas de cada sección de la plataforma.
Figura 1: Petición vía GET al home del sitio web
Como se ve en la captura anterior, la aplicación acepta solicitudes HTTP/1.1 cuando se quiere acceder al home (o raiz) de la aplicación. Por tanto, se procedió a colocar dos solicitudes de la siguiente manera:
POST / HTTP/1.1
Host: LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 42
Transfer-Encoding: chunked
0
GET /path_inexistente HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
X-Ignore: X
Figura 2: Envío de contrabando de peticiones http
Por lo tanto, cuando se quiere volver acceder al home de la aplicación, como se mostró en la primera captura, se recibe una respuesta de error.
Figura 3: Mensaje de error en el Response vía GET home
De esta forma se comprueba que el sitio web es vulnerable a HTPP Request Smuggling CL-TE.
NOTA El contrabando de solicitudes HTTP se produce cuando los servidores Frontend y Backend interpretan el límite de una solicitud HTTP de manera diferente, lo que provoca la desincronización entre ellos. Esto se debe a que las numerosas bibliotecas que estos poseen se desvían de las especificaciones RFC cuando se trata tanto del encabezado Content-Length, como del Transfer-Encoding. Por lo tanto, esto permite a un atacante interferir con la forma en que un servidor procesa las solicitudes HTTP que recibe, pudiendo así, eludir los controles de seguridad y obtener acceso a datos sensibles.
Figura 4: Estructura de un http request smuggling
De esta forma, un atacante puede hacer uso del encabezado Content-Length y Transfer-Encoding para asegurarse de que la información contenida en los dos encabezados se contradiga. Esto se debe a que el primero hace referencia a la longitud del cuerpo del mensaje en bytes, mientras que el segundo especifica que el cuerpo del mensaje posee uno o más fragmentos de datos.
Sumado a esto, se procedió a ingresar al panel del usuario wiener con las credenciales establecidas por la plataforma como se muestra a continuación.
Figura 5: Datos del usuario wiener
Cuando se accede con dichas credenciales se cargan los siguientes recursos.
Figura 6: Recursos cargados en un inicio de sesión
Entonces se debe tener en cuenta lo siguiente:
Primero se debe tener en cuenta que la ruta /my-account?id=wiener refiere al panel de acceso de dicho usuario. No obstante, de igual manera se carga el mismo recurso cuando se intenta acceder a la misma ruta pero sin especificar el parámetro id=user. Figura 7: Datos de usuario vía GET a my-accountEste dato es fundamental ya que, como se verá a continuación, un atacante no necesita los datos de nombres de usuarios para obtener datos sensibles como la API Key.
Una vez que un usuario inicia sesión en el sistema, se cargan los datos del mismo en la caché web a través del recurso /resources/js/tracking.js. Figura 8: Datos cargados en caché vía Cache-Control headerPor lo tanto, un atacante podría generar un ataque del tipo “Web Cache Deception”. Es decir, hace que la aplicación almacene contenido confidencial (como la API Key) que pertenece a otro usuario en la caché y luego, a través del contrabando de solicitudes HTTP, obtiene las mismas.
A modo de ejemplo, se procedió a utilizar la siguiente solicitude HTTP:
POST / HTTP/1.1
Host: LAB-Id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 42
Transfer-Encoding: chunked
0
GET /my-account HTTP/1.1
X-Ignore: X
Figura 9: Contrabando de peticiones a my-account
Luego de enviar dicha solicitud, y habiendo obtenido un código de estado 200, se procedió a acceder al recurso de caché como se ve a continuación.
Figura 10: Credenciales del usuario Administrador vía HTTP RS
El servidor backend responde la solicitud de dicha URL de forma habitual, es decir, se procesa en el contexto de sesión del usuario víctima. Por otro lado, el servidor frontend almacena en caché dicha respuesta frente a lo que “cree” que es la URL de la segunda solicitud, la cual es /resources/js/tracking.js.
De esta forma, a través de una ataque http request smuggling, un atacante puede obtener datos confidenciales que pertenezcan a otro usuario desde la cache web.
