Lo mismo pasará a la hora de realizar un escaneo de vulnerabilidades, podemos encontrar un servidor vulnerable, lanzarle un exploit y que el exploit se dirija a un host no vulnerable. Por el contrario, puede darse el caso de no encontrar una vulnerabilidad por haber auditado sólo un host.
Antes de pasar a ver los principales métodos de detección de balanceadores vamos a ver las principales técnicas usadas para balancear:
- Basado en DNS: basado en algoritmo round robin, cada petición es respondida con una IP distinta. Ello no quiere decir ni que sea el servidor con menos carga ni que dicho servidor esté accesible.
- Least connections: Se redirigen las peticiones al servidor con menos conexiones.
- Dicho balanceo se puede configurar para dar "pesos" a cada servidor según sus capacidades.
- Persistencia por cookie: En casos como una tienda online o un portal que se requiera un constante chequeo de credenciales se puede marcar mediante cookie una conexión "persistente" para que, una vez autenticado, tus peticiones vayan al mismo servidor y así no tener problemas con las sesiones.
- Los sistemas anteriores pueden complementarse con mecanismos como la latencia de un ping para intentar entregar el recurso solicitado desde el servidor más cercano geográficamente para intentar conseguir un mejor rendimiento.
Dicho esto vamos a ver un par de formas para detectar balanceadores de carga:
Mediante consulta DNS
Para ello bastará con realizar una consulta de tipo A y ver si se nos devuelven múltiples entradas.
z0mbiehunt3r@d3im0s:~$ dig www.tuenti.com A
;; ANSWER SECTION:
www.tuenti.com. 860 IN A 95.131.168.193
www.tuenti.com. 860 IN A 95.131.168.194
www.tuenti.com. 860 IN A 95.131.168.195
www.tuenti.com. 860 IN A 95.131.168.196
Como vemos se nos devuelven dos entradas de tipo A que corresponden a dos host de la red Akamai.
hping3
Con la herramienta hping3 podemos crear paquetes "al gusto", para realizar esta comprobación vamos a crear paquetes con la flag SYN establecida y el puerto de destino 80, para intentar abrir una conexión con el/los host remotos.
root@d3im0s:~# hping3 -S -p 80 www.f5.com
HPING www.f5.com (eth1 65.61.115.222): S set, 40 headers + 0 data bytes
len=46 ip=65.61.115.222 ttl=239 DF id=30681 sport=80 flags=SA seq=0 win=1608 rtt=221.1 ms
len=46 ip=65.61.115.222 ttl=239 DF id=34470 sport=80 flags=SA seq=1 win=1608 rtt=222.5 ms
len=46 ip=65.61.115.222 ttl=238 DF id=35460 sport=80 flags=SA seq=2 win=1608 rtt=229.4 ms
len=46 ip=65.61.115.222 ttl=239 DF id=36912 sport=80 flags=SA seq=3 win=1608 rtt=218.5 ms
len=46 ip=65.61.115.222 ttl=239 DF id=37908 sport=80 flags=SA seq=4 win=1608 rtt=223.8 ms
len=46 ip=65.61.115.222 ttl=240 DF id=38775 sport=80 flags=SA seq=5 win=1608 rtt=219.7 ms
len=46 ip=65.61.115.222 ttl=238 DF id=40694 sport=80 flags=SA seq=6 win=1608 rtt=219.9 ms
len=46 ip=65.61.115.222 ttl=239 DF id=43097 sport=80 flags=SA seq=7 win=1608 rtt=226.0 ms
Podemos observar que el IP ID devuelto no es sólo incremental o establecido a 0 siempre, sino que tenemos varios que son menores que el IP ID anterior, cosa imposible salvo que sean servidores distintos.
Load Balancing Detector
root@bt:/pentest/enumeration/lbd# ./lbd.sh www.microsoft.com
lbd - load balancing detector 0.1 - Checks if a given domain uses load-balancing.
Written by Stefan Behte (http://ge.mine.nu)
Proof-of-concept! Might give false positives.
Checking for DNS-Loadbalancing: FOUND
lb1.www.ms.akadns.net has address 207.46.170.10
lb1.www.ms.akadns.net has address 207.46.170.123
Checking for HTTP-Loadbalancing [Server]:
Microsoft-IIS/7.5
FOUND
Checking for HTTP-Loadbalancing [Date]: 21:23:54, 21:23:55, 21:23:55, 21:23:56, 21:23:56, 21:23:56, 21:23:57, 21:23:58, 21:23:58, 21:23:59, 21:23:59, 21:24:00, 21:24:00, 21:24:01, 21:24:01, 21:24:01, 21:24:03, 21:24:03, 21:24:04, 21:24:04, 21:24:05, 21:24:05, 21:24:05, 21:24:06, 21:24:06, 21:24:07, 21:24:07, 21:24:08, 21:24:08, 21:24:09, 21:24:09, 21:24:09, 21:24:11, 21:24:11, 21:24:12, 21:24:12, 21:24:13, 21:24:13, 21:24:14, 21:24:14, 21:24:14, 21:24:14, 21:24:16, 21:24:16, 21:24:16, 21:24:17, 21:24:17, 21:24:18, 21:24:18, 21:24:19, NOT FOUND
Checking for HTTP-Loadbalancing [Diff]: FOUND
< VTag: 279850942700000000
> VTag: 791860011400000000
www.microsoft.com does Load-balancing. Found via Methods: DNS HTTP[Server] HTTP[Diff]
En este caso se ha identificado balanceo de carga gracias a las diferencias introducidas en las cabeceras HTTP por cada servidor.
Cookie
z0mbiehunt3r@d3im0s:~# telnet communities.vmware.com 80
Trying 92.123.78.41...
Connected to a1005.g.akamai.net.
Escape character is '^]'.
HEAD / HTTP/1.1
HOST: communities.vmware.com
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html
Expires: Tue, 16 Nov 2010 22:02:49 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Tue, 16 Nov 2010 22:02:49 GMT
Connection: keep-alive
Set-Cookie: JSESSIONID=5CFA78E5C5959F0298E0AAFFEAF17589; Path=/
Set-Cookie: BIGipServercommunities-prod-pool=1396601098.36895.0000; expires=Tue, 16-Nov-2010 23:02:49 GMT; path=/
Connection closed by foreign host.
Como podemos observar en la imagen, a parte de usar la red Akamai, se utilizan appliances F5 BIG-IP. Existe un fallo de information disclosure que nos permite sacar las direcciones IP internas de los servidores a través de la cookie para comprobarlo usamos el plugin 20089 de Nessus.
Plugin Output
The first column is the original cookie, the second the IP address and
the third the TCP port:
BIGipServercommunities-prod-pool=1396601098.36895.0000 10.113.62.83 8080
BIGipServercommunities-prod-pool=1379823882.36895.0000 10.113.62.82 8080
BIGipServercommunities-prod-pool=1363046666.36895.0000 10.113.62.81 8080
Bueno, y hasta aquí llegó la breve introducción a la detección de balanceadores de carga, espero que os haya gustado y os haya despertado el gusanillo de comprobar distintos sitios.
Saludos!
