Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-connection-contamination.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

6.8 KiB
Raw Blame History

Contaminação de Conexão HTTP

Os navegadores da web usam o HTTP connection coalescing, que permite que eles reutilizem uma única conexão HTTP/2+ para solicitações que vão para diferentes sites, desde que os sites resolvam para o mesmo IP e usem um certificado TLS válido para ambos os nomes de host.

O roteamento da primeira solicitação é um comportamento perigoso de proxy reverso em que o proxy analisa a primeira solicitação em uma conexão para descobrir qual back-end roteá-la e, em seguida, envia todas as solicitações subsequentes nessa conexão para o mesmo back-end.

A coalescência de conexão e o roteamento da primeira solicitação não funcionam bem juntos. Por exemplo, imagine que secure.example.com e wordpress.example.com estão ambos atrás de um proxy reverso usando um certificado válido para *.example.com:

$ nslookup wordpress.example.com
52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing

$ nslookup secure.example.com
52.16.179.7 // same reverse proxy

$ openssl s_client -connect x.portswigger-labs.net:443
subject=/CN=*.example.com // wildcard TLS certificate

Se um navegador tentar enviar uma solicitação para wordpress.example.com seguido por secure.example.com, a coalescência de conexão do navegador forçará ambas as solicitações em uma única conexão para o front-end. O roteamento da primeira solicitação resultará na solicitação para secure.example.com ser incorretamente roteada para o back-end do WordPress. Isso significa que se você encontrar XSS em wordpress.example.com, você pode usá-lo para comprometer secure.example.com!

// create HTTP/2+ connection
fetch('https://wordpress.example.com/', {credentials: 'include'})

// connection coalescing will force this down the same connection...
// ...leading to the front-end misrouting it to WordPress
// the browser thinks our injected JS is coming from secure.example.com
// exposing saved passwords, cookies, etc.
location='https://secure.example.com/plugin/x?q=<script>stealPasswords()'

Você pode explorar a coalescência de conexão por si mesmo usando o gráfico de tempo na aba Network nas ferramentas de desenvolvedor do Chrome (ou usando o WireShark se você é um masoquista). Emita pares de solicitações usando fetch() e veja se o gráfico mostra o tempo gasto na 'Conexão inicial' para a segunda solicitação, e se a coluna ID de conexão corresponde:

{% code overflow="wrap" %}

fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

{% endcode %}

Não investi o tempo necessário para explorar essa ameaça em profundidade ou procurá-la na natureza, pois acredito que atualmente é rara por duas razões. Em primeiro lugar, o roteamento de primeira solicitação é relativamente incomum e a complexidade de implementação do HTTP/2 significa que há apenas um pequeno conjunto de servidores HTTP/2 exclusivos em relação ao HTTP/1.1. Em segundo lugar, a coalescência de conexão significa que os servidores HTTP/2 que executam o roteamento de primeira solicitação podem quebrar intermitentemente para visitantes genuínos, então os proprietários podem acabar corrigindo a vulnerabilidade sem incentivo do atacante.

Dito isso, nem tudo são más notícias para os atacantes. O HTTP/3 propõe remover o requisito de correspondência de endereço IP, o que exporá todos que possuem um front-end que usa o roteamento de primeira solicitação e tem um certificado válido para vários hosts.

Isso também cria um segundo risco que não está relacionado ao roteamento de primeira solicitação - significa que um servidor comprometido com um certificado curinga não requer mais um MITM para ser explorado. Na prática, isso aumenta muito o número de atores mal-intencionados que podem se beneficiar disso.

Para evitar esses riscos antes que se tornem realidade, certifique-se de que seus proxies reversos não executem o roteamento de primeira solicitação. Você pode testar isso manualmente no Repeater, habilitando o reuso de conexão HTTP/1 e HTTP/2, e também procurar por isso usando o ataque 'Connection-State' em HTTP Request Smuggler. Além disso, esteja ciente de que, embora os certificados TLS curinga nunca tenham sido ideais, o HTTP/3 significa que um servidor comprometido com um certificado curinga agora pode ser usado para atacar domínios irmãos sem um MITM ativo.

Essas novas ameaças continuam a tendência contínua de infraestrutura da web se transformando em uma bagunça altamente entrelaçada, onde uma fraqueza em qualquer site individual tem numerosos efeitos colaterais não óbvios na segurança do sistema geral. Será interessante ver como esses riscos se desenrolam na prática.

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥