Burp SessionAuth Extension

Overview

Normally a web application should identify a logged in user by data which is stored on the server side in some kind of session storage. However, in web application audits someone can often observe that internal user identifiers are transmitted in HTTP requests as parameters or cookies. Applications which trust identity information provided by the client can be vulnerable to privilege escalation attacks. Finding all occurrences of identity data transmissions can be quite straining, especially if this information is sent in different parameters, among other information or only in particular requests.
The motivation behind the Burp SessionAuth extension was to support the web application auditor in finding such cases of privilege escalation vulnerabilities. The idea is, that the auditor provides some information, internal identifiers and strings which identify different users (e.g. his/her real name) or content. The extension performs the following tasks:

• Monitoring of all requests for occurrences of the given identifiers. Such requests are typical candidates for privilege escalation vulnerabilities. Even if a web application doesn't seems to be vulnerable in one part, it can still be vulnerable in other ones.
• Preparing an Intruder configuration on request of the user and implementation of a Intruder payload generator which delivers the user identifiers.
• Actively scan a suspicious request and try to determine vulnerabilities automatically by some heuristics.

Please be aware that this piece of software is still very experimental!

Usage

Configuration

A proper configuration of the extension is very important. It's useless without providing some data to it! If you observe the usage of identifiers (numeric etc.) for user accounts or are in the lucky position, that such identifiers are provided to you in an audit, then you should enter such information in the extension configuration.
The extension provides a suite tab in Burp named "SessionAuth" which contains a table with already entered identifier/content-pairs and the possibility to add such pairs by entering them manually.

For convenience there is a possibility to provide such pairs directly from requests or responses by marking the particular text and invocation of the context menu. Before the first addition the context menu contains only an item to add the marked text as identifier. After this has been invoked, another menu item offers to add the marked text as content to the last added identifier.

Caution: currently there exists a bug which causes Burp to consume massively CPU time if a request is currently pending (if I observed it correctly). Ensure that this is not the case before adding elements, it can kill your Burp session!
Generally the roles of the both values in a pair are as follows:

• The identifier is a value that is used as internal identifier for a particular user account. E.g. 100000055410117 is the identifier of my personal account at Facebook.
• The content is a value which identifies the object addressed by the identifier in human-readable form. E.g. for the above case "Skora" would be a good value.

At least one element identifier must be given for usage of the passive scanning functionality. The content value is not required, but helps the extension to recognize interesting requests. For usage of the active scanning and Intruder functionality at least two identifier/content-pairs are required.

Passive Scanning

After the first identifier is added, the extension starts to examine each request sent through the Burp proxy with a passive scan. Each occurrence of the identifier in a request results in a scanner issue in the Scanner/Results-tab of Burp. The title is "Object Identifier found in Parameter Value". Severity is determined as follows:

• Informational: the content value associated with the identifier doesn't appears in the response.
• Low: the content value associated with the identifier appears in the response.

Confidence is determined as follows:

• Certain: the parameter value matches exactly an identifier.
• Tentative: the parameter value contains the identifier together with other stuff.

The passive scan issues generated by the extension help the auditor to identify interesting request candidates for privilege escalation vulnerabilities. They should be reviewed manually and further tests should be performed on them.  

Intruder

For each request which contains at least one identifier the extension adds a context menu item, "Send to Intruder and preconfigure id injection points", which sends the request to Burp Intruder and sets appropriate injection points at the locations of the found identifiers. Another feature is a payload generator, which outputs the identifiers given in the SessionAuth tab:

If you send a request to Intruder by the extensions context menu item, the payload is not preconfigured, because there is no possibility in the API which allows this setting to be performed from an extension. An enhancement request is pending. However, you can configure a template in the first/last Intruder tab and use it as default for new Intruder tabs in the usual way.
This supports you manually in verifying what happens if an identifier is replaced by another one in a request. Generally such identifiers are also interesting targets for injection attacks, because they are used to refer users in some kind of backend data store like an SQL or LDAP database. If you have only one identifier while an audit, increasing/decreasing it is also a good try. Live out your creativity, but always keep in mind: respect the privacy of others and disclose found vulnerabilities responsible!

Active Scanning

This is the part of the software which tries to identify privilege escalation vulnerabilities automatically with some heuristics derived from some years of web application audit experience. If you're in hurry, you possibly would find something you would have overseen or you can perform a preflight before doing the manual part. My recommendation will always be: don't rely only on automatic scans! Serious (web) application audits are mainly based on manual work and not on results of automated scans. This applies especially to vulnerabilities addressed by this extension, which are often subtle to find.
The active scan replaces identifiers found in the request sequentially with all other identifiers and reissues the request. Then the resulting response is compared against the base response. In the current version the occurrence of content values corresponding to the identifiers is counted and the count is matched. Most important cases are:

• The content value of the replaced identifier disappears completely, instead the content value of the new identifier (which wasn't contained in the base response) appears with the same count. This is considered as critical, because there is a high probability that some kind of impersonation was triggered. Be careful with your judgement: in some functionality of web applications this is the intended behavior, e.g. viewing other users profiles in social networks. Severity is high and confidence is certain in this case.
• If the count of the replaced identifier content value decreases, while the count of the content value of the new identifier increases by the same amount, the confidence is set to firm.
• If the count of the replaced identifiers content value increases, the confidence is set to tentative.
• If the responses differ but the content value of the replacement identifier doesn't appears, the severity is informational and confidence is tentative.

All active scan issues contain the base and scan request/response pair. Burp automatically adds a button for comparison of both responses.
Complicated? Maybe a bit ;-) I think there is much room for improvement. The following picture shows all issue types:

Further Usage

There are other use possible use cases. E.g. imagine a web application which stores content or documents which must not be accessible by all users. Add the identifier of an object where access by the current audit user is allowed and another one of an object where the user is not allowed to access. Furthermore add a part from the content as content value. From this point the extension will watch the requests for occurrences of the identifiers and can be used to perform the usual replacement tests automatically.

want it!

So you think the Burp SessionAuth extension could be useful for you? Then get it, use it and if you have ideas and time, feel free to improve it! Be aware: it could be buggy and mess up your Burp sessions!

Download

Get it at GitHub.

Source:skora.net