Pages

About us

H4xOrin' T3h WOrLd

Sunny Kumar is a computer geek and technology blogger. He is a founder and editor of H4xOrin’ T3h WOrLd web-site. Always passionate about Ethical Hacking, Penetration Testing of Web applications, security, gadgets and ev-erything to go with it.His goal of life is to raise the awareness of Information Security, which is nowadays is the key to a successful business.

Media

Burp SessionAuth Extension

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!