Ethical Hacking: Session Cookie TheftBy Mike Danseglio
Watch these Ethical Hacking videos, and you’ll understand skills like Denial of Service (DoS), social engineering, hijacking, and more. With these tactics of ethical hacking you’ll learn security techniques through the mind of an attacker.
Remember, browser cookies are just files on the hard drive of the client. If the session itself, session information around authentication, authorization, and any kind of traceable information that you can use for later re-establishment, is kept in a cookie and on the hard drive, that’s yet another file that you compromise when you compromise a system. You steal those out and then you examine them. There are a number of tools out there, not just to examine cookies, (although Notepad is a fine example of a tool that can examine cookies), but in a lot of cases, cookies can be compromised; they can be changed.
Cookies oftentimes are not authenticated. They are not signed. They are not validated so there may be an expiration date in a cookie that you just hack with Notepad or you use a tool to change it and change or checksum for it. Then you have a cookie that lasts a lot longer than the intention was.
Because they are just files, again, it’s just a matter of footprinting to identify which clients are using the credentials you want, as you learned in an earlier video. Once you’ve compromised that client’s system, you can steal the cookies and then analyze them offline. Some of them may not be usable, some of them may be usable, but it’s certainly worth a try.
Looking at the cookies, stealing the cookies and finding out what’s in there doesn’t really affect the client so it almost never sets off alarms.. It’s more of a read-only attack. It’s pretty elegant and it’s extremely low noise. There is a very low likelihood, once the compromise has been made, of actually setting off any alarm bells.
Calculating Session ID Numbers
Occasionally it is possible to calculate session ID numbers and parameters. It’s actually really hard to do because it does require some type of non-random sequence number, which is one of those vulnerabilities in operating systems or services that’s immediately patched, or some type of other predictable data.
The idea of session calculation is feasible; it’s just not very practical. It’s not one of the first attacks I would mount against a client. It’s actually not one of the ones I would do almost ever.
Unless there is a major vulnerability, it’s not likely it will succeed. You will occasionally see a service bulletin or an update for a Windows, which, for example, will say the TCP sequence number could actually be predicted, so we’ve made a change in the code.
The patch is preventing this type of vulnerability, and again those are extremely high priority and extremely straightforward fixes. So, these vulnerabilities when they are there, don’t last very long and are almost always fixed.
I do not recommend this, but it may be on exams or you may read about it, so this is something just to be aware of. That’s what it’s all about, calculating the session ID and then using that calculation to predict the next sequence number or some next data that you can actually use to get in the middle.
Sequence and ACK Numbers
A similar type of attack, but one that requires a bit more pre-work to compromise, is hijacking based on sequence and ACK numbers. This means actually being able to predict and calculate those numbers. They almost always require you to do some type of network sniffing on the session at the client end to figure out what the seek and ACK numbers are.
You need to uncover where they are going and how far they’re implementing, and then you need to jump into the middle by crafting some special IP packets that actually use the correct seek and ACK numbers to convince the server that you are the client.
It also requires, at the same time, that you potentially block incoming traffic from the server to the client and become the client. At the same time, you need to interrupt the connection and intercept the traffic. It’s relatively hard to engineer, but it’s an interesting type of attack in theory.
Brute Force Hijacking
Another type of session hijacking attack is also interesting. A brute force hijacking attempt is actually either really easy, or really hard, depending on the pre-knowledge and the footprinting work that you’ve done. Essentially a brute force attack against session hijacking goes like this:
You will use some type of knowledge that you’ve gathered around URL parameters, whether from sniffing the connections, connecting to the server on your own, doing some kind of HTTP header captures or even doing things that are a little bit different like screen monitoring and grabbing screen captures from the client. You might look over the client’s shoulder, which you learn about in the video on social engineering, and take a look at some of the URLs that are going on there.
This comes into play even when someone sends an email with a URL that has in it a part of a session ID. You want to actually take a look at the URL, from email, shoulder surfing, screen scraping from footprinting or sniffing, and determine if there are any hints about the session ID.
You’re looking to see what types of session IDs the system or server uses and whether they are predictable or sequential. Then you just perform brute force and try different session IDs in the URLs until it works.
Again, it is either super easy or super hard depending on how much knowledge you have of what’s going on on the server, and also, how resistant by design the server is.
A good example of brute force session hijacking really is at the very top here. For Example, this URL will have a session ID AFAD0110. If you’re sniffing, or shoulder surfing, and you see that session ID equals, (and that’s actually how the session is held open. This session ID in the browser is appended to all transactions within the session) you may actually be able to get back to your desk, or go somewhere else, and try different session IDs that are similar to this existing session. You can even try this same session ID to see if that will work.
It’s actually more of a trial and error thing, but it’s somewhat predictable. I’ve worked with some clients that use session IDs on a session by session basis. I’ve seen some where they stick the account ID or some type of statement ID at the actual end of the URL. Just sequencing this one up, one down, using the same one later, sometimes yields positive results. It sometimes actually allows a hack to occur. That’s kind of great.
It’s not terribly different than URL manipulation with a SQL injection attack, but instead of trying to pass database commands, you’re trying to use a session, or get access to something that you shouldn’t have access to.
Occasionally you’ll also see this in the form of a parameter on the end of a URL that establishes the session by explicit path. It might actually be a path into a file or a DLL or something like that on the server. Again, that’s another opportunity for you to examine the URLs, modify them, or even copy them and use those as part of an attack.
About the Author
Mike Danseglio has worked in the IT field for more than 20 years. He is an award-winning author, public speaker, and instructor on a variety of technology topics including security, virtualization, cloud computing, wireless and wired networking, and IT lifecycle processes. His operations experience includes managing the Xbox LIVE operations team, the largest cloud computing operations team in the world, and consulting on operations efficiency with countless clients around the world. Mike has published several books (including two for O’Reilly) and numerous papers. He is a frequent conference speaker and classroom instructor on IT operations, computer security, and technology frameworks. Mike holds a number of certifications and accreditations including Certified Information Systems Security Professional (CISSP) practitioner and instructor.
Author's Website: http://www.nextdirectiontech.com/