bahruzjabiyev/t-reqsBasado en gramática fuzzer HTTP/1 con capacidad de mutación
T-Reqs (Two Requests) es un Fuzzer de HTTP basado en gramáticas escrito como parte del artículo titulado "T-Reqs: HTTP Request Smuggling with Differential Fuzzing" que fue presentado en ACM CCS 2021.
BibTeX del artículo:
@inproceedings{ccs2021treqs,
title={T-Reqs: HTTP Request Smuggling with Differential Fuzzing},
author={Jabiyev, Bahruz and Sprecher, Steven and Onarlioglu, Kaan and Kirda, Engin},
booktitle={Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security},
pages={1805--1820},
year={2021}
}
T-Reqs sirve para fuzzear servidores HTTP mediante el envío de peticiones HTTP mutadas con versiones 1.1 y anteriores. Tiene tres componentes principales: 1) generar entradas, 2) mutar las entradas generadas y 3) entregarlas al servidor(es) objetivo.
Se utiliza una gramática CFG alimentada al fuzzer para generar peticiones HTTP. Como la gramática de ejemplo que se muestra a continuación está diseñada para el fuzzing de la línea de petición, cada componente de la línea de petición y los valores posibles para cada uno se especifican explícitamente. Esto nos permite generar peticiones válidas con diversas formas de línea de petición y también tratar cada componente de la línea de petición como una unidad separada desde la perspectiva de la mutación.
'<start>':
['<request>'],
'<request>':
['<request-line><base><the-rest>'],
'<request-line>':
['<method-name><space><uri><space><protocol><separator><version><newline>'],
'<method-name>':
['GET', 'HEAD', 'POST', 'PUT', 'DELETE', 'CONNECT', 'OPTIONS', 'TRACE', 'PATCH'],
'<space>':
[' '],
'<uri>':
['/_URI_'],
'<protocol>':
['HTTP'],
'<separator>':
['/'],
'<version>':
['0.9', '1.0', '1.1'],
'<newline>':
['\r\n'],
'<base>':
['Host: _HOST_\r\nConnection:close\r\nX-Request-ID: _REQUEST_ID_\r\n'],
'<the-rest>':
['Content-Length: 5\r\n\r\nBBBBBBBBBB'],
Cada componente se puede marcar de dos maneras: mutable como cadena y mutable como árbol (ver la configuración de ejemplo). Si un componente es mutable como cadena, entonces se puede eliminar, reemplazar o insertar un carácter aleatorio en una posición aleatoria. En el ejemplo que se muestra a continuación (lado izquierdo), el último carácter en la versión del protocolo (1) se elimina, la tercera letra en el nombre del método (S) se reemplaza por R, y se inserta una barra diagonal al comienzo de la URI. Mientras que, si un componente es mutable como árbol, entonces se puede eliminar, reemplazar o insertar un componente aleatorio en una posición aleatoria bajo ese componente. El ejemplo a continuación (lado derecho) muestra tres mutaciones de árbol aplicadas al componente de la línea de petición: 1) método se reemplaza por protocolo, 2) se inserta una URI extra después de la URI actual, y 3) el proto existente se elimina.
El fuzzer debe ser informado sobre las preferencias del usuario acerca de la generación y mutación de entradas. Más específicamente, la gramática de entrada, los componentes mutables, las preferencias de mutación, entre otras cosas, deben especificarse en el archivo de configuración (ver un ejemplo de configuración).
Para poder reproducir las entradas generadas y mutadas en cada iteración, se utiliza un número semilla. De hecho, este número semilla sirve como semilla para las generaciones de números aleatorios durante la formación y mutación de una entrada. Dependiendo de cómo se alimenten estas semillas al fuzzer, este se ejecuta en uno de estos dos modos: individual y por lotes. En el modo individual, las entradas se generan y mutan en base a las semillas especificadas por un usuario. En el comando a continuación, se especifica una sola semilla (es decir, 505). Alternativamente, se podría especificar una lista de semillas con la opción -f (ver la página de ayuda para más).
python3 main.py -i -c config -s 505
Mientras que, en el modo por lotes (que es el predeterminado), comienza desde cero como valor de la semilla y lo incrementa en cada iteración hasta alcanzar el número final. Los números de inicio y fin se pueden personalizar.
python3 main.py -c config
También compartimos un Dockerfile para que puedas ejecutar el código de t-reqs. Puedes ejecutar los comandos a continuación para comenzar:
# ejecuta el comando a continuación en el directorio que contiene el Dockerfile
docker build -t test/treqs .
# crea un contenedor después de haber construido la imagen usando el comando anterior
docker run -ti test/treqs bash
# ejecuta los comandos a continuación en el shell de Docker iniciado
cd t-reqs/
python3 code/main.py -c config -n -i -s90
HTTP Request Smuggling se basa en diferentes comportamientos de análisis del cuerpo entre servidores, donde un servidor usa la cabecera Transfer-Encoding mientras que el otro prefiere la cabecera Content-Length para decidir los límites del cuerpo de una petición, o un servidor ignora el cuerpo de una petición, mientras que el otro lo procesa.
Para analizar el análisis del cuerpo de los servidores en respuesta a varias mutaciones en diversas formas de una petición HTTP, necesitamos tener un mecanismo de retroalimentación instalado en esos servidores que nos informe sobre el comportamiento del análisis del cuerpo. Una forma de instalar un mecanismo de retroalimentación en un servidor es ejecutar el servidor en modo proxy inverso y hacer que reenvíe las peticiones a un script "proveedor de retroalimentación" que se ejecuta como un servicio. Este servicio mide la longitud del cuerpo en las peticiones recibidas y la guarda para compararla más tarde con otros servidores.
Un script de ejemplo "proveedor de retroalimentación" está disponible en este repositorio. Sin embargo, este script envía la información de la longitud del cuerpo de vuelta en una respuesta asumiendo que esta información se almacena en el lado del cliente.
T-Reqs está bajo licencia MIT.