Session Hijacking – CompTIA Network+ N10-006 – 3.2

| April 26, 2015 | 0 Comments


We rely on session identification to manage many aspects of our application use, but an insecure session ID can be a significant security concern. In this video, you’ll learn about browser cookies, session IDs, session hijacking, and header manipulation.
<< Previous: Brute Force AttacksNext: Social Engineering >>


When you visit a website with your browser, it’s very common for that site to store a little bit of information on your machine that will be used for later. That information is called a cookie. The browser uses that and generally only uses that for that particular site that you’re visiting. Generally cookies are not shared between websites. These cookies can be used to track what you’ve done on that server, they can be used for personalisation when you change how the server provides a view of that website to you.

They’re used for session management which we will talk about a lot in this video. These are not generally executables, though. Sometimes people think that cookies on a machine are a security risk, but generally cookies are there to work for you and provide customization of your browsing experience. Usually they’re not a problem unless somebody happens to gain access to a cookie that does not have encrypted information inside of it. In those particular cases, that would be a security risk because somebody gaining access to your cookies might also gain access to personal information about you.

Session ID information is very often stored in the cookie. There are a number of sessions that you will have with a web server, and in order to keep you logged in and recognize you the next time you visit, instead of having you log in again, it can store this session ID and that makes it much easier to authenticate and gain access to a website. If it is a well secured cookie, the information inside the cookie is going to be encrypted or obfuscated in some way. No one would be able to see what’s inside of it or in any way tie that cookie back to you.

Let’s step through the process of somebody hijacking a session. This is often called sidejacking. And we’re going to see this occur to a web server that is sharing information over the internet in a non-encrypted form and the session ID is being sent in the clear across the network. And this is what happens when a user logs in. They provide a username and password to a web server, and when the web server authenticates that user, it sends back a session ID that is then stored on this victim machine.

If somebody is monitoring the network during that time frame, they can see this conversation take place. And if it’s done in the clear, they now know what the session ID is. And if the only check that web server is doing is of that session ID, the attacker can then use the exact same session ID, gain access to the web server, and be automatically authenticated to that web server because the web server is trusting the session ID.

It’s assuming that user has already logged in, but in reality, it’s a completely different user who’s now gaining access through this sidejacking or session hijack. You would generally obtain and use this session information by gathering the information from the network and then perhaps even modifying the header information that was being sent to the web server. And as you can imagine, there are a number of tools available to do exactly this. If we want to gather information from the network, we know there are many different protocol analyzers out there.

We can use Wireshark or Kismet or many of the other analyzers that are available to capture packets directly from the network. If the web server is vulnerable to a cross-site scripting exploit, you may be able to gather session information on the web server itself. This gives you the advantage of seeing a lot of people authenticating to the web server and getting out a lot of session IDs. And you’re also avoiding that encryption process that normally would take place across the network. Now that you have these session IDs, you need to be able to use them.

Some web servers are looking for the session information in the headers themselves. And in that case, you’ll need to use a tool like Tamper or Firesheep or Scapy to be able to modify the headers that are being sent to the web server. Sometimes the session information is in the cookie itself, so you need to modify the cookies and add your own session information directly into the cookies using something like Cookies Manager+. There are many different add-ons for many different browsers that allow you to really manipulate the details of every single cookie on your computer.

One way to prevent somebody from gaining access to your session ID would be to encrypt it. You would have an encrypted session between your browser and the web server using something like SSL or HTTPS. There are many browser extensions that will automatically change your session to be one that is encrypted if the web server supports it. And that way it doesn’t matter what you type in at the address bar of your browser, it will automatically switch over to an encrypted form if that’s available.

Instead of just encrypting traffic to the web server on an individual session basis, maybe you encrypt everything by using something like a VPN. This would obviously be in the clear to a particular VPN concentrator, but if anybody’s trying to grab that session information on your side of the concentrator, all they’ll see is encrypted data. You can even use session ID monitors to see if somebody’s trying to use these session IDs. Utilities like Blacksheep will send fake session IDs out to the network and then listen to see if somebody’s trying to use that fake session ID. That will make you aware that somebody is trying to take advantage of these session IDs and perform a session ID hijack to the web server.

Tags: , , , , , , , , , , ,

Category: CompTIA Network+ N10-006

X