Lab: Exploiting exact match cache rules for web cache deception
Identify a target endpoint
After we have started the exercise, the blog should look similar to the screenshot. We click on the link "My Account" and log in to the application with the user name wiener and the password peter.
After entering the data, we confirm our entry by clicking on the "Log in" button.
We now see our account and change our e-mail address to wiener1@hacker.com.
After the change we see our new e-mail address wiener1@hacker.com.
We now switch to the Burp Proxy and open the "HTTP history" tab. In the "HTTP history" we search for the request GET /my-account and see a CSRF token as a hidden parameter.
Investigate path delimiter discrepancies
We send the request GET /my-account to the Burp Repeater. To do this, we move the mouse over the request and press the right mouse button. A context menu appears in which we select the option "Send to Repeater".
In Burp Repeater, we append the character string abc to the path /my-account. The request should look like this.
We now send this request to the application and receive a 404 Not Found. This means that the origin server does not abstract the path to /my-account.
We now change the path from /my-account/abc to /my-accountabc and send the request to the application again.
The response is again a 404 Not Found and contains no indication of caching.
We now send this request to Burp Intruder. To do this, we move the mouse over the request and press the right mouse button. A context menu appears in which we select the option "Send to Intruder".
We now switch to the Burp Intruder and adjust our request so that we can identify limiters. First, we make sure that "Sniper attack" is selected as the attack method.
Then we click with the mouse in the path /my-accountabc between /my-account and abc and press the button "Add §".
Our request should now look like this.
In the "Payloads" section, the "Payload type" must be set to "Simple list". We now go to the start page of the exercise. There you will find a list of limiters.
The list can be found in the following code block.
We copy this list and click on the "Paste" button in the "Payload configuration" subsection of the Burp Intruder.
In the subsection "Payload encoding" we deactivate the checkbox "URL-encode these characters". If we do not disable this option, Burp Intruder will encode our delimiters and we will not be able to identify any delimiters used by the application.
Click on the "Start attack" button to start the attack. In the result window, we now click twice on the "Status code" column and see that the characters ; and ? have received a 200 OK code.
If you are using the Community Edition of Burp, this attack may take a little longer, as the Burp Intruder version is somewhat limited.
Now we go to the Burp Repeater and test our two delimiters ; and ?. We adjust the path /my-accountabc as follows. We insert ; between /my-account and abc. We turn abc into a static JavaScript file abc.js. The path should now look like this: /my-account;abc.js. The finished request is shown in the following code block.
When we send the request, we get a 200 OK but no indication of caching.
We now replace the character ; in the path with ? so that our path looks like this: /my-account?abc.js. The complete request is shown in the following code block.
Here, too, we receive a 200 OK, but again without any indication of caching.
Investigate normalization discrepancies
In the repeater, we now remove the character string abc.js from the request and insert a directory with an attached coded point sequence /aaa/..%2fmy-account. The request should look like this.
When we send this request to the application, we receive a 404 Not Found in response. This indicates that the origin server is not decoding or resolving the dot segment to normalize the path to /my-account.
Now we switch to the "HTTP history" tab in the Burp Proxy and see that static files all start with the prefix /resources.
If we look at the responses of the three requests, we find no evidence of caching. This means that there is no static directory cache rule. The three responses are listed below.
In the Burp Repeater, we now change our path from /aaa/..%2fmy-account to /robots.txt and send it to the application.
We now receive a response with the headers Cache-Control: max-age=30, Age: 0 and X-Cache: miss. If we send the request to the application again within 30 seconds, the value of the header is X-Cache: hit.
We now place the coded dot sequence /aaa/..%2f in front of /robots.txt so that our path has the following form: /aaa/..%2frobots.txt.
We receive a '200 OK' response. This shows that the cache is normalizing the path to /robots.txt.
Exploit the vulnerability to find the administrator's CSRF token
We now construct the path /my-account?%2f%2e%2e%2frobots.txt with the delimiter ; and send the request to the application.
We receive a 200 OK response, but no indication of caching.
We change the delimiter to ; and send the request to the application again.
We again receive a 200 OK response with the Headers Cache-Control: max-age=30, Age: 0 and X-Cache: miss. If we send the request to the application again within 30 seconds, the value of the header X-Cache: changes to hit.
Now we switch to the exploit server by clicking on the "Go to exploit server" button in the browser.
In the exploit server, we scroll down to the "Body" section and insert the following exploit code there. This code redirects the victim carlos to a malicious URL. At the end, we insert an arbitrary value as a cache buster (wcd) so that carlos does not receive the previously cached response.
To deliver the exploit to carlos, we click on the "Deliver exploit to victim" button in the exploit server.
We then copy the URL from the exploit and paste it into a new tab in the browser. We see that the browser redirects to the login page. This may be because the browser is redirecting requests with invalid session data. We try the exploit in Burp instead.
The exploit may have to be delivered to the victim several times before access to the login page is possible.
We now switch to the Burp Repeater and change the path of our request from /my-account;%2f%2e%2e%2frobots.txt to /my-account;%2f%2e%2e%2frobots.txt?wcd.
We click the "Deliver exploit to victim" button again in the exploit server and send the request in the Burp Repeater (within 30 seconds) twice in succession to the application and see that the header X-Cache: contains the value hit. If we scroll down in the response, we see a CSRF token there.
The CSRF token may be from the administrator and we can use it to log in to the application. If the CSRF token has not changed, click on "Deliver exploit to victim" again in the exploit server and send the request twice in succession in the repeater.
Craft an exploit
We switch to the "HTTP history" in the Burp Proxy and search for the request POST /my-account/change-email.
We send this request to Burp Repeater. To do this, we move the mouse over the request and press the right mouse button. A context menu appears in which we select the option "Send to Repeater".
In the repeater, we replace the existing CSRF token with our CSRF token that we have just captured and change the mail address to a new address that we have not yet used (in line 23).
Now we move the mouse over the request and press the right mouse button. A context menu appears in which we select the option "Engagement tools".
Another window opens in which we select the option "Generate CSRF PoC".
The "CSRF PoC Generator" window now opens, in which we click on the "Copy HTML" button.
We now add this code to our exploit server, in the "Body" section, and click on the "Deliver exploit to victim" button.
The exercise was successfully completed.
Video solution
Last updated