Our team had a discussion regarding the safety of session id’s some time ago. The main topic was “how safe is it to rely on the session id alone?”. Discussion went on and on – and I made my point of view very clear. You can’t rely on it. Unless you know how the CMS handles the session id you can’t really rely on it. I have tested a lot of CMS’s over the years – some have been good and some have been bad. Really bad. This is my proof of concept report on how to hijack sessions.
In this demonstration we are targeting a site running on a local server. This servers serves a handful of sites using virtual hosting. One of these sites runs a fully updated CMS – which we are targeting. This CMS is deployed using a stock (naive) setup which, sadly, is very easy to exploit. This CMS will never be deployed in production and is not available from the outside.
This demonstration will touch upon how to obtain session id’s in non legal matters. Do not try this at home, school or anywhere. Be cool – stay on the right side of the law.
- Google Chrome browser. We’ll obtain cookie information from this using the developer console.
- Burp Suite. A very good tool for testing security. It doesn’t come with a brain.
Step by step
There are many ways to obtain session id’s. Two common techniques are to sniff the network and/or trick the user using XSS. This demonstration will show neither. Session ID were copied from the response header from the server after admin successfully logged in. Chrome offers a nice view of responses in the developer console.
With access to the session ID the attacker must find a way to send the information to the server. There are a myriads of tools for this on the market – but for this demonstration Burp Suite is chosen. Burp Suite offers a tool for writing custom HTTP headers. This tool can be found under the “repeater” tab.
Using the “raw” input it offers the following header was entered and sent to the server:
GET / HTTP/1.1 Host: crazycms.localhost Cookie: session_key=session_value; logged_in=true
- First line reads out as: Use “GET” request to fetch index page (“/”) using the “HTTP” protocol version “1.1”.
- “Host” field: If the server hosts several sites the server will use this information to determine which site to serve. This was set to the desired site the attacker was trying to abuse.
- “Cookie” field: Information related to session was inserted in this field.
Viewing the response information in the “render” tab of Burp revealed admin access had been obtained. Strangely – simulating admin logging out using Chrome resulted in the CMS showing the admin as logged out. As it should. However – resending the specially crafted header showed, in Burp, that this user was logged in still. Now – there are many ways to invalidate the session key. On my own CMS’s I make sure that the session key is invalidated upon log out to prevent these attacks. But this is stock software from a well known blog engine.