Cache Poisoning with XSS, a peculiar case

You have heard of the cache poisoning, a bug that had existed for far longer than most of people have been aware, as in many other cases of this nature, in my opinion. But, this article isn’t about a history lesson; however, there are a couple of lessons, maybe more, that you might find useful.

Param Miner with an Edge:

See what I did there? Never mind, it will make itself known soon enough.

Here’s the real world example. Of course I can’t disclose the bbp in question, but the details of the attack won’t make it necessary to do so.

I use Param Miner, an extension for burp pro (technically, it also works in burp community edition, but with a lot of limitations). And, aside from testing for hidden parameters, it also tests for cache poisoning, and then there’s burp pro with its scanner which tests for xss. Add them together and you can get yourself some nice bounties. But, it still requires some legwork.

Doesn’t your heart simply swell up by an increase in adrenaline production upon seeing this, or maybe it flutters, or it starts beating stronger. Either way, it means a good news. It did for me. Upon the initial (with hands shaking) review, it turned out that it wasn’t a false positive. Param miner had discovered a hidden header parameter that was reflecting its value inside the body (plot twist) of the website’s main page. Bonus points: the value wasn’t being properly sanitized for xss. Yey.

But, for that initial review, I had been using burp repeater for verification, which was a mistake that took time figuring out. And, it did take me a while. Trying to replicate the results (i.e. website’s main page rendering with xss) was failing when done using firefox. I checked the source code, there was no trace of that param, and therefore no xss. What was going on?

Verification, and actually a PoC:

When in doubt, drink some coffee, and then some more coffee, maybe check what video games are on discount during the week in question, and then get back into the mud of ones and zeroes (not really ones and zeroes, unless if you’re doing some serious stuff which would probably place you far from this article). And then — curl.

To be more precise,

bash script with curl command used to attack the website:

curl and grep to check for response (done manually):

curl https://website.com | grep “</script>testing”

The first response had nothing to grep. But, then… what was that red font highlighting? Could it be? But then the next few responses had nothing, and then another few had, and then again nothing. As it turned out, the cache was being cleared fairly quickly, but not quickly enough :)

Getting the PoC to actually affect visitors of the website:

Back to the problem at hand. Having burp intruder run infinitely, and curl responses containing the hidden param while firefox and chrome were still rendering the website without that hidden param, how could that be used to attack anyone? It couldn’t. Those two things alone weren’t enough.

MS Edge to rescue(?):

Now you get the bit from earlier :) Never mind.

After spending some time swearing and being all around baffled by the problem at hand, and of course trying to figure out how to present it in a report without being marked as N/A or Informative, I remembered that I haven’t tried all the browsers. And, while I am not a fan of windows, I do have it, I can always count on it to fail therefore no unpleasant surprises :)

That’s how I ended up going with MS Edge. I opened MS Edge, and I opened the affected website. Nothing. Well, of course, the cache got cleared too fast or my curl script was being too slow. The point is, with final curl payload for bash script being:

upon refreshing a few times, voila:

I reported it and… they couldn’t reproduce it. I made a few videos, and of course I also combined vps and local environments when testing for cache poisoning and the response in order to ensure it wasn’t local cache poison. But, in the end, it turned out that, for whatever reason (location of servers, maybe) the answer to why they weren’t able to reproduce it, initially, had to do with them trying it from a different country than the USA. They contacted their colleagues located in the USA who had no problem reproducing it. Computers, go figure.