DDoS-attack bypassing the balancer: protect your cookies!
In the process of analyzing the security of IT infrastructures, we have to work with different network equipment. There are well-known devices and relatively rare. Among the infrequently encountered, we can distinguish load balancers. Today we will introduce you to the mechanism of maintaining sessions of the F5 BIG-IP balancer using the cookie method. The peculiarity of this mechanism is that it allows an attacker to attack the system, bypassing the specified load balancing algorithm.
What is a load balancer? It is a network device that distributes application traffic between servers, as well as allowing to monitor and change its characteristics in accordance with the rules specified. When using web applications, it is necessary that the same server serves the client session. To do this, the BIG-IP balancer tracks and stores session information, which includes the address of a specific web server serving the client. This information is used to direct client requests to the same web server during one session.
')
BIG-IP offers several session support methods, including: cookie persistence, hash persistence, destination / source address persistence, SSL persistence. In the vast majority of cases, the persistence cookie is used for HTTP traffic. It includes four types: HTTP cookie insert, HTTP cookie rewrite, HTTP cookie passive and cookie hash. The type of HTTP cookie insert is the most common, since, unlike the others, it does not require that each web server be configured to send certain cookies, and they are automatically generated on the balancer.
Let's see what kind of information does the cookies send to the client.
The cookie name is configured as BIGipServer <pool name>. The client immediately receives information about the use of the BIG-IP balancer and the name of the server pool.
Now look at the cookie. It contains the reverse decimal representation of the server’s IP address (4225695754) and its port (20480).
There are two ways to restore the IP address and port to the usual format:
1. We take the decimal value of the cookie, which is responsible for the IP address, and translate into hexadecimal format: FBDF000A.
Divide bytes and arrange them in reverse order: 0A00DFFB.
We convert bytes into decimal format, each byte opens an octet of an IP address: 10.0.223.251.
By the same principle, we decode the port (it contains a two-byte value):
2. Enter
Write the values of the octets from the last to the first, we get: 10.0.223.251.
A similar operation can be done for the port value:
We get the value: 0.0.80.0.
Since the port is written in two bytes, the first two values are omitted. Write the values of the two extreme octets from the second to the first, we get: 080.
Thus, we received the address of our service: 10.0.223.251:80.
If the pool member is not in the default route domain, a different type of encoding is used.
Content:
By completing the session (by default, they expire when the browser is closed) and accessing the site again, we will be able to get information about all the servers in the pool. This is completely unnecessary disclosure of information about the internal structure of the data center.
As mentioned earlier, balancers are installed for the purpose of proper load distribution. However, by manipulating the cookie value, an attacker can choose with which server from the pool to connect, bypassing the specified load balancing algorithm.
Let's see how it looks in practice:
1. Change the cookie value to the appropriate server we need:
2. We turn to the server and make sure that the balancer redirects us to the service corresponding to the value we set in the cookie in the previous step:
A reasonable question arises: how to defend yourself?
BIG-IP supports cookies encryption. Encryption is performed with the AES 192-bit cipher, and then the cookie is encoded using the Base64 algorithm.
An example of an encrypted cookie:
When using cookies encryption, an attacker can no longer get information about the IP addresses of web servers. However, this does not protect against the possibility of a DoS attack on a particular server. The fact is that encrypted cookies do not bind to the client, and, as a result, cookies can be used to launch attacks against a server from multiple sources (for example, from a botnet).
The diagram at the beginning of this article shows statistics collected from 100 random websites using the BIG-IP balancer and cookie support for sessions. According to these statistics, the owners of most of these sites do not bother with additional security settings to hide data on the internal infrastructure.
Author: Kirill Puzankov, Research Center Positive Research
What is a load balancer? It is a network device that distributes application traffic between servers, as well as allowing to monitor and change its characteristics in accordance with the rules specified. When using web applications, it is necessary that the same server serves the client session. To do this, the BIG-IP balancer tracks and stores session information, which includes the address of a specific web server serving the client. This information is used to direct client requests to the same web server during one session.
')
BIG-IP offers several session support methods, including: cookie persistence, hash persistence, destination / source address persistence, SSL persistence. In the vast majority of cases, the persistence cookie is used for HTTP traffic. It includes four types: HTTP cookie insert, HTTP cookie rewrite, HTTP cookie passive and cookie hash. The type of HTTP cookie insert is the most common, since, unlike the others, it does not require that each web server be configured to send certain cookies, and they are automatically generated on the balancer.
Let's see what kind of information does the cookies send to the client.
The cookie name is configured as BIGipServer <pool name>. The client immediately receives information about the use of the BIG-IP balancer and the name of the server pool.
Now look at the cookie. It contains the reverse decimal representation of the server’s IP address (4225695754) and its port (20480).
There are two ways to restore the IP address and port to the usual format:
1. We take the decimal value of the cookie, which is responsible for the IP address, and translate into hexadecimal format: FBDF000A.
Divide bytes and arrange them in reverse order: 0A00DFFB.
We convert bytes into decimal format, each byte opens an octet of an IP address: 10.0.223.251.
By the same principle, we decode the port (it contains a two-byte value):
20480→5000→0050→802. Enter
“ping 4225695754” on the command line. At the output we have IP: 251.223.0.10.Write the values of the octets from the last to the first, we get: 10.0.223.251.
A similar operation can be done for the port value:
ping 20480 .We get the value: 0.0.80.0.
Since the port is written in two bytes, the first two values are omitted. Write the values of the two extreme octets from the second to the first, we get: 080.
Thus, we received the address of our service: 10.0.223.251:80.
If the pool member is not in the default route domain, a different type of encoding is used.
Content:
- rd524 - route domain 524, denotes the domain identifier of the routes,
- ac174810 - hexadecimal representation of the IP address of the web server - 172.23.72.16,
- 5080 is the real port of the web server.
By completing the session (by default, they expire when the browser is closed) and accessing the site again, we will be able to get information about all the servers in the pool. This is completely unnecessary disclosure of information about the internal structure of the data center.
As mentioned earlier, balancers are installed for the purpose of proper load distribution. However, by manipulating the cookie value, an attacker can choose with which server from the pool to connect, bypassing the specified load balancing algorithm.
Let's see how it looks in practice:
1. Change the cookie value to the appropriate server we need:
2. We turn to the server and make sure that the balancer redirects us to the service corresponding to the value we set in the cookie in the previous step:
A reasonable question arises: how to defend yourself?
BIG-IP supports cookies encryption. Encryption is performed with the AES 192-bit cipher, and then the cookie is encoded using the Base64 algorithm.
An example of an encrypted cookie:
When using cookies encryption, an attacker can no longer get information about the IP addresses of web servers. However, this does not protect against the possibility of a DoS attack on a particular server. The fact is that encrypted cookies do not bind to the client, and, as a result, cookies can be used to launch attacks against a server from multiple sources (for example, from a botnet).
The diagram at the beginning of this article shows statistics collected from 100 random websites using the BIG-IP balancer and cookie support for sessions. According to these statistics, the owners of most of these sites do not bother with additional security settings to hide data on the internal infrastructure.
Author: Kirill Puzankov, Research Center Positive Research
Source: https://habr.com/ru/post/244819/
All Articles