If you have the right information, it may be possible to gain access to a user’s account information without any authentication. In this video, you’ll learn about session hijacking and I’ll demonstrate a live session hijack by gaining access to cookie information and manipulating HTTP headers.
<< Previous Video: Zero-Day AttacksNext: Locally Shared Objects and Flash Cookies >>
You’ve probably heard of browser cookies before. This is little information that the browser stores on your hard drive. And it does this so that later on, if you were to close your browser and go back into your browser, your information would still be in there. Maybe it’s information that allows you to easily log into a website. Maybe it’s information that keeps your session active so that you don’t have to log into a website. They’re not generally considered a security risk because they are not executables. But the information inside of the cookie can be a security concern if somebody happens to get their hands on that information. Sometimes the developers of a website will store session information or other details that could be considered very sensitive information and would allow someone else to gain access to your sessions. We’re going to look at this in this video.
So unless somebody is information or access to that information, it’s not really that huge of a security risk but it does very often store very detailed personal information, private information, and sometimes that’s more of a privacy risk then a security risk. So that’s something you should also consider is that your name’s, your email addresses, session IDs, and other information are being stored on your computer. And some of these cookies are used to track what websites you go to and keep information that it then sends back to a central database over time. That may be a security or at least a privacy concern, as well.
The real key for what we’re going to look at today is that some websites, many websites like Facebook, like eBay, and many, many others will store the session ID in the cookie. If you’ve ever closed out your browser and you’ve opened your browser back and you’ve been able to log into a website without having to type in your user-name and password, it may be that the session ID itself is one that is persistent. It stays there. It allows you to connect over and over again without having to re-login all the time. Sometimes it’s one where you’re just keeping your web browser active.
You have different controls over the cookie if you’re a developer, you can decide whether that cookie is only available for the lifetime of the browser, whether it’s only available for a certain amount of time, maybe it’s one that stays regardless of whether you close the browser or not. So you never are quite sure. You have to go to each individual cookie and look if that’s something you’re interested in seeing.
The way that this works is you log into a website– you log into Facebook, you log into eBay, you log into almost any website these days– you say, hi I’m logging in, here’s my user name and password. And if you are authenticated properly, the web server sends you back a session ID, and it probably sends back a number of other pieces of information that are stored in the cookie, but we’ll look at this very high level. It sends back a session ID. And here’s this big hexadecimal session ID that’s sent back. And as long as you send and receive information back to that web server– you send an email, you send some data– and you include that session ID, both the web server and your computer are in sync and it recognizes, oh, you’ve already logged in. I’ve already given you a session ID, great, I’ll allow you to send that message. I’ll allow you to give me that piece of information.
But if the bad guy happens to get that session ID, they can sit now anywhere on your network or even not on your network– anywhere, really– and send this information back to the web server and say, oh, I’m actually this machine and here’s my session ID which happens to match the session ID up there. The web server has no idea of this difference. It has no idea that these are two different machines. It assumes that the session ID is the same, therefore, it must have been the machine that originally authenticated. Now obviously, it’s not a simple process to get a session ID, it’s not a trivial thing to be able to use that session ID, but there are a number of easily available programs allow you to together this information.
You may recall in our video on cross-site scripting that was another one that we used to be able to grab that information and display it on the screen, or give it to a bad guy. If you’re on a network were there are other users you can use things like Wireshark or Kismet, especially for wireless networks, to be able to gather information. These session IDs are usually sent in the clear back and forth over the network. So if we’re able to grab the packets, we can easily see that cookie when it’s transferred back and forth.
Cross-site scripting as we already mentioned is another good way to get that session ID and to be able to exploit that. So cross-site scripting is something that we always have to be careful of. Then we want to modify the headers that we send in so that we can pretend that we are that user with that session ID. So you may use programs like Tamper, or Firesheep, or Scapy that have either automated or very manual ways to modify the headers. What we’re going to do in our case is use an add on to Firefox called Cookies Manager Plus. And that’s going to allow us to have a very easy front end to be able to modify and add cookies into our browser.
To demonstrate this session ID hijacking and using this cookie manipulation to be able to take over someone’s session I’ve got two machines running on my desktop at one time. I’ve got this Ubuntu system and this one is running Firefox. And I’m connected to this device and I’m able to load up and show you information here. Also I’ve got exactly the same thing running to the same server, the same web server, and this is my local computer. So I’ve got Firefox running on my local machine and Firefox running on a separate computer.
So we’re going to login on the Ubuntu system I have here and we’re going to look at the session information. Now this happens to be an application that was not well developed, it allows me to do this session manipulation to it. This is WebGoat. This comes from the open web application security project. You can download WebGoat at owasp.org and you can load it on your computer and try this exact same system. Also in Firefox under Tools you can see that I have already added Cookies Manager. You would go to your add-ons administrator, your add-ons Manager, and load up Cookies Plus Manager yourself.
So what we’ll do is login. We’re a normal user. In fact this particular WebGoat tells you to login using WebGoat WebGoat to see what happens. And let’s do that. Let’s login with WebGoat with password WebGoat. And this is a very simple application. It doesn’t do anything other than tell you that you’re logged in. So you can hit refresh a few times, resend this information. We’re still logged in. So nothing really unusual about that. Nothing changed with this. If we go over to our other computer and refresh, you can see we’re definitely not logged in to that computer. Now because we’re logged in as WebGoat, we should be able look at this cookie information. So under my Tools pull down menu, I’m going to go to my Cookies Manager. And you can see I’ve already got a filter here for this single computer.
So we’re just looking at cookies for that IP address. And I have a session ID. You can see the session ID content right here, this is the value of the session ID information. And here is the auth cookie, and just the name of auth cookie makes us realize this is the cookie we got when we were authenticated. So there are some things we can try to be able to take advantage of that auth cookie. If all we need is that auth cookie, maybe we can re-create this on another computer. So all the bad guy needs to get is some of this information that’s within the cookie. So let’s try that. I’m going to highlight this, I’m going to copy that auth cookie. And what I’d like to do is re-create it on my computer over here. So we’re going to move to the other browser and we’re going to use that auth cookie. Let’s pull this down and I’m going to pull up my Menu. Under Tools we’re going to choose our Cookies Manager as well. And here’s the Cookies Manager for this computer.
Notice I don’t have an auth cookie on this computer, we need to add that new one. So let’s do that. And let’s type in exactly as it was on the other auth cookie. And for the content let’s put in exactly that same auth cookie. I’m just going to paste it right in. And click Save. Now let’s see what happens here if I do a refresh. Notice because I have exactly the same auth cookie I’m now logged in. I didn’t have to put in a user-name. I didn’t have to put in a password. I’m simply now logged into this computer, exactly the same way the other user was. And this application is really bad because I can even log out, you can see clearly I’m not logged in anymore. I can refresh this page, I’m not logged in. But if I refresh over here, I’m still not logged out.
So even though the other user turned off their computer– they went home, the cookie is gone in that other machine– because I was able to steal it, I’m still authenticated, and I’m still in this application, and I can still use it exactly the same way the real user would have been able to use it. And that’s the way that the bad guys would take advantage of these victims is to be able to steal that cookie information, re-create it in their browser very, very easily, and now they have exactly the same rights as the victim.
Obviously you saw how easy it was to pretend that you are someone else on this network, and. It’s something that is very easy to do with some of the most popular websites in the world it’s a very common way to maintain sessions on these systems. So some of the ways that you can avoid this happening to you is to encrypt your session end to end. Do HTTPS all the way to the web server because the bad guys cannot grab your cookie information if they can’t see it. If they’re monitoring that wireless network, they’ll see encrypted data. They’ll have no idea what your authentication cookies, session cookies, or any of your cookie information might be.
Now this puts an additional load on the web server. Being able to do encryption is not a trivial task. It really involves a lot of additional resources. So not all web services will allow this. Not all websites allow this. But the ones that do, you can have your browser automatically connect in an encrypted form. You may want to try downloading some Firefox extensions. There’s HTTPS Everywhere and Force- TLS are a couple that if you go to a website that will support encryption, it will automatically shift you to an encrypted mode just so you don’t have to remember to use HTTPS when you go to those websites.
Another thing you might try to do is encrypt at least across the wireless network. Maybe it’s from your computer to at least somewhere else. So that if somebody was in your local coffee shop on your wireless network that’s in a hotel, they at least would still not be able to see things in the clear. You can see this for instance, using things like a personal VPN like OpenVPN, VyperVPN, or any of the other VPN solutions you might have at your office would ensure that nobody would be able to at least see that locally.
Other people might want to use things like session ID monitors. There’s things called Blacksheep and Application-specific ID monitors for each individual app. That is not a perfect solution but it with the least allow you to see if yourself or other people are out there on the network. Blacksheep’s an interesting one because it will send fake session ID information out and the bad guys never know which one of those session IDs is really legitimate. Session ID hijacking, being able to manipulate these cookies, is obviously a security concern and you should be sure that the applications your users are using, and the ones that you’re using in your environment are protected against these types of hijacks.