Automated scanning with Burp despite Anti-CSRF token

The usage of security tokens in Web Applications is increasing rapidly, especially as more and more frameworks support this technique to prevent CSRF attacks. These anti-CSRF tokens are typically used when state-changing actions are executed, like adding a user or confirming your purchasing order.

There are web applications that use anti-CSRF tokens in the whole application. This makes the web application very robust against CSRF attacks, but makes the life of a penetration tester much harder because automated scanning becomes a nuisance.

This tutorial explains how to circumvent the anti-CSRF tokens used in requests, to execute tools like the Burp Intruder, Burp Active Scan and sqlmap.

Intruder Scan

Click on „Add“ to define a new grep item

If you want to fuzz a certain parameter in a request that is protected by anti-CSRF tokens there is an easy solution already implemented within Burp.

Just send the request you would like to analyze to the Intruder. Clear all payload positions and only select the value of the anti-CSRF token parameter and the value of the parameter you would like to be analyzed by the Intruder. Also set the attack type to Pitchfork.

In the options tab of the Intruder , the number of threads must be set to „1“, as the attack has to be executed as sequential processing. Otherwise the intruder will mix up valid and used anti-CSRF tokens.

Select anti-CSRF token in response

To circumvent an anti-CSRF token in the Intruder, it is sufficient to go to the options tab, click on „Add“ in the Grep-Extract menu and choose the value of the anti-CSRF-token in the „Define extract grep item“ menu. The start and end point will be filled out by Burp automatically after selecting the token and we can click OK.

Select payload for parameter to be tested

In the Payloads tab, we now need to select the payload type „Recursive

grep“ for the identified anti-CSRF token parameter in the position tab. It is important that you also insert the token that was sent in the last valid response to be used as initial token value for the first request. The second payload can be set to whatever we want to test for.

Select payload type and insert value of valid CSRF token

If we start the Intruder now, the parameter can be tested and the initial token is used to create a valid request. The token in the responses to that is extracted by the grep-rule and inserted into the subsequent request.

In case of an error it is likely that the initial token was wrong or was already used. Then, in our browser, we again navigate to the function we would like to test, execute all of the above steps and use the token of the last response of the application in the initial payload field.

There is also an extension available for Burp Intruder to circumvent this kind of anti-CSRF token:

(1)    Burp Extension available to extend Intruder:

http://blog.spiderlabs.com/2012/09/adding-anti-csrf-support-to-burp-suite-intruder.html

Active Scan

Sometimes during testing we encounter applications that already use anti-CSRF tokens during login and for every subsequent request in the application. To automatically scan a certain request in such an application, we have to:

1. Get the Login-Page,
2. Login to the application,
3. Navigate to the function that should be scanned and
4. Get the anti-CSRF token that can be used for an automated scan.

Add a new session handling rule

Steps 2, 3 and 4 always need the valid token of the last response, otherwise the requests will be invalid. To use tools that execute automatic scans like the Active Scan in Burp or sqlmap, we need to create a session handling rule and a macro to automate the steps (1) to (4) within Burp. 

We give the Session Handling rule a unique name and select „Run a macro“ in the rule actions section.

To create a new macro we click on „Add“ under „Select macro:“ in the next menu. The macro recorder will start, where we can select the appropriate requests. We must start with a request that does not need a valid token when sent to the application and select all requests until we get to the request we would like to test.

Record the „request-chain“

In our case we needed to start at the login, as all other requests needed a token when sent to the application. The first request gets the login page where no token is  required. The second request is a login request with valid user credentials, and the third request directs to the page we wanted to test. To get a valid request chain, the second and third request needs the hidden token of the response before.

Configure macro items

We can achieve this by selecting the second request and clicking on „Configure item“. There, we set the parameter that contains the token to be „Derive from prior response“. Usually this setting does not work by itself, we also need to „Add“ a custom parameter. We just select the location of the token value and use the parameter name as name for the custom parameter. This must be done for all subsequent requests.

In the „Session handling action editor“ the anti-CSRF token parameter that needs to be updated should be added explicitly.

Update parameter with anti-CSRF token

The scope of the session handling rule should be set to „scanner“. To limit the macro to certain requests we can either use „Use suite scope“ or „Use custom scope“. It is not recommended to set „include all URLs“, as every request in the scanner would then trigger the macro.

Set scope for Active Scanner

After the Session Handling rule is created we just need to enable it. As the macro navigates to the page we want to test and gets a valid token for the scanner, you can execute an active scan of this page now. For another page we would need to create a separate macro.

Note:

Every single scanner request will also trigger all the requests we defined in the macro additionally. In the case described above 100 requests of the active scanner would produce 400 requests in total, as every request requires the three requests in the macro. Therefore, the scan will take longer but will also produce more load on the server as many logins will be simulated. So, we should be careful to not overload the server during testing.

sqlmap

Set scope for sqlmap

The exact same steps as for the Burp Active Scan can also be executed for sqlmap.

There is just one difference: The scope of the session handling rule should be set to „proxy“. But use this setting with caution, as every request in the proxy will trigger the full macro and thus all requests in it. To limit the macro to certain requests here, it is even more important to set „Use suite scope“ or „Use custom scope“, as described above.

When the Session Handling Rule is activated we can start sqlmap. If we have a POST-request saved to a file we can use:

./sqlmap.py -r request.txt –proxy=http://127.0.0.1:8080

If we have a GET-request we can use:

./sqlmap.py –u „www.target.com/vuln.php?id=1“ –proxy=http://127.0.0.1:8080

References

http://blog.portswigger.net/2011/03/burp-v14-preview-session-handling_25.html

http://labs.asteriskinfosec.com.au/fuzzing-and-sqlmap-inside-csrf-protected-locations-part-1/

http://labs.asteriskinfosec.com.au/fuzzing-and-sqlmap-inside-csrf-protected-locations-part-2/