Cause of the Problem It allows user to sign into the application via login credentials. It is needed because we have to do some transaction, which means shopping & exchanging of our private data to someone else in the world. So some personalized environment is required. Session management is a mechanism which keeps the track record of our each and every request and server response. When HTTP protocol was invented, neither session management nor authentication was taken in to consideration. By now, the internet has become rich and complex, so we need those two things now. That is why it is a question of worry of how to secure it and what are the risk factors of these two things. Techniques and tools to exploit these vulnerabilities are very different, but with their close relation to each other, it is good advice to study authentication and session management together. Path traversal has no relation to these two vulnerabilities. It occurs when a user accesses the different folders and files of the server through the browser. It is a common practice that a web developer puts their files and folders on the server. However, attackers craft malicious requests which later on are processed by a web application and this is how it allows attackers to access the sensitive directory of application server. It can be either a Windows based or Linux based server. Authentication & Session Vulnerabilities The most common attacks against these flaws are proxy-based attacks in which an attacker intercepts requests generated by the browser and tries to play with it. A widely used proxy tool is Burp Suite. Burp Suite is used to brute force the login panel for any legitimate user in order to gain access into their account. This vulnerability will always be there until legitimate users stop picking weak passwords. In Burp Suite, I am going to use an Intruder tool specifically in order to exploit this vulnerability. I will be also generating a common username and password list. A cookie is nothing but a session cookie or you can also say session identifier. Session attacks can be only done under two conditions.
If the session identifier’s entropy is strong.
How the cookie is treated by a web application in order to handle the legitimate user’s account.
Measuring a session identifier’s entropy is nothing but finding an algorithm or sequence by measuring lots of session identifiers. Attackers login into the account various times and note down the session identifier each time. Mostly it is very difficult to detect the sequence of the session, as all web applications connected to the server use different mechanisms in order to generate session identifiers. But if an attacker’s luck is in his favor, then she/he might figure it out the sequence or algorithms used in the application.
This is called a predictable session. Let us suppose that user01 is my legitimate account, but if I want to access another user’s account then all I have to do is to change to user02, and if the application doesn’t verify it and processes my request, then I might get access to the other user’s account. We will see how to exploit this vulnerability in a later part of this article. A novel approach to exploit this vulnerability is to understand how the cookie is used in the application. Testing Authentication via Intercepting Request Browse the NOWASP mutillidae login panel in which we are going to exercise our brute force testing. Make sure that you have configured your Burp proxy with your browser’s proxy in order to intercept the request and response successfully. My approach is to guess the username and password combination in order to attempt the successful login, but rather than approaching with the normal method, once we intercept the request in Burp we will understand which parameters are talking with us in order to take our credentials to give the server. Once we know that we will do the same process with automation. The below figure shows that I have inserted a username and password, and now I will click on login in order to intercept the request via Burp Suite.
The intercepted request is as follows.
Now as we have our intercepted request, we will send this to the Intruder tool within Burp Suite. To do so, simply right click and select Intruder as shown in the below figure.
The intercepted request in Intruder will show as follows. As you can see anything written between $ $ is an input. We can set our payload to all these possible inputs. However for our login attempts we only need two parameters as an input, they are username and password.
In our case, we are going to use Cluster Bomb, as we have two different parameters and sets of payload for them. I have created all possible guessable usernames and passwords in a list on my desktop, and they are as follows:
Now in Burp Suite, we will jump to the payloads tab from the positions tab. Here we have two different files on the desktop, so we are going to use them. In this case we have to select the “Runtime file” option in payload type as follows.
After this we have to select our username.txt file lying on the desktop by clicking on the “Select File” option. Then go to the payload set and select number 2, and do the same process but here this time select the passwords.txt file. After you select your payloads, you are all set to start your attack. To do so, follow the simple step of clicking on the Intruder main tab and then start the attack as shown in the below figure.
After launching the attack, you can see that Burp Intruder is showing all possible username and password combinations from our two payload files. 200 OK Response – It is telling us that these are unsuccessful attacks because if they were successful then the user might have logged in via redirection (302 – Redirect). 300 Redirect – These are a legitimate combination of usernames and passwords which shows that our attack was successful and we have logged in now into the account. We have two ways to verify our successful login in especially this (NOWASP mutillidae) case.
Either we can check the cookie value which will be set according to the userlogin.
Or we can click on the render tab in the below bar which will show us the rendered HTML page when that request was processed and the HTML response came back to Burp.
Session Attacks Different types of session attacks are mentioned below. Cookie Cracking Most of the security researchers in the world first try to decode the cookie value in order to identify the sequence of the cookie. They also identify the algorithm by which cookies are generated. As I have shown in figure 1, that cookie is generated by a simple algorithm which just increases the number of a user cookie from 01 to 02, 03 … and so on. That time is gone when session cookies were created with very weak algorithms. Nowadays there are various fancy algorithms by which it is 70% impossible to crack or find the algorithm by which session identifiers are generated. Use of Burp Sequencer Burp Sequencer checks for the randomness of the session identifiers. It is a very handy tool. First it gathers the various sessions and then it checks for the randomness or the sequence pattern in order to identify the algorithm. Use of Burp Sequencer is shown in the below figure.
To check the randomness of the session cookie, follow the below steps.
Capture the request.
As you can see, that request is already generating a session ID, so if we forward this request to the server, it will respond with the same session ID. So we have to remove this session in order to get a new session in our response. So I am removing this cookie and forwarding the request. Then I am getting a new ID in my response back in the Burp Suite only. That is as follows. Now we will send this response to the Sequencer tool.
In the Sequencer tool, we have to set the cookie value. As in our response, there are two cookie values, so we have to select PHPSESSID in order to perform our analysis. We can do it by selecting the option shown in the below figure.
Then click on start capture on the same panel.
Once you do that it will start capturing sessions issued by the application server.
Initially the Analyze now button will be disabled. However when it receives around 100 tokens then it will identify the tokens in order to check the randomness. When it appears enabled, click on that to see the results.
Here you can check for the randomness of the sessions along with entropy level and other important stuff as well. Other Cookie Attacks Below shows a list of other cookie bugs which are lying in most web applications. This is not the complete list of all session cookie related bugs but these are the most common ones.
Path Traversal Vulnerability When a web server is configured, it gives an application a piece of a file system on which an application puts their important files and folders. Those can contain folders, programming language files such as php, aspx, asp, java, and that can also contain web designing files such as css, html, javascript, etc. Users must not be allowed to access this kind of environment outside an application. An example of this kind of vulnerability is shown in the below figure.
Structure of a Web Server If you use a Linux server, then your ideal web server directory is something like as follows.
I am visiting the text file viewer page in NOWASP mutillidae in order to exploit this vulnerability. It has an insecure direct object reference through which we can exploit a local file inclusion vulnerability by using path traversal. The intercepted request is as follows. The parameter text file is vulnerable. I will remove the value of this parameter and will include…/ series followed by a file named boot.ini which is lying in my local directory of the Windows operating system.
Then I forwarded a request and when I saw my browser, it was showing the content of boot.ini file. It is always important how far and deep you can go by guessing the directory structure of the web server. Your aim should be to reach the root directory. Using../ is dependent on how far and deep you go into the directory. In a simple Linux environment, if you have setup your own pen test lab, then you probably need to use 4 or 5 ../ In order to reach the root level via this vulnerability.
Once you reach the root directory, you can give a simple command that says /etc/passwd in order to see the users with their relevant passwords as shown in the below figure.
Conclusions So these are the common application bugs which are lying in most websites and need to be fixed. I have explained authentication, session and file structure related problems. However, there are high risk threats as well for web applications but these are very common and can be fixed within a few hours. References
https://www.owasp.org/images/b/b8/Predictable_cookie.JPG
http://phpsecurity.files.wordpress.com/2007/11/lfi.png?w=480
http://www.trustabyss.com/images/scr_shots/mods/dir_list_mod_04.png
http://www.tecmint.com/wp-content/uploads/2013/09/Linux-Directory-Structure.jpeg
