BurpSentinel HowTo and introduction
Select a HTTP request which you want to attack.
This request should:
- have attackable parameters (GET, POST, COOKIE, PATH)
- be idempotent (sending it multiple times should have the same result)
- is an original request (as sent by the web application itself, like a virgin. It should not contain attack artifacts, like XSS/SQL attacks)
If the request is part of a multi-step process, it may be better to test manually (via intercepter). BurpSentinel really requires an HTTP request which will generate the same (or super similar) result every time its being sent.
Just click the right mouse button on a HTTP request, and click "Send to Sentinel":
Result: The request appears in the Sentinel tab:
The Sentinel windows is split into three panels:
- Top: All requests which have been sent to Sentinel
- Left: The original request (which has been sent to Sentinel), and possible attack options
- Right: The performed attacks (and their HTTP responses)
Sentinel's basic design principle consists of comparing the HTTP responses of attacks, with the HTTP responses of the original request.
Click on the parameter which should be attacked (Checkbox "Attack"), and then "Go". The original HTTP request will be attacked, and the result shown in the panel on the right side.
It is possible to attack:
- GET parameter
- POST parameter
- Cookies
- PATH elements (for REST applications)
When the attack is finished, we have a list of HTTP requests which have been sent by the attack. Select each of the attack to see the corresponding HTTP request and response.
Now there are a lot of HTTP requests and responses, but how to identify vulnerabilities? I'll discuss this in the next sections.
The attacks can be selected with the button "Attack Selection":
Sentinel has several attack payloads:
- XSS
- SQL (simple)
- SQLE (enhanced)
I'll discuss the attack payloads in the following chapters, and also give an explanation of how to use them.
The XSS attacks will send typical XSS injections, like:
<p>"'"[space]=
These attack payloads should include all necessary characters to check if the web application is performing a correct output encoding.
It will also prepend an unique identifier, like this:
Xss[a-Z][a-Z]
And append it to the original request, like this:
OriginalTextXssaf<p>"
Sentinel will automatically detect if the unique identifier is appearing in the HTTP response (e.g. Xssag). It will also identify if a specific attack resulted in an XSS:
- Attack:
Xssab%3Cp%3E%22 - Detect:
XssabandXssab<p>"
In the following screenshot, I attacked an application vulnerable to reflected XSS:
With the arrow up/down buttons, its possible to iterate through all occurences of the unique identifier (Xss) in the selected HTTP response. In this case, the decoded attack payload of Xssab%3Cp%3E%22, namely Xssab<p>", has been found in the HTTP response. Seems like the web application is vulnerable to XSS! But further investigations are needed by the tester to check the exploitability. Sentinel will only aid in detection of vulnerabilities, not exploitation.
Additionally, it is also possible to just see the difference between the original- and attack request (unified diff):
The unified diff view will create a standard diff between the original request (on the left side of BurpSentinel tab), and the attack request's response. With this its pretty easy to identify XSS's and other changes.
For XSS vulnerabilities, we want to identify all occurrences of unencoded characters.
Sentinel will detect:
- instances of the unique identifier
- decoded instances of input attack parameter
- different amounts of HTML syntax errors (see blog entry for more information)
Therefore, the result column is a good indicator for vulnerabilities. If the HTTP responses have a vastly different size and number of tags, its probably the application generating an error. Anyway, check the results manually. How are the attack payloads encoded? Is everything encoded, or partially? What encoding did they use?What frameworks did the webapp developer use, and did they use them correctly? Are there instances, where they didnt use them correctly? Can the encoding be circumvented? Etc...
If the applications generates a SQL error, Sentinel will automatically detect this (it has a big sql error string list).
The BREAK request already made the web application to generate an SQL error message.
If an SQL error message is identified in the HTTP response, Sentinel will notify the user in the Result and Info column. Simple and easy.
Sentinel will send:
o'BREAK"riginalo' || 'riginalo' + 'riginalo' 'riginal
See my presentation at BsidesVienna 2014 for details: Semi Automated Pentesting with BurpSentinel
We have the following result:
Lets check the BREAK request:
Seems like when we insert a 'BREAK", the web application does not output "Username ID:" HTML elements. Could this be an SQL injection?
Lets check the idempotent SQL injection:
It appears that these two requests produce the identical result:
rootr' || 'oot
Which is a very strong indicator for an SQL injection. Time to test it manually, or with SQLmap, intruder or by yourself!
Keep an eye out for the length and #tags in the responses. Check the responses with the same size as the original request, this is a good indicator for SQL injection. What input's give an error message? Why? Is it consistent with other requests?