Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 21:53:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-response-smuggling-desync.md

11 KiB
Raw Blame History

HTTP Response Smuggling / Desync

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

Outras formas de apoiar o HackTricks:

Desincronização da Fila de Requisições HTTP

Primeiramente, esta técnica abusa de uma vulnerabilidade de HTTP Request Smuggling, então você precisa saber o que é isso:

A principal diferença entre esta técnica e um HTTP Request Smuggling comum é que em vez de atacar a requisição da vítima adicionando um prefixo a ela, vamos vazar ou modificar a resposta que a vítima recebe. Isso é feito, em vez de enviar 1 requisição e meia para abusar do HTTP Request Smuggling, enviando 2 requisições completas para desincronizar a fila de respostas dos proxies.

Isso porque vamos conseguir desincronizar a fila de respostas de modo que a resposta da requisição legítima da vítima seja enviada ao atacante, ou injetando conteúdo controlado pelo atacante na resposta à vítima.

Desync de Pipeline HTTP

HTTP/1.1 permite solicitar diferentes recursos sem precisar esperar pelos anteriores. Portanto, se houver um proxy no meio, é tarefa do proxy manter uma correspondência sincronizada das requisições enviadas ao backend e das respostas recebidas dele.

No entanto, há um problema ao desincronizar a fila de respostas. Se um atacante enviar um ataque de HTTP Response Smuggling e as respostas para a requisição inicial e a contrabandeada forem respondidas imediatamente, a resposta contrabandeada não será inserida na fila de respostas da vítima, mas será descartada como um erro.

Portanto, é necessário que a requisição contrabandeada leve mais tempo para ser processada dentro do servidor backend. Assim, quando a requisição contrabandeada for processada, a comunicação com o atacante já terá terminado.

Se nessa situação específica uma vítima enviou uma requisição e a resposta à requisição contrabandeada for respondida antes da requisição legítima, a resposta contrabandeada será enviada à vítima. Assim, o atacante estará controlando a requisição "realizada" pela vítima.

Além disso, se o atacante então realizar uma requisição e a resposta legítima à requisição da vítima for respondida antes da requisição do atacante. A resposta à vítima será enviada ao atacante, roubando a resposta destinada à vítima (que pode conter, por exemplo, o cabeçalho Set-Cookie).

Injeções Aninhadas Múltiplas

Outra diferença interessante com o HTTP Request Smuggling comum é que, em um ataque de smuggling comum, o objetivo é modificar o início da requisição da vítima para que ela execute uma ação inesperada. Em um ataque de HTTP Response Smuggling, como você está enviando requisições completas, você pode injetar em um payload dezenas de respostas que irão desincronizar dezenas de usuários que estarão recebendo as respostas injetadas.

Além de poder distribuir mais facilmente dezenas de exploits entre usuários legítimos, isso também pode ser usado para causar um DoS no servidor.

Organização do Exploit

Como explicado anteriormente, para abusar desta técnica, é necessário que a primeira mensagem contrabandeada enviada ao servidor exija muito tempo para ser processada.

Esta requisição que consome tempo é suficiente se apenas quisermos tentar roubar a resposta da vítima. Mas se você quiser realizar um exploit mais complexo, esta será uma estrutura comum para o exploit.

Primeiro, a requisição inicial abusando do HTTP Request Smuggling, depois a requisição que consome tempo e então 1 ou mais requisições de payload cujas respostas serão enviadas às vítimas.

Abusando da Desincronização da Fila de Respostas HTTP

Capturando as requisições de outros usuários

Como com os payloads conhecidos de HTTP Request Smuggling, você pode roubar a requisição da vítima com uma diferença importante: Neste caso, você só precisa que o conteúdo enviado seja refletido na resposta, nenhum armazenamento persistente é necessário.

Primeiro, o atacante envia um payload contendo uma requisição POST final com o parâmetro refletido no final e um Content-Length grande

Então, uma vez que a requisição inicial (azul) foi processada e enquanto a sonolenta está sendo processada (amarelo) a próxima requisição que chega de uma vítima será anexada na fila logo após o parâmetro refletido:

Então, a vítima irá receber a resposta à requisição sonolenta e se, enquanto isso, o atacante enviar outra requisição, a resposta do conteúdo refletido será enviada a ele.

Desincronização de Resposta

Até este ponto, aprendemos como abusar de ataques de HTTP Request Smuggling para controlar a requisição cuja resposta um cliente vai receber e como você pode então roubar a resposta que era destinada à vítima.

Mas ainda é possível desincronizar ainda mais as respostas.

Existem requisições interessantes como a requisição HEAD que são especificadas para não ter nenhum conteúdo dentro do corpo da resposta e que devem (obrigatoriamente) conter o Content-Length da requisição como se fosse uma requisição GET.

Portanto, se um atacante injetar uma requisição HEAD, como nestas imagens:

Então, uma vez que a azul é respondida ao atacante, a próxima requisição da vítima será introduzida na fila:

Então, a vítima irá receber a resposta da requisição HEAD, que vai conter um Content-Length mas nenhum conteúdo. Portanto, o proxy não enviará esta resposta à vítima, mas esperará por algum conteúdo, que na verdade será resposta à requisição amarela (também injetada pelo atacante):

Confusão de Conteúdo

Seguindo o exemplo anterior, sabendo que você pode controlar o corpo da requisição cuja resposta será recebida pela vítima e que uma resposta HEAD geralmente contém em seus cabeçalhos o Content-Type e o Content-Length, você pode enviar uma requisição como a seguinte para causar XSS na vítima sem a página ser vulnerável a XSS:

Envenenamento de Cache

Abusando do ataque de desincronização de resposta e Confusão de Conteúdo comentado anteriormente, se o cache armazenar a resposta à requisição realizada pela vítima e esta resposta for uma injetada causando um XSS, então o cache está envenenado.

Requisição maliciosa contendo o payload XSS:

Resposta maliciosa à vítima que contém o cabeçalho que indica ao cache para armazenar a resposta:

{% hint style="warning" %} Note que neste caso se o "vítima" é o atacante ele pode agora realizar envenenamento de cache em URLs arbitrários pois ele pode controlar a URL que vai ser armazenada com a resposta maliciosa. {% endhint %}

Engano de Cache Web

Este ataque é semelhante ao anterior, mas em vez de injetar um payload dentro do cache, o atacante estará armazenando informações da vítima dentro do cache:

Divisão de Resposta

O objetivo deste ataque é abusar novamente da desincronização de resposta para fazer o proxy enviar uma resposta 100% gerada pelo atacante.

Para conseguir isso, o atacante precisa encontrar um ponto final da aplicação web que esteja refletindo alguns valores dentro da resposta e conhecer o comprimento do conteúdo da resposta HEAD.

Ele enviará um exploit como:

Após a primeira requisição ser resolvida e enviada de volta ao atacante, a requisição da vítima é adicionada à fila:

A vítima receberá como resposta a resposta HEAD + o conteúdo da segunda resposta à requisição (contendo parte dos dados refletidos):

No entanto, note como os dados refletidos tinham um tamanho de acordo com o Content-Length da resposta HEAD que gerou uma resposta HTTP válida na fila de respostas.

Portanto, a próxima requisição da segunda vítima estará recebendo como resposta algo completamente criado pelo atacante. Como a resposta é completamente criada pelo atacante, ele também pode fazer o proxy armazenar a resposta no cache.

Referências

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

Outras formas de apoiar o HackTricks: