9.5 KiB
HTTP Response Smuggling / Desync
Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras maneiras de apoiar o HackTricks:
- Se você quiser ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF Confira os PLANOS DE ASSINATURA!
- Adquira o swag oficial PEASS & HackTricks
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @carlospolopm.
- Compartilhe seus truques de hacking enviando PRs para os HackTricks e HackTricks Cloud repositórios do github.
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, essa 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 essa 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.
Isso ocorre porque seremos 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 backend. Portanto, quando a requisição contrabandeada for processada, a comunicação com o atacante terá terminado.
Se, nessa situação específica, uma vítima enviar 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).
Injeções Aninhadas Múltiplas
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 contrabando 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 de Exploits
Como explicado anteriormente, para abusar dessa técnica, é necessário que a primeira mensagem contrabandeada no servidor leve muito tempo para ser processada.
Essa requisição demorada é suficiente se você apenas quiser tentar roubar a resposta da vítima. Mas se você quiser realizar um exploit mais complexo, essa 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 depois 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 os payloads conhecidos 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
Depois, 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 no 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á essa 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 requisição cuja resposta a vítima 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 requisição como a seguinte para causar XSS na vítima sem que a página seja vulnerável ao XSS:
Envenenamento de Cache
Abusando do ataque de Confusão de Conteúdo de dessincronização de respostas comentado anteriormente, se o cache armazenar a resposta à requisição realizada pela vítima e essa resposta for uma injetada causando um XSS, então o cache estará envenenado.
Requisição maliciosa contendo o payload XSS:
Resposta maliciosa para a 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" 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. {% endhint %}
Decepção de Cache da Web
Este ataque é semelhante ao anterior, mas em vez de injetar uma carga útil dentro do cache, o atacante estará armazenando informações da vítima dentro do cache:
Divisão de Respostas
O objetivo deste ataque é abusar novamente da dessincronização de respostas 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 está refletindo alguns valores dentro da resposta e saber o comprimento do conteúdo da resposta HEAD.
Ele enviará um exploit como:
Depois que a primeira requisição for resolvida e enviada de volta ao atacante, a requisição da vítima é adicionada à fila:
A vítima receberá como resposta o HEAD response + o conteúdo da resposta da segunda requisiçã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 requisição da segunda vítima irá receber como resposta algo completamente criado pelo atacante. Como a resposta é completamente criada pelo atacante, ele também pode fazer o proxy armazenar em cache a resposta.