Analisis de red mediante HTTP
Posted on 11:37 by Xianur0
Antes que nada aclaro que se requiere conocimientos previos sobre el funcionamiento del HTTP, no se va a explicar el funcionamiento, solo va a mostrar los mecanismos de analisis...
Supongamos, nosotros tenemos una transferencia HTTP con web.com. Lo que podemos ver a simple vista es la respuesta que nos da, pero mas haya, nos interesa saber como esta estructurada la conexion al servidor, es decir, que puntos/proxys/balanceadores de carga hay?
Y por que nos seria util saber eso?, por varias razones, por ejemplo si determinamos la estructura que hay, podemos analizar las reglas de cada uno de los proxys y por consiguiente utilizarlo para algo "no tan bueno". Sin mas comenzemos:
de inicio vamos a utiliza webs reales, pero ocultando las direcciones, para evitarnos problemas....
Solo llames a estas webs: www.servidor1.com y www.servidor2.com.
La prueba que siempre nos sera de utilidad es la del TRACE:
TRACE / HTTP/1.0
Host: www.servidor1.com
X: <script>alert(/xss/.source)</script>
Esta prueba nos ayudara a determinar si se edito el paquete en algun punto de la red antes de llegar al servidor, es decir, la respuesta aproximada a esta consulta deberia de ser:
HTTP/1.1 200 OK
Date: Sat, 05 Jun 2010 17:20:26 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http
50
TRACE / HTTP/1.1
Host: www.servidor1.com
X: <script>alert(/xss/.source)</script>
0
suponiendo que el servidor solo envia datos con Transfer-encoding chunked.
esto es, se responde como contenido lo que enviamos, en caso de que la respuesta sea diferente, quiere decir que tenemos algo en la red, del mismo modo podemos extraer datos de eso, es decir segun cabeceras añadidas en el envio, se pueden determinar algunas cosas, por ejemplo:
HTTP/1.0 200 OK
Date: Sat, 05 Jun 2010 17:23:46 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.12
Content-Type: message/http
X-Cache: MISS from wefwfg
X-Cache-Lookup: NONE from wefwfg:80
Via: 1.0 wefwfg:80 (squid/2.6.STABLE5)
Connection: close
TRACE / HTTP/1.0
Host: www.servidor2.com
Via: 1.1 wefwfg:80 (squid/2.6.STABLE5)
X-Forwarded-For: 189.xx.xx.xx
Cache-Control: max-age=259200
Connection: keep-alive
esto es, primero que nada podemos ver en el encabezado:
X-Cache: MISS from wefwfg
X-Cache-Lookup: NONE from wefwfg:80
Via: 1.0 wefwfg:80 (squid/2.6.STABLE5)
Para comenzar ahi podemos determinar que se utiliza un servidor proxy cache llamado wefwfg, el usa el puerto 80, y es un squid/2.6.STABLE5, de momento ya sabemos que hay un servidor proxy cache implicado, pero eso no es todo.
TRACE / HTTP/1.0
Host: www.servidor2.com
Via: 1.1 wefwfg:80 (squid/2.6.STABLE5)
X-Forwarded-For: 189.xx.xx.xx
Cache-Control: max-age=259200
Connection: keep-alive
El proxy cache agrega las cabeceras Via, X-Forwarded-For, Cache-Control y Connection.
Lo que enviamos al servidor fue (en este caso):
TRACE / HTTP/1.1
Host: www.servidor2.com
Y ese envio no coincide con lo que le llego al servidor....
Ahora otro detalle: se envio la cabecera X-Forwarded-For, con mi ip, esto quiere decir, que a simple vista, no hay otro servidor proxy antes de este squid, en otras palabras, el servidor principal, al cual nos conectamos fue: wefwfg, y este realizo la conexion al servidor donde se encuentra www.servidor2.com
Ahora nos queda determinar si se balancea la carga (es decir que hubiera mas servidores en esto...), como podriamos hacer esto?, mediante un envio recursivo de datos, lo mas comun es detectar cabeceras Date, que no coincide (es decir, fallan por 1 minuto, 1 hora, 1 año, o mas...) o alguna diferencia en otra cabecera que marque tiempo o algo similar que pueda variar en caso de tratarse de otro servidor.
Pero no estas conformes con estas tecnicas, por la simple razon de que no funcionan en todos los servidores, es decir si el proxy no edita la respuesta, si no envia via o cabeceras similares o el servidor web no soporta TRACE, entonces no funcionaran, vamos a ver algunas mas:
GET http://localhost/ HTTP/1.1
Host: localhost
Connection: Close
Proxy-Connection: Close
Esto es una trampa doble, para comenzar, se pide localhost, es decir si hay un proxy este intentara conectarse a si mismo en el puerto 80, lo cual por lo regular causaria un bucle infinito (en caso de ser un proxy sin filtro para esto), un 403 o un 500. Pero adicional a eso pueden aver algunos otros datos:
HTTP/1.1 403 Forbidden
Date: Sat, 05 Jun 2010 17:20:32 GMT
Content-Length: 257
Content-Type: text/html
Server: NetCache appliance (NetApp/5.4R2D2)
Tenemos un 403, y aparte en la cabecera Server, tenemos datos del servidor proxy, en este caso un NetCache (Version 5.4R2D2).
Ahora dije que era una trampa doble, como podran notar agrege 2 tokens para la conexion (encabezados Connection y Proxy-Connection), es decir, en caso de no recibir un 403 o 500, podemos recibir en el encabezado de la respuesta un Connection: close o un Proxy-Connection: Close.
Un servidor web comun no utiliza Proxy-Connection, un proxy si...
Ahora podemos usar eso mismo con otra clase de consultas y ayudaria bastante...
Ahora regresando a lo del balanceo de cargas, lo mas eficiente para estos casos, aparte de revisar que las cabeceras no cuadren con lo que deberian, se puede forzar al servidor a mostrarse, como?
mediante un envio recursivo de paquetes, es decir, podemos determinar cuando un servidor cambie por ciertos detalles por ejemplo:
un servidor soporta 3 paquetes por conexion persistente, es decir:
GET / HTTP/1.1
Host: servidor2.com
Connection: keep-alive
GET / HTTP/1.1
Host: servidor2.com
Connection: keep-alive
GET / HTTP/1.1
Host: servidor2.com
Connection: close
y respondera a esas 3 consultas en la misma conexion, pero a la siguiente consulta, soporta 4?, ahi detectamos que son servidores diferentes...
Otro:
Enviamos varias consultas con diferentes metodos, determinamos que metodos soporta y si en otra vuelta, no soporta algun metodo, es lo mismo, es otro servidor...
Bueno concluimos con este paper diciendo lo siguiente: la seguridad es solo un mito, los proxys invisibles no existen, siempre hay una forma de detectar cuando algo que esta ahi, no deberia estar ahi ;)...
PD: para mas informacion y mas tecnicas, asistir a mi conferencia en x25sec xd jajajaj
Saludos!, esto es todo por el momento... xD....
2 comentarios:
"therahack"
No tengo mucha idea del protocolo HTTP pero estoy aprendiendo para resolver mis dudas, para hacer las peticiones al servidor y mostrar lo que responde se hace con el nc verdad?
salu2, esperemos poder asistir a la conferencia jeje
Publicar un comentario