Introduction
Cross-Site Request Forgery (CSRF) attacks are well established and understood, having been in the OWASP top ten for ten years. For those of you not so familiar with this vulnerability, it takes place when a user can be coerced into clicking on a link that performs an authenticated action on an application. In February 2017, security researcher Omer Gil unveiled a new attack with a similar exploitation vector but different consequences, dubbed "Web Cache Deception" (https://omergil.blogspot.co.il/2017/02/web-cache-deception-attack.html). This attack results in an attacker gaining access to sensitive data from a users' authenticated session. The outcome of the attack is a mirror image of CSRF, in that response data is extracted rather than an action being blindly performed.
No tools were readily available to test for Web Cache Deception, so I came up with Airachnid for my favourite webapp testing tool, Burp Suite.
At a high level, the Web Cache Deception attack is very simple to execute and contains only two steps:
- An attacker coerces the victim to open a link on the valid application server containing the payload.
- The attacker opens the newly cached page on the server, using the same link, to see the exact same page as the victim.
N.B - This attack only makes sense when the vulnerable resource that's available to the attacker returns sensitive data.
Requirements / Preconditions:
The attack depends on a very specific set of circumstances to make the application vulnerable, I have tried to explain this clearly with examples below (please add comments / questions at the bottom).
- The application only reads the first part of the URL to determine the resource to return. In our example, if the victim requests: https://www.example.com/my_profile, the application returns the victim profile page. The application uses only the first part of the URL to determine that the profile page should be returned. If the application receives a request for https://www.example.com/my_profile_test,
it would still return the profile page of the victim, disregarding the added text. The same applies for https://www.example.com/my_profile/test.
- The application stack caches resources according to their file extensions, rather than by cache header values. In our example, the application stack has been configured to cache image files. It will cache all resources with .jpg .png or .gif extensions. That means that the image at https://www.example.com/images/dog.jpg would be retrieved from the application server the first time the image is requested. All subsequent requests for the image are retrieved from cache, responding with the same resource that was initially cached (for as long as the cache timeout is set).
Attack
These preconditions can be exploited for the Web Cache Deception attack in the following manner:
Step1: An attacker entices the victim to open a maliciously crafted link: https://www.example.com/my_profile/test.jpg
- The application ignores the "/test.jpg" part of the URL, the victim profile page is loaded.
- The caching mechanism identifies the resource as an image, caching it.
Step 2: The attacker sends a GET request for the cached page:
https://www.example.com/my_profile/test.jpg
- The cached resource, which is in fact the victim profile page is returned to the attacker (and to anyone else requesting it).
The Tool
We wanted to have a tool that we could use in the normal course of testing to easily validate the existence of this vulnerability. Since all our consultants use Burp Suite Proxy, it seemed a logical course of action to create an extension for testing requests that have already been observed. We also required a scalpel rather than a shotgun; since testing publicly available static pages could potentially create false positives, we wanted a tool that would only start sending multiple requests once certain criteria were met. The scalpel approach requires some thinking on the part of the user. Having access to cached versions of resources only helps an attacker if the page contains data that is valuable to the attacker.
Once the extension has been loaded, go to the sitemap area and right click on the resource containing sensitive information and click on Test Web Cache Deception:
The first request sent in testing, repeats the original request (to ensure that the session identifier is still valid). The response of this request is then compared to the response to the same URL, with added text - precondition no.1.
If this test is satisfied, a number of requests are made to the server, checking if resources are cached by extension - precondition 2. Any successful test would lead to an issue being added to the particular URL in the Target -> Site Map tab. If the test was not successful, the extension will report this in the Output window of the extension.
Vulnerable:
Not vulnerable:
Possible False Positives
If testing is done on static pages, that do not change between requests, it is expected that false positives are created. Testing depends on the similarity of pages, and if an application responds with 200 OK messages, regardless of changes to the ending of a URL, false positives are expected.
Future Developments
- Creation of a GUI: A number of parameters should be user set. Similarity tests are dependent on text comparison strategies. Thresholds are set for the extension that might need to be fine tuned for specific applications.
- Implementation of different approach. Build more intelligence into recognising vulnerable pattern.
Obtain the extension from here, we're expecting it to be available in the Burp app store very soon:
https://github.com/SpiderLabs/Airachnid-Burp-Extension
Comments and feedback welcome :)
