Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-connection-contamination.md
carlospolop 63bd9641c0 f
2023-06-05 20:33:24 +02:00

8.7 KiB
Raw Blame History

Contaminación de Conexión HTTP

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

El contenido de este post fue tomado de https://portswigger.net/research/http-3-connection-contamination****

Los navegadores web utilizan la coalescencia de conexión HTTP, lo que les permite reutilizar una única conexión HTTP/2+ para solicitudes que van a diferentes sitios web, siempre y cuando los sitios se resuelvan a la misma dirección IP y utilicen un certificado TLS válido para ambos nombres de host.

El enrutamiento de la primera solicitud es un comportamiento peligroso de proxy inverso donde el proxy analiza la primera solicitud en una conexión para averiguar a qué extremo de back-end dirigirla, y luego envía todas las solicitudes posteriores en esa conexión al mismo extremo de back-end.

La coalescencia de conexiones y el enrutamiento de la primera solicitud no funcionan bien juntos. Por ejemplo, imagina que secure.example.com y wordpress.example.com están detrás de un proxy inverso que utiliza un 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

Si un navegador intenta enviar una solicitud a wordpress.example.com seguido de secure.example.com, la combinación de conexiones del navegador forzará ambas solicitudes en una sola conexión al front-end. El enrutamiento de la primera solicitud resultará en que la solicitud a secure.example.com sea incorrectamente enrutada al back-end de WordPress. Esto significa que si encuentras XSS en wordpress.example.com, ¡puedes usarlo 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()'

Puedes explorar la coalescencia de conexiones por ti mismo utilizando el gráfico de tiempos en la pestaña de Red de las herramientas de desarrollo de Chrome (o utilizando WireShark si eres un masoquista). Emite pares de solicitudes utilizando fetch() y observa si el gráfico muestra tiempo invertido en 'Conexión inicial' para la segunda solicitud, y si la columna de ID de conexión coincide:

{% code overflow="wrap" %}

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

{% endcode %}

No he invertido el tiempo necesario para explorar esta amenaza en profundidad o buscarla en la naturaleza, ya que creo que actualmente es rara por dos razones. En primer lugar, el enrutamiento de la primera solicitud es relativamente poco común y la complejidad de la implementación de HTTP/2 significa que solo hay un pequeño conjunto de servidores HTTP/2 únicos en comparación con HTTP/1.1. En segundo lugar, la coalescencia de conexiones significa que los servidores HTTP/2 que realizan el enrutamiento de la primera solicitud pueden interrumpirse intermitentemente para los visitantes genuinos, por lo que los propietarios pueden terminar solucionando la vulnerabilidad sin necesidad de que el atacante lo aliente.

Dicho esto, no todo son malas noticias para los atacantes. HTTP/3 propone eliminar el requisito de una coincidencia de dirección IP, lo que expondrá a todos aquellos que tengan un front-end que use el enrutamiento de la primera solicitud y tenga un certificado válido para varios hosts.

Esto también crea un segundo riesgo que no está relacionado con el enrutamiento de la primera solicitud: significa que un servidor comprometido con un certificado comodín ya no requiere un MITM para explotarlo. En efecto, esto aumenta enormemente el conjunto de actores malintencionados que podrían beneficiarse de ello.

Para evitar estos riesgos antes de que se conviertan en una realidad, asegúrese de que sus proxies inversos no realicen el enrutamiento de la primera solicitud. Puede probar esto manualmente en Repeater habilitando la reutilización de conexiones HTTP/1 y HTTP/2, y también buscarlo utilizando el ataque 'Connection-State' en HTTP Request Smuggler. Además, tenga en cuenta que si bien los certificados TLS comodín nunca han sido ideales, HTTP/3 significa que un servidor comprometido con un certificado comodín ahora se puede utilizar para atacar dominios hermanos sin un MITM activo.

Estas nuevas amenazas continúan la tendencia actual de que la infraestructura web se convierta en un enredo muy entrelazado donde una debilidad en cualquier sitio individual tiene numerosos efectos secundarios no obvios en la seguridad del sistema en general. Será interesante ver cómo se desarrollan estos riesgos en la práctica.

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