December 2, 2014

DDoS attack over Load Balancer: secure your cookies!

In security analysis, we deal with various network devices, both well-known and rare ones. Among the latter, load balancers can be singled out. Today we would like to talk about session persistence methods of F5 BIG-IP load balancer. As we found out, an intruder is able to attack such a system and bypass the specified load balancing algorithm by manipulating with cookies’ value.



What is load balancer? It’s a network device that distributes application traffic between servers and allows to control and change traffic characteristics due to specified parameters. When using applications, a client session should be served by the same server. For this purpose BIG-IP monitors and saves session information, which includes an address of a certain web server that serves the client. This information is used mainly for sending client requests to one and the same web server during the session lifetime.

BIG-IP provides several persistence methods, such as cookie persistence, hash persistence, destination/source address persistence, SSL persistence. Cookie persistence is commonly used for HTTP traffic. It includes four types: HTTP cookie insert, HTTP cookie rewrite, HTTP cookie passive and cookie hash. HTTP cookie insert is the most common method, because unlike others it does not require to set up each web server to send certain cookies, and they are automatically generated by a balancer.

Let's have a look at the data that are stored in cookies sent to the client:


A cookie's name is generated as BIGipServer. The client gets information about the usage of a BIG-IP balancer and a server pool name.

Now let's have a look at a cookie's contents. It contains a reverse decimal representation of the server's IP address (4225695754) and its port (20480).

There are two methods to convert it into a more usual format:

1. Let's take the decimal value of the cookie related to the IP address and convert it into a hexadecimal format: FBDF000A.

Divide them into bytes and put in a reverse order: 0A00DFFB.

Then convert bytes into a decimal format, each byte representing an octet of the IP address:
10.0.223.251.

And on the same principle we decode the port (it contains a double-byte value):

20480→5000→0050→80

2. Type "ping 4225695754" into the command line.  The output value is 251.223.0.10.

Type the octets from the last one to the first one: 10.0.223.251.

A similar process can be used with the value of the port: ping 20480.

We obtain the following value: 0.0.80.0.

As the port is two bytes, so the first two values are to be omitted. Type the values of the last two octets from the second one to the first one: 080.

So we got the address of the server: 10.0.223.251:80.

If a member of the pool is not included in the default route domain, a different type of coding is used.


Content:

  • rd554 is route domain 554, an identifier of the route domain,
  • ac164811, a hexadecimal representation of the IP address of web server 172.22.72.17,
  • 5080, the real port of the web-server.

After completing the session (by default, they expire when the browser is closed) and getting on the site again, we can obtain information about all the servers of the pool. Such disclosure of information about the internal structure of the data center is absolutely unnecessary.

As we have mentioned, load balancers are set for correct traffic distribution. However, by manipulating with a cookie's value an intruder is able to choose a server from the pool to connect with, and thus bypassing the specified load balancing algorithm.

Let's see it in practice:

1. Change a cookie's value into the value corresponding to the required server;


 2. Send a request to the server and see that the balancer redirects us to the service with the value we specified in the previous step.


But how to protect yourself?

BIG-IP supports encryption of cookies. It is performed by AES-192 and then cookie is encoded with Base64 algorithm.

An encrypted cookie:


Encryption prevents an intruder from obtaining information about web servers' IP addresses. However, a DoS attack against a certain server is still possible, because the encrypted cookie is not associated with the client and as a result it can be used to perform an attack against a particular server from various sources (e.g. from a botnet).

At the beginning of this article, you could see the diagram showing the statistics we gathered based on 100 random web sites that use BIG-IP and cookie persistence. According to this statistics, most of the companies that use BIG-IP and cookie persistence do not take the trouble of setting additional security measures for hiding internal infrastructure data.

Written by Kirill Puzankov, Positive Research

5 comments:

  1. This information was published by F5 in following link:
    https://support.f5.com/kb/en-us/solutions/public/6000/900/sol6917.html

    the article describes how to enable cookie encryption for various software versions.

    ReplyDelete
  2. Wouldn't it just hit one server, and the rest can still do their job? Doesn't the LB know how busy the host is since it is sending the traffic there?

    And what if the attacker changed the host and port to something else that the load balance isn't supposed to connect to at all? Will a stupid LB still let the traffic go through?

    ReplyDelete
    Replies
    1. >Wouldn't it just hit one server, and the rest can still do their job?

      If the attacker only chooses to perform DDoS only on one server, yes. However, it can drop current connections and transactions that are set to this server.

      >Doesn't the LB know how busy the host is since it is sending the traffic there?

      It depends on load balancing mechanism. The default load balancing method (Round Robin) simply passes new connections to the next server in line. All other methods take server capacity and/or status into consideration.

      >And what if the attacker changed the host and port to something else that the load balance isn't supposed to connect to at all? Will a stupid LB still let the traffic go through?

      No, it only works with published services within the pool.

      Delete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete