Wang Session ID with Burp Sequencer

Whenever we enter the application, the server issues Session ID or tokenthat are unique. But what if we could guess the next unique session ID to be generated by the server?

Today we will try to overtake the application algorithm and enter it, giving out a user with a predictable Session ID.

Content:

Introduction to Burp Sequencer
Session ID Operation in Sequencer
Manual query analysis
Comparison of captured tokens

Introduction to Burp Sequencer

Burp Sequencer is a tool for analyzing the quality of randomness in a sample of data items.

Data items can be:

application session identifiers
CSRF tokens
reset or forgotten password tokens
any specific unpredictable identifier generated by the application

Burp Sequencer is one of the most amazing tools out there that attempts to capture the randomness or variance of session IDs with some standard statistical tests that rely on the principle of testing a hypothesis on a sample of evidence and calculating the likelihood of observed data occurring.

The tool tests samples in several different scenarios, be it character-level analysis or bit-level analysis. The analyzed result will be presented in the best segregated format. For more details on how the Burp Sequencer works, see its documentation…

The main advantage of the sequencer is that it is available for both versions of Burp. After installing the application, the Sequencer tab will be on the top bar.

Exploiting Session ID in Sequencer

Whether it’s a basic session ID or a server-side generated token, sequencer will parse everything, because the only requirement is the request it is sent to.

Let’s run the analyzer in the sequencer by capturing and sharing the login session ID from our favorite vulnerable bWAPP application that comes with Kali Linux and other white-hat hacking OSes.

Enter the target IP address in your browser and login with bee: bug…

Wait! We were talking about the login session ID correctly, so enable the proxy service and then click the “Login“.

Check if burp has captured the request or not. From the captured request, we can see that the PHPSESSID is in the Cookie header, let’s share the full request with the Sequencer by right clicking on the blank space.

Once the Sequencer receives a request, the empty fields are populated directly with the Token ID that comes with the “Response” for the particular generic request.

However, there are times when we want to parse a different value. In such situations, the burp suite makes it possible to define Custom location… Let’s check it out.

Click the “Custom location “ below for the cookie parameter and then open the settings. As soon as we do this, we will have a new window with the name “Define Custom token location“, In which we receive a response to our general inquiry.

In addition, we can choose certain parameters:

Define start & end
Extract from regex group

Let’s check the first one.

When we hover over and select a value from the overall response, we get some manipulation of the start and end delimiters. Press the button “Save“And our custom location will be defined in the panel.

Now just click the “Start Live Capture“By selecting the” Cookie “option in the”Token Location within Response“.

When we do this, a new cono will appear [ Live capture #1 ]…

As soon as the button “Start Live Capture“Burp repeated the original request (about a thousand times) and thus retrieved all the tokens it received from the responses.

However, once the capture page is loaded, a progress bar is displayed with a counter of generated tokens and requests made by the sequencer.

Live Capture window buttons:

Pause / Resume – pauses the process to help the penetration tester analyze the requests generated up to this point.
Copy tokens – helps to copy all generated randomized tokens.
Stop – complete stop of the process.
Save Tokens – saving randomly generated tokens to a specific file.
Auto analyze – resets the analyzed results, after generating a certain number of tokens.
Analyze now – displays a report when pressed. Works only if the number of generated tokens is more than 100.

So let’s pause the sequencer and then press the “Analyze now»To find out what he collects.

From the image below, we can see that the sequencer analyzed about 16,000 requests, and the overall quality of randomness in the sample was rated “excellent”.

We could get the quality of the randomness as “bad” if the session ID of the web application was repeated.

However, the effective entropy is 110 bits, which is considered a good value because:

the smallest value is 64
the best value is 128

Burp Sequencer runs on top of Sample, so a better and more accurate result will be obtained with a large number of captured tokens. Thus, it is recommended to have at least 1000-2000 trial tokens before analyzing the randomness of the application session ID.

There are a number of subsections available that can help us analyze the application correctly, but as a pentester we just need to analyze the reliability of the results. To find out more, see documentation…

Let’s press the button “Save Tokens“And save the generated token values in token.txt…

While the file is being saved in the background, let’s log out to bWAPP…

Now, when redirecting to the login page, change the URL inside it by setting:

http://192.168.0.9:8080/bWAPP

And commit the current HTTP request to our burpsuite.

We see that there is a session ID in the cookie header.

Let’s change the session id with one of our saved results.

As soon as we press the button “forward», We are redirected to the portal.php page. It also requires a session ID, so we repeat our manipulations.

And when we press the button again, in the browser we are logged in as “Bee“. This time she was without credentials.

There are times when the session ID we manipulate might not be valid, so in such cases we can use the entire tokens.txt c intruder to hunt for a successful login.

Manual query analysis

What if we don’t have a specific live web application, but we have a sample of tokens or session IDs, and we want to analyze or display their randomness?

Regardless of whether the sample is from a live application or not, the sequencer is always ready to perform statistical analysis, for example, to determine randomness.

On the toolbar, go to the Sequencer tab, to the Manal load parameter, click the button pasteif the sample is on your clipboard, or the button loadif the tokens are in a specific file, then click the “Analyze now” button to start the sequencer.

The sample or number of tokens must be greater than 100 in order to run manual analysis.

After a few seconds, we get the result displayed in a new window as “manual load analysis“.

If the session ID or token is base64-bound, then there is a special option in the sequencer for such cases. IN Sequencer’s dashboard switch to the analysis parameters tab and just turn on “base-64 decode before analyzing“.

Comparison of captured tokens

Burp Comparer is a tool for comparing two requests or responses with each other. Sometimes this makes it easier to analyze different responses.

This tool is the most user-friendly as it works with almost all other burp sections, such as:

proxying requests
fuzzing with Intruder
capturing the response with a Repeater

Most useful, it has its own place in the burp bar.

Let’s use the Comparer tool from our Proxy tab and compare the two intercepted requests captured in it.

Just right click next to the white space of the captured request and send it to Comparer.

Next, intercept the next request and send it again.

Now switch to Comparer Comparator from the panel, where we will see our two queries.

We can even paste a request or response directly from our clipboard by clicking the paste button. It can also be done using the download button.

The Comparer tab offers us two comparison options:

Word by word
Bitwise

Let’s start with words.

As soon as we select the compare option, we have a new window that displays both queries and highlights the keywords:

Modified
Deleted
Added

In the lower right corner there is a checkbox “Sync Views”Which can help us parse and loop through two requests or responses at the same time if the content is a little long.