Operation n

Load Balancer Enumeration
author: david.kierznowski_at_gmail.com
http://michaeldaw.org

Table of Contents:
0. Introduction
1. Dynamic DNS
2. Proxies
2a. Cookie Analysis
2b. Web Server Configuration issues
2c. Using the TCP/IP Stack
2d. Using HTTP Date: field
3. References

0. Introduction

Load balancing (performed by a load balancer) is a type of service performed by a computer that assigns work loads to a set of networked computer servers in such a manner that the computing resources are used in an optimal manner - wikipedia

As touched upon in “http://michaeldaw.org/news/news-091006-0/”, detecting load balancing is crucial to the security of any web application, yet I have heard very little by way of security testing in this area.

This article will discuss some ideas around detecting load balancers but more importantly I will share some techniques to enumerate the web servers behind these load balancers. None of the ideas in this article are new, but offer a collection of techniques that I have often found useful.

Note: I do not presume this article to be the end all on the subject, but I hope to encourage the reader to find new and effective techniques to not only detect load balancers, but also to be able to distinctly identify the targets behind the load balancer.

1. Dynamic DNS Load Balancing

./check-dns.sh
Connecting to [www.google.com] [20] times
www.l.google.com has address 64.233.183.103
www.l.google.com has address 64.233.183.104
www.l.google.com has address 64.233.183.147
www.l.google.com has address 64.233.183.99
www.l.google.com has address 66.249.85.104
www.l.google.com has address 66.249.85.99

check-dns.sh source here.

As seen above, DNS load balancing is the easiest to spot. It is also one of the easiest to test for as each web server has an external IP address.

2. Proxies

Proxy type load balancers (i.e. Apache Tomcat, F5’s BIG-IP) typically forward connections to a cluster of web servers. This can be done sequentially, randomly or by more advanced methods such as by bandwidth utilisation etc.

Unlike DNS load balancing, proxies require a method to maintain state (as HTTP is stateless). It is because of this that our techniques in load balancing enumeration once again branch off. These include:
a. Cookie Analysis
b. Web Server Configuration issues
c. Using the TCP/IP Stack
d. Using HTTP Date: Field

2a. Cookie Analysis

This is fairly straight forward. A number of popular load balancers use cookies to maintain state and ultimately manage its connections.

F5’s BIG-IP Load Balancer demonstrates this nicely:

Set-Cookie:BIGipServer[poolname]=336268299.20480.0000;expires=Sat,01-Jan-200200:00:00
GMT;path=/

The [poolname] variable above represents an encoding (d*(256^3)+c*(256^2)+b*256+a) of the IP address and port of the server.
See http://www.nessus.org/plugins/index.php?view=viewsrc&id=20089

2b. Web Server Configuration issues

Web server configuration vulnerabilities can be used to detect load balancing and determine the internal IP addresses (in some cases) of the internal web servers. The following example demonstrates this:

GET / HTTP/1.0

HTTP/1.1 302 Object Moved
Location: http://172.16.14.25/
Server: Microsoft-IIS/5.0
Content-Type: text/html
Content-Length: 148

--snip--
This document may be found
<a HREF=”http://172.16.25.140/pdf/”;>here</a>
–snip–

2c. Using the TCP/IP Stack

Observing and watching IPID increments can often tip you off that multiple stacks are being used.
Example:

$ hping2 *hidden* -S -p 80 -i u1000 -c 30
HPING *hidden* (eth0 x.x.x.x): S set, 40 headers + 0 data bytes
len=46 ip=*hidden* ttl=51 DF id=58489 sport=80 flags=SA seq=0 win=24656 rtt=203.9 ms
len=46 ip=*hidden* ttl=51 DF id=16912 sport=80 flags=SA seq=2 win=24656 rtt=200.1 ms
len=46 ip=*hidden* ttl=51 DF id=58490 sport=80 flags=SA seq=3 win=24656 rtt=197.2 ms
len=46 ip=*hidden* ttl=51 DF id=16913 sport=80 flags=SA seq=4 win=24656 rtt=194.2 ms
len=46 ip=*hidden* ttl=51 DF id=58491 sport=80 flags=SA seq=5 win=24656 rtt=204.0 ms
len=46 ip=*hidden* ttl=51 DF id=16914 sport=80 flags=SA seq=7 win=24656 rtt=199.1 ms

2d. Using HTTP Date: field

Discrepancies in the web server’s ‘Date:’ field.
Example:

# ./check-date.sh
Connecting to [*hidden*] [10] times
Date: Mon, 20 Nov 2006 21:30:30 GMT
Date: Mon, 20 Nov 2006 21:28:22 GMT
Date: Mon, 20 Nov 2006 21:28:23 GMT
Date: Mon, 20 Nov 2006 21:28:24 GMT
Date: Mon, 20 Nov 2006 21:30:43 GMT
Date: Mon, 20 Nov 2006 21:30:44 GMT
Date: Mon, 20 Nov 2006 21:30:45 GMT
Date: Mon, 20 Nov 2006 21:30:45 GMT
Date: Mon, 20 Nov 2006 21:30:46 GMT
Date: Mon, 20 Nov 2006 21:30:47 GMT

check-date.sh source here.

3. References:

http://content.websitegear.com/article/load_balance_dns.htm
http://en.wikipedia.org/wiki/Load_balancer
http://michaeldaw.org/news/news-091006-0/
http://www.nessus.org/plugins/index.php?view=viewsrc&id=20089
F5’s BIG-IP Load Balancer
http://www.hping.org/

Appendix

check-dns.sh Source:

#!/bin/sh

# PoC: DNS Load Balancer Check

TARGET="www.google.com"
TIMES=20

echo "Connecting to [$TARGET] [$TIMES] times";

for ((i=0; i<$TIMES; i++)); do
 host www.google.com | grep address >> ,dns.txt;
done

 cat ,dns.txt | sort -u

check-date.sh Source:

#!/bin/sh

# PoC: Grab 'Date:' field from web server

TARGET="www.microsoft.com"
TIMES=10

echo "Connecting to [$TARGET] [$TIMES] times";

for ((i=0; i<$TIMES; i++)); do
 echo -e 'HEAD / HTTP/1.0\r\n\r\n' | nc $TARGET 80 | grep 'Date:';
done