Introducción a la Técnica TE.TE
Transfer Encoding Obfuscation, también conocida como TE.TE significa Transfer-Encoding/Transfer-Encoding. Al contrario que los métodos CL.TE o TE.CL, la técnica TE.TE surge cuando ambos servidores (front y back) usan el header Transfer-Encoding. En la técnica TE.TE, el atacante se aprovecha de la inconsistencia en el manejo de TE en los headers HTTP.
La vulnerabilidad no siempre requiere múltiples headers TE. En su lugar, involucra un solo TE malformado que es interpretado diferentemente por los servidores front y back. En algunos casos, el servidor frontend puede ignorar o separar la parte malformada del header y procesar la petición de forma normal, mientras que el servidor backend puede interpretarla diferentemente llevando a request smuggling.
Ejemplo: Un atacante manipula el header TE incluyendo "chunked" en variantes malformadas. Esto es hecho para explotar cómo el front y el back priorizan el header TE sobre CL. Crafteando headers TE malformados, el atacante intenta hacer que un servidor ignore el header TE y use el CL en su lugar, llevando a discrepancia en cómo se interpretan las fronteras entre el servidor front y el back. Esta manipulación puede resultar tanto en una situación CL.TE o TE.CL, dependiendo de qué servidor vuelva a usar CL.
Explotar TE.TE para Request Smuggling
Para explotar la técnica TE.TE, un atacante puede craftear una petición que incluye headers TE que usan diferentes encodings. Por ejemplo, un atacante puede mandar una petición como:
POST / HTTP/1.1 Host: example.com Content-length: 4 Transfer-Encoding: chunked Transfer-Encoding: chunked1 4e POST /update HTTP/1.1 Host: example.com Content-length: 15 isadmin=true 0
En el payload de arriba, el servidor frontend encuentra dos headers Transfer-Encoding. El primero es un encoding chunk estándar, pero el segundo es chunked1, no es estándar. Dependiendo de la configuración, el servidor frontend puede procesar la petición basado en el primer header Transfer-Encoding: chunked e ignorar el malformado chunked1, interpretando todo como un sólo mensaje hasta el 0.
EL servidor backend, sin embargo, puede que gestione el header malformado Transfer-Encoding: chunked1 de forma diferente. Podría tanto como rechazarlo como interpretar la petición de forma diferente debido a la presencia de un header no estándar. Si procesa sólo los primeros 4 bytes como se indica por el Content-Length: 4, la parte restante de la petición empezando por POST /update se trata como una petición nueva.
La petición contrabandeada tiene el parámetro isadmin=true procesado por el backend como si fuera una petición legítima. Esto podría llevar a acciones no autorizadas o demás dependiendo de la utilidad de /update en el servidor.