We used Burp Suite to demonstrate an experiment on enumerating sessions IDs created using PHP language. The source code used a vulnerable mechanism in creating the session ID by assigning a numerical value in a pre-determined range and linking it to the user’s profile. When the session ID isn’t randomly generated, it makes the web application vulnerable to session hijacking attacks. We used OverTheWire war games Natas Level 18 – 19 challenge for demonstration purposes. . This was part of OverTheWire War Games Natas Level 18 – 19
Natas Level 19 Password
8LMJEhKFbMKIL2mxQKjv0aEDdk7zpT0s
Video Transcript
What’s going on guys? Welcome back to this video today. We’re doing over the wire WarGames.
And we’re going to tackle down the level 18. So the last video we did it was on level 17 do they were doing level 18 and I’m going to remind you guys at night is level or night has challenges our web application penetration testing challenges. So we head over to notice 18 after we provide the password of the previous level.
I will see a login form. Okay, we click on view source code since this is kind of white box pen testing. We have access to the source code of the application. So we click on The View source code.
And the first thing we notice here is this line? This line defines a variable named Max ID this variable equals to 640.
If we read through the code. This line there is a function to create an ID. And as you can see here, the ID is generated. To be between 1 and the maximum ID that has been defined earlier in the code to be equal or to be equal to 640. So scrolling down later. We see here the function responsible for generating the session.
And here what we get if we have the correct session so basically The problem in this code lies here the session ID or this number is used to generate the session ID. Okay. Now session IDs if the attacker is able to guess them or generate them or find the correct session ID for the user there looking after.
The attacker will be able to access the user’s profile without the need to find the password. So we call this session hijacking. And what’s the problem here? The problem is the session is defined or is generated is a number generated between one and six hundred forty.
This means that most of the users who are registered on this website. Okay, as users. Okay, these users they have such an IDs between one.
And 640 which means we are able to guess which user ID belongs to which user we’re going to be able to get access to any user profile.
So that’s the problem in this code. Now the secure alternative to this is to randomly generate the session ID.
We cannot Define a specific value or range for the session ID. Okay. So what you do here, we can solve this challenge using two methods. We can either either do it using python. We create a script and we Brute Force the session ID of the admin user. Basically we’re gonna Try numbers between one and six forty with every session see which one ends up with the admin user or we’re going to need to use burp Suite which I’m going to use in this video because we have done many challenges where we solve the challenge using python today. We’re going to use purple sweet. Let’s go back and open Burp Suite Let’s first take a look At the request so let’s say we start admin admin.
Right now, let’s simulate a login Request using the username admin and the password admin.
So now we can intercept the response because we want to see the cookie assigned.
Let’s take a look here. As you can see guys in the response. We see the session ID is set to 498.
Okay. Now what we’re going to do we’re going to take this and send it to the Intruder. Okay, so now we’re going to forward and now we’re going again to set the intercept or going again to intercept request So refresh.
So now let’s simulate the request one more time. Alright, so this is the request again and here notice that the request is get requests.
And another thing to note here is the session ID. So we’re going to do here. We now we want to brute-force the session ID want to find the correct number that is tied to the admin account. Okay, so we want to send this to the Intruder before doing that. We have to remove this somehow we have to remove this line.
We only want to keep the session ID. And then it’s ready to be sent to the intruder.
Go ahead. He would Define the payload positions going to clear and set the position. From scratch. So here we highlight the session ID and we click on ADD. And now the session ID is highlighted next we Define the payload type. So we set the type two numbers and here we set the sequence. So we’re going to start say from zero and go all the way up till we reach 1000 you can Define more but don’t Define less than 700 or so.
140 and then we go to start attack. Alright, so now that that is started.
As you can see here, all the requests have similar length in the response. Take a look here. Most of them are 608 608 607 sorry 67 and so 67 ends with 68. So we’re gonna look for a response that is kind of very different in size like far away from this length.
So that we know that we have a different response for this request. We take a look at the request and we take a note of the session ID and we’re going to try it. Let’s wait now.
Okay, so the Intruder finished and here I found the ID to be 119 that generated the different risk response. So we’re going to put it as the new session ID and we’re going to say forward.
Checking the browser and as you can see guys, this is the bastard for the next level. So the ID the correct ideal was 119.
Video Walkthrough
