Contrabando de solicitudes HTTP: nuevos enfoques

El 7 de octubre de 2019, el Director de Investigación de PortSwigger (fabricante de BurpSuite) publicó un estudio sobre nuevos enfoques para el contrabando de solicitudes HTTP. Con su ayuda, ganó alrededor de $ 70,000 en bugbounty. En este artículo, descubrimos brevemente la esencia del ataque, las herramientas y también los métodos de investigación de servidores web que son vulnerables a esta vulnerabilidad.

¿Qué es el contrabando de solicitudes HTTP?

Contrabando de solicitudes HTTP: un ataque destinado a desincronizar el frontend del servidor web y el back-end del servidor web, como resultado de lo cual el atacante podría pasar de contrabando una solicitud HTTP más allá del servidor frontend. La imagen del artículo original sirve como una buena demostración:

Tal ataque puede llevar a una variedad de consecuencias: la introducción de XSS en la sesión de otros usuarios, redirigiendo a los usuarios a recursos de terceros, envenenando la caché del servidor, similitud con SSRF y muchos otros.

En la Encarnación de contrabando de 2019 de 2019, James Kettle explotó el procesamiento incorrecto del encabezado del servidor web

Transfer-Encoding: chunked 

indicando que el cuerpo del mensaje se transmitirá en partes ( RFC ). Debido al hecho de que algunos servidores web no son compatibles con la transmisión fragmentada, o manejan el encabezado de manera diferente, el frontend "verá" solo una solicitud, y el backend la reconocerá como dos. Puede encontrar más detalles sobre los detalles del ataque en el artículo original , también hay una tarea práctica en la que puede practicar para encontrar la vulnerabilidad manualmente.

Para una búsqueda rápida, James desarrolló un complemento para BurpSuit, que recibe una solicitud de entrada y crea una nota sobre la vulnerabilidad del servicio (si existe) en la salida.

Ejemplos de servidores web vulnerables

Debo decir que el problema del contrabando y otras vulnerabilidades relacionadas con el funcionamiento de los servidores web ha sido tratado por otro investigador bajo el apodo regilero . En los últimos tres años, ha publicado tres artículos que describen las vulnerabilidades que encontró en los servidores web populares, la mayoría de los cuales tienen asignados CVE de crítica media y alta. Entre los servidores vulnerables se encuentran Apache Traffic Server, Jetty, Apsis.

A raíz del interés en el problema, otro investigador, Nathan Davison, descubrió una vulnerabilidad en HAProxy, que ignoró un encabezado formado incorrectamente.

 Transfer-Encoding:[\x0b]chunked 

y lo convirtió a la siguiente forma:

 Transfer-Encoding: chunked 

Pero el servidor de fondo: gunicorn, que representa la aplicación en Flask, leyó el encabezado, lo que provocó la vulnerabilidad.

Un poco más tarde, varios otros investigadores descubrieron una vulnerabilidad (asignada CVE-2019-16276) en la implementación del servidor http golang: el servidor normalizaba el encabezado si había un espacio antes del prelet.
Solicitud:

Después de procesar por el servidor:

La vulnerabilidad podría explotarse si el servidor frontend ignora el encabezado con un espacio y usa Content-Length para calcular el tamaño de la solicitud.

El servidor web Caddy escrito en Go también era vulnerable porque usaba la misma biblioteca net / http. Los desarrolladores confirmaron que después de actualizar GO y reconstruir el paquete, el problema desaparece.

El autor de este artículo encontró un problema similar en el servidor lighthttpd (no se asignó CVE). La captura de pantalla muestra que el servidor acepta y procesa el encabezado que contiene un espacio:

Los desarrolladores no están del todo de acuerdo con RFC 7230 (y el autor también), y creen que la responsabilidad del procesamiento incorrecto de los encabezados recae en los proxies que envían las solicitudes sin normalizarlas y verificarlas. Sin embargo, el error se solucionará en la nueva versión:

De forma predeterminada, lighttpd analiza (y normaliza) las solicitudes antes de enviarlas por proxy a los backends. Hacerlo frustra los ataques mencionados en https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn a los servidores aguas arriba de lighttpd.
Sin embargo, como mencionó anteriormente stbuehler, los servidores proxy posteriores a lighttpd podrían pasar cualquier cosa a lighttpd.
El cambio que se realizará en la próxima versión de lighttpd será rechazar las solicitudes con espacio o tabulación después del nombre del campo y antes de los dos puntos, pero solo cuando lighttpd esté configurado en el modo (predeterminado) del análisis estricto del encabezado http.

Se encontró el mismo error en el servidor web cheroot utilizado por el framework cherrypy. Este mini-framework se encuentra en startups, a menudo se usa para escribir API. El informe de error se cuelga en el estado abierto.

Condiciones necesarias y suficientes para la vulnerabilidad.

Entonces, ¿cuáles son las condiciones necesarias para verificar y explotar la vulnerabilidad?

• Solicitud POST. Aunque el RFC no prohíbe explícitamente el uso de encabezados Content-Length y Transfer-Encoding para solicitudes GET, de hecho, solo se usan en solicitudes POST.
• La presencia de servidores frontend y backend: si no hay ninguno, no habrá nada que sincronizar.
• Los servidores web deben analizar el encabezado Transfer-Encoding de manera diferente, es decir, uno debe "leerlo" y el segundo debe ignorarse.

Pruebas de laboratorio

Para una mejor comprensión y resolución de problemas en servidores web y servidores proxy existentes, es aconsejable implementar un entorno de prueba localmente con Docker.

Un ejemplo de un diagrama de entorno de prueba:

Código de aplicación:

 from flask import Flask, request, jsonify app = Flask(__name__) @app.route('/', methods=['GET', 'POST']) def main(): # the next line is required for Transfer-Encoding support in the request request.environ['wsgi.input_terminated'] = True headers = {} for header in request.headers: headers[header[0]] = header[1] print (request.data) print (headers) return jsonify(body=str(request.data), headers=headers) 

Archivo con configuraciones frontend, por ejemplo, caddy:

 localhost:80 log ../access.log proxy / host.docker.internal:8888 

Entonces todo es simple, ejecuta la aplicación:

 gunicorn --keep-alive 10 -k gevent --bind 0.0.0.0:8888 -w 4 backend:app 

Y contenedor:

 docker run -d -t --name caddy -p 80:80 -p 443:443 -v /Users/sun/work/caddyfile:/etc/Caddyfile abiosoft/caddy:latest 

Desde la tienda Burp, instalamos HTTP Request Smuggler y Logger ++ para facilitar la depuración. A continuación en Repeater formamos una solicitud simple, por ejemplo esto:

 POST / HTTP/1.1 Host: localhost Content-Length: 8 Connection: close body=123 

Y envíelo para verificar que todo esté configurado correctamente:

 HTTP/1.1 200 OK Content-Length: 202 Content-Type: application/json Date: Mon, 07 Oct 2019 13:17:18 GMT Server: Caddy Server: gunicorn/19.9.0 Connection: close {"body":"b'body=123'","headers":{"Accept-Encoding":"gzip","Connection":"close","Content-Length":"8","Host":"host.docker.internal:8888","User-Agent":"Go-http-client/1.1","X-Forwarded-For":"172.17.0.1"}} 

Ahora inicie Launch Smuggle Probe y mire las respuestas.

Lo más interesante comienza en este momento. Es necesario analizar las solicitudes y respuestas para comprender si los servicios son vulnerables o no. Esta parte se deja para el lector curioso.