WebGoat Part 2: Session Management Flaws (Hijack a Session)

Concept / Topic To Teach:
Many applications will automatically log a user into their site if the right authentication cookie is specified. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.

General Goal(s):
The user should be able to bypass the authentication check. Login using the webgoat/webgoat account to see what happens. You may also try aspect/aspect. When you understand the authentication cookie, try changing your identity to alice.

First Hint: The server skips authentication if you send the right cookie.

I tried to random username and password to get cookies from webscarab. The result are:
Cookie: WEAKID=19518-1309378397801; JSESSIONID=663FE77D11103E8A8607EA8E391AE86E



Second Hint: Is the cookie value predictable? Can you see gaps where someone else has acquired a cookie?

Seems the cookie not suitable for to access an authenticated session.

Third Hint: Try harder, you brute!

Fourth Hint: The first part of the cookie is a sequential number, the second part is milliseconds.

Fifth Hint: After the 29th try, the skipped identifier is printed to your screen. Use that to login.

From this, i started nearly to deadlock. When look the page solution, it's time to think again and keep moving forward..

In this lesson the purpose is to predict the WEAKID value. The WEAKID is used to differentiate authenticated and anonymous users of WebGoat.

Solution:

The easiest way to complete this lesson is to use WebScarab's Session ID Analysis.

Go to WebScarab and click on the button "SessionID Analysis". Select the last POST request from the "Previous requests" drop-down box.

Figure 1 WebScarabs SessionID Analysis

To make sure that WebScarab is able to fetch the WEAKID cookie, you need to click the "Test" button on the bottom of the screen. A pop-up window must be shown like below.

Figure 2 SessionID WEAKID discovered

If you don?t have a pop-up window with the Extracted Sessionids, you must edit the Request. You must delete the WEAKID value from the request. Without this cookie value, WebGoat will return a HTTP Header "Set-Cookie: WEAKID=value" so WebScarab learns about this value.

Fetch 50 samples and examine the results. Enter "50" in the "Samples" window and click the button "Fetch". You will not see any information about progress.

Now you need to go to the tab "Analysis".

In the "Analysis" pane you see nothing.

You must select the Session Identifier WEAKID value from the drop-down box.

The WEAKID is divided in 2 parts: the first part is an identifier that is added 1 in every cookie and a time value. The time value is calculated at the moment that you submit the request.

Notice that there is sometimes a gap in the first value of the WEAKID, skipping with 1. The value that is missing is the value that you need to know to log on. Now you only need to calculate the timestamp. This can be brute-forced using Crowbar. You know the previous timestamp and the next timestamp so you have a start and end value.
You can download Crowbar for free: http://www.sensepost.com/research/crowbar/

There is a value 16935 and a value 16937 with a numeric difference of 28110 instead of 14109, so there the WEAKID cookie is located. Copy and paste the raw HTTP request in Crowbar:

Figure 3 Crowbar

Change target to localhost and adjust the port.

Create a Base response. Make sure that you see "How to hijack a session" in the middle window.

Insert ##1## in the WEAKID parameter where you want to brute-force the value and be aware, that the first part of the WEAKID is the one we are searching for (16936). The WEAKID in Crowbar lookes like this: Cookie: JSESSIONID=...; WEAKID=16936-1163685##1##;
Start the first loop at 363093, the last digits of the last cookie before the authentication cookie and 363203, the first cookie after the authentication cookie. You have to enter these two values in the Parameter1 fields. We have to brute-force these values, but we are sure that they lie between these two boundaries.

Examine the results until you see a different fuzzy logic value (the blue line in Figure 3), right-click it and click on "Show reply".