Wednesday, 16 January 2019

A Noob's Guide to Web Cache Deception.

Users are often the weakest link when we are exploring for a vulnerability and 
of-course they can be easily tricked. Today in this tutorial we are going to discuss about a simple but severe bug known as Web Cache Deception. So let's begin

Introduction
As the name says it all "Web Cache Deception" - something related to cache and the action of deceiving someone. Web cache deception is deceiving a victim using weakness in caching mechanisms. So, how it works? Well as a rough definition this is how it works : A caching mechanism / load balancer / web application firewall is setup so that if a page is requested then it creates a cached copy of that page and when the next time, the same page is requested, then the page will be loaded from the mechanism and not from the server. An attacker creates a malicious link ( we will talk about this further ) and the victim clicks on it. Resulting in getting sensitive data cached and the attacker can also request that page with sensitive data from the caching mechanism. Now let's break it down and understand each and everything step by step

Caching 
Caching is simply storing files on a computing system. This is usully done when a file is requested frequently and to reduce load from the server.
Note : static files i.e. with extensions like .css, .txt, .img, .png, .js e.t.c are cached more often because these files doesn't contain any sensitive information.

Caching Mechanism

Malicious Link
Now let us assume that there is a web application "hackmonk.tld" and there's a caching mechanism to cache all static public files. And let us also assume that the web application has user account feature and every user, after authentication can access their dashboard via "hackmonk.tld/home"
Now what an attacker will do is modify the url to make it like "hackmonk.tld/home/non-existing-file.css" where "non-exisiting-file.css" is a non existant name with .css extension. This will be the Malicious link. But hey, won't this give a 404 not found status code? That's where we confirm that vulnerability may exist. If this url leads to hackmonk.tld/home then we can go for further testing. So now the attacker will send the url "hackmonk.tld/home/non-existing-file.css" to the victim and will make him anyhow click on the link and load it on a browser on which he is logged in on the site "hackmonk.tld". Now the victim will get to the dashboard and the caching mechanism thinking that the url "hackmonk.tld/home/non-existing-file.css" belongs to a public static file will cache the page along with the cached page of victim's dashboard and the attacker wil request the same page and it will load from the caching mechanism instead of server. BOOM private information is in your hands. Sometimes you will also be able to get CSRF Tokens which will lead to full ACCOUNT TAKEOVER. Isn't it cool?

Here is an image that demonstrate's the whole attack scenario - 



Now let's discuss it further with some questions.

Won't it ask for authentication when accessing the cached page?
No, it won't. Websites don't require authentication to access public static files.

What are the conditions for this attack to work?
Well, there should be either a caching mechanism / load balancer / WAF like akamai or cloudfront which is ofcourse not configured properly and when requesting page liks "hackmonk.tld/home/non-existing-file.css" it should give the content of "home" for the URL.

Final Words
So here we end this tutorial and i hope it explains each and everything about Web Cache Deception. Please comment down if i missed anything or if i wrote something incorrect.

Resources and Tools 
Here are some resources for further reading on the topic "Web Cache Deception"
  1. https://hackerone.com/reports/260697
  2. https://omergil.blogspot.com/2017/02/web-cache-deception-attack.html
And here is a payload list for faster testing 

  1. https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Web%20cache%20deception
Thankyou for reading guys. I will meet you next time with more informational content. BYE


No comments:

Post a Comment