Session Hijacking (Whiteboard)

[toggle_content title="Transcript"] Alright let us get into session hijacking. Session hijacking is a really fun module only because you have somebody else to do the hard work and then you get to reap the rewards from it. So let us take it apart section by section. So why does this happen? Some of the reason are obvious, some them are not so obvious. So let us look at them no account loss if you have an infinite session time between the client and server and you aren't locking out or forcing a log of some sort. Then that becomes a ball of goodness for the penetration tester insecure session handling when does the session get created. Once it gets created before you authenticate and sometimes after authentication. It is really, really good for the penetration tester when it happens before you authenticate because if you can gather that session id prior to supplying your authentication. Well then you could perhaps predict the next round of session information or maybe a small session id if there is only an eight bit field then to power of 8 256 possible combinations. If there is a 16 bit field then 65000 combinations or if there is a 24 bit field well then they are 16 million possible combinations. So the longer the key spaces of the session id the more possible values that you have to exhaust in order to actually take over session. So from the pen testers point of view the shorter the session space the easier it is for the penetration tester. Also weak generation algorithms if you view generate your session id on a date time stamp well then that would be relatively easy. Because you just started guessing dates and times and then you use to construct your session id. Infinite session time if there is no log out or lock capability then you can stay connected for example X website but if you could just stay connected and come back 5 or 6 hours, 2 3 days later and you are still connected well then that exponentially increases the likelihood of someone being able to take over somebodies session. Anything in clear text is a value to the penetration tester because if it is in clear text you can read it. If you can read it and sniff it well then ultimately you can start predicting the sessions. We are always interested in predictable information whatever format that comes in. In most of the context here we are talking about the session ids in general but if anything is predictable that is always a value to the penetration tester. Also the sequence numbers in themselves how do you create the sequence number. How did the developer write them at first they may seem like it might not make any sense but a little bit of reverse engineering and you could get really, really valuable information really really quickly. So some of the basic concepts here I want to talk about and really just lay the foundation for why session hijacking is even possible. So the first piece of this is TCP three way handshake remember I am going to send a synchronization request to the server. The server is going to reply with an acknowledgment and their own synchronization request and then of course all I have to do is acknowledge it. That is your three way handshake so that ultimately can be manipulated in the context of session hijacking also spoofing versus hijacking well spoofing is simply claiming somebody else's identity but it is normally directly from the client to the server. Whereas server session hijacking is really watching somebody else's client to server and then ultimately inserting yourself either actively or passively to take over that. So identity spoofing is kind of a precursor or it is one style of attack session hijacking is really different altogether because you are realistically anticipating on I wish to have the option to take over somebody else's session and get access to their resources which brings us to active versus passive. Passive session hijacking is realistically just listening or sniffing or eavesdropping to the details of the conversation where active that means to take our client our source of our client. We knock them offline and then actively their resources on the behalf of the original client. The server is indifferent of who is actually accessing the resources. So you are kind of swapping out the original source. Next we can go into application versus network this is really the focal point where you can focus your time. You could do network level session hijacking or you can do application session hijacking it just really depends on where do you want to exploit the software. Next is session IDs themselves so how are they created how are they used, how are they handled, how are they setup used terminated the penetration tester has got to spend a significant amount of time learning all of how this is done manually and then of course write algorithms so that computers or scripts can actually do this automatically. So while manually is very, very painful and it is working on how to do because if one lays the foundation for how this attacks works ideally what you want is to use a program where you just click a button and you say take over session. Let us do man in the browser. Any sort of software where you have to set up an internal proxy a good example of this burp suite. Because basically you are you own proxy and then that application sniffs all the traffic and then forwards it on. So effectively there is a proxy of some sort in the relationship between the original client and the server whether that happens directly through the web browser or in between over the network by a third party or penetration tester. So we just talked about man in browser but you then you also have men in the middle. So if it kind of the same concept except one is literally a redirect within a web browser application where the man in the middle technique is realistically across the network somewhere also easily accomplished through a cross side script. This is running a script from one site to another. So whether you are using the cross side script to steal a cookie or some other valuable information like a session id. Cross eyed scripting is a very, very popular attack especially nowadays. Alright this is the basic architecture it is client and server or the victim and some sort of application service and the attacker wants to monitor this conversation and knock the victim offline and then take over and get access to that server side service or resource, passively the attacker would just listen actively the attacker knocks the victim offline and then connects to the server. So that is the architecture so let us look at how this actually happens. If the attacker wanted to do a session hijacking attack then ultimately they are going to need to sniff traffic or monitor the traffic. This is where we can gain insight to the TCP through a handshake or how the application handles in the session or any sort of session ID information. Ultimately you are going to do this actively you are going to need to desynchronize the original victim or knock them off line and then once they are offline then you can just take over the session. Now the server or the service side of a relationship at this point they are not distinguishing between an authorized user and an unauthorized user because the original victim has already done all of the hard work. They have already offended they have already been authorized and you are just taking advantage of that. So the last step of this is realistically you can do whatever you want in the relationship. So this is the how do we actually do this? Okay. Now when it comes to session IDs there is kind of - sessions IDs are generic terms. But where do we use these sessions ID concepts if you will one kind of place that is easily identifiable and in clear text is right through the URL. This is where we do sniffing traffic going into the application data digging down and looking at the tool kit. Another place in which it has been found if it is not going to be directly in the URL. Some developers put it in a hidden form field. So you can use any sort of form dissecting or form scalpeland dig out the hidden form field information and this where tools like the Chrome browser make it really easy to tear apart and look at a web page and a source code of that and even to insert your own code and submit that to the server. Also another place in which it is very commonly used is through cookies and themselves. The cookies are just little pieces of code that the server will put on the client to remember things about the session. So the attacker in this case could write a script that says. Hey go get me this cookie from victim and give it back to me and that is where things like the session ID or time stamps or lots of value or information can be disclosed to the attacker. So that is why crossed eye scripting is very much in relationship to session hijacking because you are looking for very similar style information. Let us jump up here to techniques so ultimately we need to figure out how the applications are going to calculate your session IDs. Now there is the classic example of like a date and time stamp format but even that can hashed but you know the format in which the application is using it. It really doesn't matter if it is hashed or not because you can use hashing calculators to ultimately figure out what the different sessions are. So they may not be as if encrypted at first glance ideally we want to steal session information that is what allows us to monitor the traffic and steal the session. There was a great Firefox plugin called fire sheet years ago and there swell spot has not been a great replacement for it. Moreover we are still looking for the replacement but it was a really great Firefox add-on and worked great on wireless networks. So you just had to connect to the same access point and anybody who is connected to any other popular social networking sites you can just monitor the sessions and literally click and take over session. It was really point and click graphical take over based. It was a phenomenal toll. Brute forcing there is another technique here. This is where you have some sort of URL and the session ID has some sort of weak generation. So I used an easy example here of 001 002 003 or this date and then add seconds to it or add milliseconds to it or add days to it. If it is easily predictable well then we can use that to our advantage as a penetration tester. Ultimately we can use forged ICMP or ARP request as well - so this where we have got what we call packeting crafting software. There is a variety of them out there but especially crafted packets to start manipulating pieces of this. I want to zoom out and look at the big picture here. Ultimately what we are doing here is we penetration testers we are experts analysts in terms of looking at information. So you have to learn how to sniff traffic dissect that stuff and really become an expert. As much as I consider myself a penetration tester I very much consider myself just a protocol analyst because it is one thing to watch protocols behave normally but once you know what normal behavior is well then you can start manipulating them and tweaking them in small different ways and you can start changing little tiny features of ICMP or ARP or routing protocols or applications. Ultimately to trick computers into giving you some sort of detailed or juicy information. So forging ICMP or forging request is really just two of the protocols here but you have got to think of this as full blown packet analysis penetration testers at the foundation must be experts in packet analysis at the end of the day. I would even go as far as to say log file analysis as well let us look at the network level couple of concepts here you have blind hijacking anything blind is a technique where you don't see the results. Right so you don't know if it works. It is kind of like throw in the grade on the other side of a wall and you don't know if they blew up or not. Okay. Well we get the same thing from the network level Whether it be SQL injection or session hijacking code goes in but you don't get any response or any information back to you to the end user or the penetration tester UDP hijacking is also possible while TCP has additional fields compared to that UDP. It has things like sequence number acknowledgements and sliding windows and flow control and has lots of information. UDP has none of that - one way that you can easily learn the difference between TCP and UDP is to sniff through some traffic. The sniffing module go back to that and we will watch it again. Because when you look at sniffing TCP verus UDP the best way to learn about these protocols is to sniff the traffic and watch the normal behavior over them. Once you understand the normal behavior then you can start using package crafters and then manipulating that to achieve some sort of an objective. Whether it be like men in the middle or cross side scripting or whatever. TCP/IP now we are still on version 4 so it is not going to away yet and I don't think it is going to go away anytime soon. A version six has been out for some time now and we are just slowly starting to go in the IPv6 route in 2014. But it is not here yet. So there is still going to be plenty of hacking to do on TCP/IP version 4 networks for some time to come. So if you haven't learnt TCP/IP version 4 it is never too late to learn. Because I still believe just like those old windows servers and NT 4 servers that are still around for whatever reason. There is still going to be TCP/IP version 4 networks for years and years and years to come. Reset hijacking now to appreciate reset hijacking you have to go and look at the TCP/IP protocol. Remember I sent you the synchronization you reply with your acknowledgement and your synchronization and then I finally acknowledge it. Well in a normal conversation if we are done. I would send a finished request or whatever side is done since the finish request. It is kind of analogous to when you are done talking on the phone if you are finished to say. Hey I am done I am going to hang up well a reset is kind of like all of a sudden the phone is disconnected and you have to pick up and redial again. So reset hijacking is realistically sending a reset packet to one side of the conversation. Either the victim or the server the client or the server and tricking them into some sort of behavior. So if I could send you a reset packet and you think I have been disconnected. Let me pick up the phone and dial again and this time you are dialing to the attacker as opposed to legitimate service while you could take over session. An easy way to get yourself is to be in the middle or IP spoofing and we have already covered that with spoofing your source address but it is just technically it is another component of network level of attacks. So we talked about the why we talked about concepts we talk about where it happened. We talked about the network level - now let us go and look at some of the counter measures. By far one of the easiest way is that you can prevent a session hijacking is to encrypt the traffic or what I generically say encrypt your stuff. Whatever that stuff is use protocols like SSH or HTTPS or whatever it is at the network layer you could use IP sec or you can use an application and use things like SSL SSH and TLS. Also use good random number generators. Some random number generators aren't really that random. Which kind of defeats the purpose and I find irony in that because it is supposed to be random but it is not really random. It is called pseudo random as opposed to completely random use a really, really good random number generator. So that when you choose your session space with that session IP really comes out of thin air. It is not based on anything previous so that is good. Generate the session id after log on - you don't want to give pieces to the attacker or penetration tester and then make them authenticate that discloses information. So encryption and disclosure work together - well the same thing here. If you generate the session id after you log in or log on then that naturally prevents certain information from being disclosed. Simply stated have a log out functionality and not only use two factor authentication but have a two factor challenge. It is a little bit more robust here but it is a great way to counter measure session hijacking. The reason being is because let us return the attacker takes over a session. If the attacker captures the authentication information and then the server says hey who are you. You just replay the authentication information and boom you are in. But now if you have to tie in two factors to - something you know - something you have or something you are in addition to just regular authentication well then the attacker or the penetration tester is ultimately stuck because now they don't have what the original victim has. So use two factor challenges or two factor authentication that is a great, great counter measure. Education may people wear what strange behavior what does session hijacking look like. If they understand the symptoms of this well then they identify it. They might start logging out voluntarily on their own - I mean think of it this way. Would you start voluntarily logging out of your banking website. If you know that hey somebody else could take over and wipe out your account. I know I would also the concepts of switches versus - meaning virtual private connections versus shared mediums and things like access points. Wireless action points you can typically sniff a lot of the association type traffic that is kind of equivalent to a hub. You can switch that over to switched environment well then you have these virtual private connections. Well if port A and port 1 and port 3 communicate to each other none of the other ports on the switch or the medium should be able to hear what that conversation is. So it is kind of like a virtual private connection. Just between me and you - use strong authentication you can use tools like and there is other alternatives to arp watch out there but remember this is likely to happen on a switch or a network somewhere so arp watch detects the flooding or the knocking offline at layer 2. Also defensive in depth, in theory that is don't rely on any one technique a variety of counter measures is probably the right way to go here. Also use time out features or log out or log off features. Keep your software up to date that always goes with best practices make sure that you are on the latest and greatest that way you naturally reduce your surface area of attack and then follow up with encryption at the network layer. Because session hijacking is either happening at the network level or at the application level. The more information you can naturally encrypt well then it is not disclosed. We want to protect things at the network layer using things like IP Sec therefore the attack or the penetration tester can't hear what is going on. Then they can't predict the session tokens - then they can't take over the session. Doesn't matter if it is at the network layer or the application layer. If you are using things like SSL and TLS well that would be great. Because now the penetration tester has the same exact problem - if they can't sniff the traffic they can't predict the sessions. If they can't predict the sessions. They cannot insert themselves into the middle they cannot be offline etc. Session hijacking in itself is one of my favorite modules because realistically as a penetration tester you are letting somebody else do all of the hard work and you are taking an advantage of all of the weakness. Let all the hard work be done by somebody else and then you just reap the rewards of it and there are some pretty good tools out here that can do away with. Now some of the tools are like freeware oriented but commercial session high jacking tools are very, very expensive and script kitties aren't likely to go for ten or fifteen thousand dollars for one piece of software. So session hijacking very, very important stuff can be done at the click of a button also can be done at the script kitty level but nonetheless very, very important. So let us go ahead and take a look at some examples. [/toggle_content] In this whiteboard lecture, you'll learn about session hijacking: what it is, how to do it and the best tools for doing so. Session hijacking is finding and taking over an existing network session. Every time you are connected to the web you have a unique ID or session which defines you as a valid user. Hackers try to identify these IDs and then gain privileges as a valid user on the web.
Recommended Study Material
Learn on the go.
The app designed for the modern cyber security professional.
Get it on Google Play Get it on the App Store

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play

Support Cybrary

Donate Here to Get This Month's Donor Badge



Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?