Lesson Plan Title: How to Hijack a Session

Concept / Topic To Teach:
Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks.

General Goal(s):
Try to access an authenticated session belonging to someone else.
In this lesson we are trying 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 feature. The Solution Videos provide another method of uncovering it as well.
To access the Session ID Analysis, you need to put WebScarab in its full-featured mode, if it isn't already. This can be enabled by going to Tools -> use full-featured interface in WebScarab.
Click on the SessionID Analysis tab at the top of the page, then use the Previous Requests dropdown to select the most recent GET request with a 200 OK header. Its address will end with webgoat/attack, not an image or java file.
Selecting the correct GET request for Session ID analysis.
Next, we need to make sure that WebScarab is able to fetch the WEAKID cookie. Click the Test button at the bottom of the page. You should get a popup window showing the WEAKID.
Succesful WEAKID test popup.
If the popup indicates that no valid session is found, that means there is already a WEAKID value in the request. This prevents the "Set-Cookie" header from being sent in the response. To fix this, delete the WEAKID=value; portion of the Cookie header and press test again.
Now we need to fetch a set of WEAKIDs. Enter "50" into the Samples field at the bottom of the window, then press Fetch. Switch to the "Analysis" tab. Select the WEAKID option from the Session Identifier dropdown, and the window should populate with WEAKID values.
The WEAKID is divided into two parts: the first part before the dash is an identifier that increases by 1 in each cookie, and the part after the dash is a time value that is calculated when the request is submitted.
Notice that there is sometimes a gap in the first value of the WEAKID, where one number is skipped. The missing value is what we need to log in, we just need to figure out the time stamp value that goes after the dash.
It's simple to spot where this value is. Look at the "Difference" column on the analysis screen. Almost all of the values will be only one or two apart. We are looking for the record where this value is around double the rest of them.
Analysis screen with the cookie of interest highlighted.
This WEAKID follows the one we're trying to find. You will notice the identifier of the cookie preceding the highlighted one is two less, whereas all the other cookies decrease only by one. The one missing is what we want to find:
16964-1312472439375
16966-1312472439484
The WEAKID beginning with 16965 is missing. This is the WEAKID we want, we just need to figure out the second part.
We'll figure this out by using the brute force method. We will send requests with each possible timestamp value until we find one that is successful. Its timestamp must be between the two surrounding it:
16964-1312472439375
16965-?????????????
16966-1312472439484
So our timestamp is between 1312472439375 and 1312472439484. Now we just need a program to do brute force this for us. We will use J-Baah, previously known as Crowbar. Download it and run the .jar.
We will configure J-Baah to send our request repeatedly, with a different WEAKID each time. Copy our RAW HTTP Request we used to generate these cookies, found under the Collection tab. Paste it in the Request box in J-Baah.
The WEAKID paramter needs to be put into the request. It will begin with the missing value we figured out before the dash, 16965 in our case. How do we fill in the rest when we dont know what it is?
In this case, we will add WEAKID=16965-1312472439##1##; to the Cookie paramter of our request. The ##1## replaces the part of the timestamp that varies in our range. Next, we specify this range. In the Paramter 1 Tab, we set From as 375, and To as 484.
J-Baah setup.
Lastly, go to the "Target" tab at the bottom right, and set the Host to localhost and the Port to whichever port WebGoat is using, generally 80 or 8080.
Go back to the "Action" tab, and click Base Response. You should see a message on the bottom left that a response is generated successfully. Change Threads to 2 and then press Start. The bottom left window should start filling up with "Hijack a session"
All of the responses for each WEAKID. The successful attempt is highlighted.
Before we go any further, it is important to understand what is happening here. The ##1## string is replaced with a different number in the range we specified and the request is sent. The first WEAKID tried is 16965-1312472439375, then it tries every timestamp until the last one, 16965-1312472439484. J-Baah collects all of these responses and shows them in the bottom left window.
Each line shows one response, and displays important information about it.
0.99969 : 417 : : Hijack a Session
Clicking base response tries the first WEAKID and sets its response as the control. This first number indicates how similar this response is to the base response. A value of 1 means the responses are identical. The further the number is from 1, the more different this response is.
0.99969 : 417 : : Hijack a Session
This second number is the value replacing the ##1## in our request.
0.99969 : 417 : : Hijack a Session
The last portion is the title of the response page. In this case, if it's not "Hijack a Session", something went wrong.
The value indicating similarity to the base response will tell us which WEAKID worked. If everything went swimmingly, there should only be three values for this number. Look again at the screenshot above. There are many responses showing .99969, one showing .9949, then many more showing .99954. The response stayed the same until we got to the WEAKID ending in 429, then it changed. This is where the brute force succeeded. Right click on this response and click "Show Response".
This WEAKID worked! We hijacked this session.
Refreshing the lesson should show it is complete.