HTTP Response Smuggling / Desync
A técnica deste post foi retirada do vídeo: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Dessincronização da Fila de Requisições HTTP
Em primeiro lugar, esta técnica abusa de uma vulnerabilidade de Smuggling de Requisições HTTP, então você precisa saber o que é isso:
A principal diferença entre esta técnica e um Smuggling de Requisições HTTP 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 enviando 2 requisições completas para dessincronizar a fila de respostas dos proxies, em vez de enviar 1 requisição e meia para abusar do Smuggling de Requisições HTTP.
Isso ocorre porque vamos ser capazes de dessincronizar a fila de respostas para que a resposta da requisição legítima da vítima seja enviada ao atacante, ou injetando conteúdo controlado pelo atacante na resposta para a vítima.
Dessincronização de Pipelines HTTP
O HTTP/1.1 permite solicitar recursos diferentes sem precisar esperar pelos anteriores. Portanto, se houver um proxy no meio, é tarefa dos proxies manter uma correspondência sincronizada das requisições enviadas ao backend e das respostas provenientes dele.
No entanto, há um problema de dessincronização da fila de respostas. Se um atacante enviar um ataque de Smuggling de Resposta HTTP e as respostas para a requisição inicial e a contrabandeada forem respondidas imediatamente, a resposta contrabandeada não será inserida na fila da resposta da vítima, mas será simplesmente descartada como um erro.
Portanto, é necessário que a requisição contrabandeada leve mais tempo para ser processada no servidor de backend. Portanto, no momento em que a requisição contrabandeada for processada, a comunicação com o atacante terá terminado.
Se, nesta situação específica, uma vítima enviou uma requisição e a requisição contrabandeada for respondida antes da requisição legítima, a resposta contrabandeada será enviada à vítima. Portanto, 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 da vítima (que pode conter, por exemplo, o cabeçalho Set-Cookie).
Múltiplas Injeções Aninhadas
Outra diferença interessante com o Smuggling de Requisições HTTP comum é que, em um ataque de contrabando 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 Smuggling de Resposta HTTP, como você está enviando requisições completas, você pode injetar em uma carga útil dezenas de respostas que irão dessincronizar 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 poderia 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 no servidor leve muito tempo para ser processada.
Esta requisição demorada é suficiente se você apenas quiser 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 Smuggling de Requisições HTTP, em seguida a requisição demorada e então 1 ou mais requisições de carga útil cujas respostas serão enviadas para as vítimas.
Abusando da Dessincronização da Fila de Respostas HTTP
Capturando requisições de outros usuários
Assim como com as cargas úteis conhecidas de Smuggling de Requisições HTTP, 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 uma carga útil contendo uma requisição POST final com o parâmetro refletido no final e um grande Content-Length
Então, uma vez que a requisição inicial (azul) foi processada e enquanto a sonolenta está sendo processada (amarela), 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, nesse meio tempo, o atacante enviar outra requisição, a resposta da requisição de conteúdo refletido será enviada para ele.
Dessincronização de Respostas
Até este ponto, aprendemos como abusar de ataques de Smuggling de Requisições HTTP 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 dessincronizar 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 das respostas e que devem (devem) 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 para a vítima, mas irá aguardar por algum conteúdo, que na verdade será a 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 solicitação cuja resposta o alvo vai receber e que uma resposta HEAD geralmente contém em seus cabeçalhos o Content-Type e o Content-Length, você pode enviar uma solicitação como a seguinte para causar XSS no alvo sem que a página seja vulnerável ao XSS:
Envenenamento de Cache
Abusando do ataque de Confusão de Conteúdo de resposta descomentado anteriormente, se o cache armazenar a resposta à solicitação feita pelo alvo e essa resposta for injetada causando um XSS, então o cache estará envenenado.
Solicitação maliciosa contendo o payload XSS:
Resposta maliciosa ao alvo que contém o cabeçalho que indica ao cache para armazenar a resposta:
Note que neste caso, se o "alvo" for o atacante, ele pode agora realizar envenenamento de cache em URLs arbitrárias pois ele pode controlar a URL que será armazenada em cache com a resposta maliciosa.
Decepção de Cache Web
Este ataque é semelhante ao anterior, mas em vez de injetar um payload dentro do cache, o atacante irá armazenar informações do alvo 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 alcançar isso, o atacante precisa encontrar um endpoint da aplicação web que esteja refletindo alguns valores dentro da resposta e saber o comprimento do conteúdo da resposta HEAD.
Ele enviará um exploit como:
Após a resolução da primeira solicitação e o envio de volta ao atacante, a solicitação do alvo é adicionada à fila:
O alvo receberá como resposta o HEAD response + o conteúdo da resposta da segunda solicitação (contendo parte dos dados refletidos):
No entanto, observe 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 solicitação do segundo alvo irá receber como resposta algo completamente criado pelo atacante. Como a resposta é completamente criada pelo atacante, ele também pode fazer o cache do proxy da resposta.
Last updated
