BurpSentinel HowTo and introduction - dobin/BurpSentinel GitHub Wiki

How to use BurpSentinel

Send a request to BurpSentinel

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": pictures/howto-1.png

Result: The request appears in the Sentinel tab:

pictures/sentinel-tut-result1.png

Sentinel UI Overview

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.

pictures/sentinel-tut-overview.png

Attack the 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)

pictures/sentinel-tut-attackrequest.png

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.

pictures/sentinel-tut-attack1.png

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": pictures/sentinel-tut-overview-2.png

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.

Attack: XSS

XSS: Attack methodology

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: Xssab and Xssab<p>"

XSS: Attack examples

In the following screenshot, I attacked an application vulnerable to reflected XSS:

pictures/sentinel-tut-attack-xss-1.png

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):

pictures/sentinel-tut-attack-xss-2.png

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.

XSS: analysis methodology

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)

XSS: What to look for

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...

pictures/sentinel-tut-attack-xss-3.png

SQL Injections

SQL1: Non-blind SQL injection

SQL1: Attack methodology

If the applications generates a SQL error, Sentinel will automatically detect this (it has a big sql error string list).

SQL1: Example

pictures/sentinel-tut-attack-sql-1.png

The BREAK request already made the web application to generate an SQL error message.

SQL1: What to look for

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.

SQL2: Half-blind XSS

SQL2: Attack methodology

Sentinel will send:

  • o'BREAK"riginal
  • o' || 'riginal
  • o' + 'riginal
  • o' 'riginal

See my presentation at BsidesVienna 2014 for details: Semi Automated Pentesting with BurpSentinel

SQL2: Example

We have the following result: pictures/sentinel-tut-attack-sql-2.png

Lets check the BREAK request:

pictures/sentinel-tut-attack-sql-3.png

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:

pictures/sentinel-tut-attack-sql-4.png

It appears that these two requests produce the identical result:

  • root
  • r' || 'oot

Which is a very strong indicator for an SQL injection. Time to test it manually, or with SQLmap, intruder or by yourself!

SQL2: What to look for

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?