# Contrabando de Requisições em Downgrades de HTTP/2
Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Origens
A principal origem dessa vulnerabilidade é o fato de que o **reverse proxy** vai **comunicar-se com o cliente** usando **HTTP/2** mas depois vai **transformar** essa **comunicação** com o **servidor back-end** para **HTTP/1.1**.
![](<../../.gitbook/assets/image (636) (1).png>)
O problema com essa abordagem é que o **usuário** vai poder **injetar** **headers** desnecessários na **comunicação HTTP/2** que provavelmente **não serão verificados** pelo proxy. Mas então, quando esses são **injetados cegamente na comunicação HTTP/1.1**, **um ataque de contrabando de requisições pode ser realizado**.
## Exemplos
### Desincronização H2.CL
A especificação do HTTP/2 indica que o **header Content-Length não é necessário, mas pode ser indicado**. Portanto, o **reverse proxy** vai **tratar todo o conteúdo enviado pelos usuários** como a requisição, mas então, ao **rebaixar para HTTP/1.1**, esse **header** vai ser **injetado** na **requisição** e, portanto, o **back-end vai tratar a requisição como 2 requisições diferentes**, como você pode ver na imagem abaixo:
![](<../../.gitbook/assets/image (639).png>)
### Sequestro de Token de URL H2.TE Desync
A especificação do HTTP/2 também indica que **qualquer mensagem contendo campos de cabeçalho específicos da conexão DEVE ser tratada como malformada... mas se você não seguir essa regra, você está vulnerável**.
Esta técnica foi abusada no balanceador de carga da AWS, então garantir que os usuários acessem um cabeçalho Host apontando para um servidor controlado pelo atacante fará com que eles acessem esse servidor.
![](<../../.gitbook/assets/image (631) (1).png>)
### Sequestro de Cabeçalho H2.TE Desync
Esta é exatamente a mesma técnica que a anterior, mas verificando as requisições, James notou que os clientes estavam pedindo para enviar suas credenciais, então ele apenas modificou seu servidor para permitir que o CORS lhe enviasse as credenciais das pessoas:
![](<../../.gitbook/assets/image (662) (1) (1) (1) (1) (1).png>)
### H2.TE via Injeção de Cabeçalho de Requisição
**HTTP/2 também não permite colocar caracteres não permitidos nos cabeçalhos**, mas se o servidor **não respeitar** essa regra, você pode **injetar cabeçalhos arbitrários** quando a comunicação for **rebaixada** para HTTP/1.1.
Neste caso, **o cabeçalho Transfer-Encoding foi injetado**.
![](<../../.gitbook/assets/image (648) (1) (1) (1) (1) (1).png>)
### H2.TE via Injeção de Nome de Cabeçalho
HTTP/2 em alguns servidores permite colocar um **dois-pontos no nome do cabeçalho, e com um** você pode injetar um novo cabeçalho dentro do nome do cabeçalho como este:
![](<../../.gitbook/assets/image (632) (1).png>)
Note que se você colocar apenas os caracteres de nova linha enviando um cabeçalho sem conteúdo, a requisição será tratada como **inválida**:
![](<../../.gitbook/assets/image (647) (1) (1) (1).png>)
### H2.TE via Injeção de Linha de Requisição
Neste caso, a injeção foi realizada dentro da linha de requisição:
![](<../../.gitbook/assets/image (640) (1).png>)
### Injeção de Prefixo de URL
Dentro do esquema da conexão HTTP/2, você pode ser capaz de enviar uma URL completa que sobrescreverá a indicada no caminho:
![](<../../.gitbook/assets/image (661) (1) (1).png>)
### Injeção de Linha de Requisição via espaços
![](<../../.gitbook/assets/image (641) (1).png>)
## Reutilização de conexão Frontend->backend
Às vezes, você descobrirá que ao realizar um ataque de Contrabando de Requisições HTTP **você só pode atacar a si mesmo**. Isso pode ser porque o reverse proxy decidiu **usar uma conexão diferente com o servidor back-end** por IP.
Note que **mesmo** com essa **restrição** você ainda pode realizar ataques como **bypass de autorização**, vazamento de cabeçalhos internos e ataques de **decepção e envenenamento de cache**.
Geralmente essa restrição não existe, então você pode **contrabandear requisições na conexão entre o reverse proxy e o back-end** que outras pessoas estão usando, mas é até **possível** que o **proxy** não **reutilize uma conexão com conexões do mesmo IP** (restrição bastante pesada para esse tipo de ataque).
![](<../../.gitbook/assets/image (646) (1) (1).png>)
Na restrição mais pesada (sem reutilização de conexão), você detectará a vulnerabilidade com a técnica Baseada em Tempo, mas ao testá-la, você descobrirá que é um "falso positivo".
### Confirmação de Túnel
Uma maneira de **confirmar** se o **ponto final é vulnerável** mas a conexão está **dentro de um "túnel"** é **contrabandear 2 requisições completas** em 1.
O **problema** com **HTTP/1.1** é que se você **receber 2 respostas HTTP** você **não sabe** se o ponto final era **vulnerável** ou não e a **requisição "contrabandeada" foi apenas tratada como uma requisição regular**.
No entanto, esta técnica pode ser usada **em HTTP/2** porque se o ponto final era **vulnerável** e você contrabandeou uma requisição, você verá os **cabeçalhos da resposta à requisição contrabandeada na resposta do reverse proxy**:
![](<../../.gitbook/assets/image (652) (1) (1) (1).png>)
### Problema de Visão de Túnel
Pode haver outro problema, se a **resposta** à requisição legítima **contiver** um **Content-Length**, o **reverse proxy** só vai **ler os bytes especificados lá e nada mais, então você não será capaz de ler a resposta da requisição contrabandeada.**
No entanto, a **requisição HEAD** **não contém um corpo** mas geralmente **contém** o **Content-Length** como se a requisição fosse um GET. Portanto, enviando uma **requisição HEAD** **em vez de uma POST** você pode **ler os bytes do Content-Length da HEAD** da resposta da requisição contrabandeada.
![](<../../.gitbook/assets/image (628) (1) (1).png>)
### Vazamento de Cabeçalhos Internos via Túnel
Se você encontrar um **parâmetro POST** dentro da aplicação cujo **conteúdo** vai ser **refletido** na **resposta**, então você pode tentar injetar caracteres HTTP/1.1 \r\n dentro de um cabeçalho de requisição HTTP/2 para que os novos cabeçalhos injetados pelo proxy sejam anexados no parâmetro POST que será refletido na resposta:
![](<../../.gitbook/assets/image (656) (1) (1).png>)
Note que neste caso o **atacante** só se importa com a **resposta** à **primeira** **requisição**, ele não precisa ler a resposta à segunda requisição contrabandeada inválida.
{% hint style="info" %}
Usando este ataque **contra diferentes partes da web (método, caminho...)** pode levar a diferentes back-ends sendo usados e **diferentes informações sensíveis sendo vazadas**
{% endhint %}
### Envenenamento de Cache via Túnel
Neste cenário, uma **requisição HEAD** para a **URL** **cujo** **cache** vai ser **envenenado** é enviada enquanto **contrabandeia** uma **requisição** cujo **conteúdo da resposta conterá o payload** (talvez algum payload XSS).
Devido ao fato de que a **resposta HEAD contém o `Content-Type: text/html`** e porque o reverse proxy acha que a **resposta inteira à requisição contrabandeada é o corpo da requisição HEAD**, o **payload XSS** vai ser **tratado como HTML** mesmo que a página não fosse vulnerável a XSS.
![](<../../.gitbook/assets/image (659) (1).png>)
## HTTP/2 Oculto
Geralmente os servidores anunciam o suporte via campo ALPN no handshake TLS, mas alguns não.
Pode ser facilmente detectado usando `curl --http2 --http2-prior-knowledge`
## Ferramentas
* Extensão Burp: HTTP Request Smuggler
* [https://github.com/neex/http2smugl](https://github.com/neex/http2smugl)
## Referências
* Esta palestra explica perfeitamente todas as técnicas indicadas aqui: [https://www.youtube.com/watch?v=rHxVVeM9R-M](https://www.youtube.com/watch?v=rHxVVeM9R-M)
Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).