A couple of months ago I wrote about how fellow author Dale Meredith and myself are building out an ethical hacking series on Pluralsight and in that post I launched the first course I had written for the series on SQL injection. You can read about the ethical hacking series in that blog post and what my approach to covering the CEH syllabus has been (hint: I have my own take on it), but what I will again point out here is that this material remains by far and away the most requested content in the entire Pluralsight catalogue of course suggestions:
The viewership of the ethical hacking series has absolutely exploded! All the courses we’ve created so far have enjoyed time in the Top 100 most popular courses in the library which puts them in the top couple of percent given there’s now over 4,000 courses. In fact to his credit, Dale’s intro course to the series has spent considerable time in the Top 10:
When you’re vying for position with Scott Allen, you know you’re doing something right! Kudos to Dale, it’s a testament to both the quality of the content and the demand for good security material.
I’m very happy to now introduce the fifth course in the 20 part series, Ethical Hacking: Session Hijacking. Let me tell you what it’s about.
Understanding session hijacking
I’m going to start by talking about how web apps persist sessions over HTTP then give you one solid example of session hijacking and finally I’ll tell you a little more about the course. Firstly, session hijacking is serious stuff. OWASP has it up there in the number two risk on the web today as part of broken authentication and session management in their Top 10 Application Security Risks publication (incidentally, I have three different Pluralsight courses on the Top 10):
Not only is sloppy session management up there in number two, XSS is number three and that’s frequently a vector by which a session hijacking attack is mounted.
When we talk about session hijacking in web apps, we’re usually talking about exploiting the way session persistence is implemented over HTTP. You see, HTTP is stateless, that is it’s not a constant connection that’s left open between your browser and the web server. You make a request, the connection closes then you make another request and at the HTTP level there is no continuity with the previous request. For example, if you login to a website then request another page, HTTP itself doesn’t have a construct to keep you logged in, it’s something we need to build into the app.
This is why we use tokens to persist sessions and in very simple terms, they work like this:
The token is returned by the server after logging in and then on each subsequent request, the user’s browser sends the token back to the web server which then says “Hey, I know you, you’re the person who just logged in because the token you gave me matches my record of you”. The server may then apply authorisation rules that govern what the user can access and can also record the user’s identity against transactions, for example if they leave a comment on a website which they needed to login to first.
Session hijacking is all about the attacker gaining access to the token the victim is using. If they can get hold of that then they can send it off to the website with their own requests and impersonate the victim. What’s really key here is how the token is persisted between requests and then what attack vectors might exist that allow an attacker to gain access to it. For example, is it persisted on the client by cookie or URL? Is there an XSS risk on the site that could allow access to the cookie? Is the token being passed to external resources via the referrer header if it’s persisted in the URL? Is the token enumerable, that is can the attacker guess what it is because it adheres to a predictable pattern? We’re just scratching the surface here, but you get the idea.
Let me give you one solid example of how a session hijacking attack can take place.
The mechanics of a session fixation attack
There are many different variants of session hijacking attack that exploit various weaknesses in web apps. One of these attacks which I often find isn’t very well known by developers is a session fixation attack. The idea here is that the attacker is going to predetermine the session ID the victim will use. For example, the attacker may send the victim a link like this via social media or email or some other form of phishing campaign or social engineering: http://TargetWebsite.com/(S(1004744))/
In this case, the session ID is being persisted in the URL (it’s the path after the host name) and when the victim follows that link, they’re now using that ID. As they navigate around the site, the session ID is persisted in the URL so at any time the web app can say “Ah, I know who you are, you’re the person who owns session ID 1004744”. Anything the server stores in session state is then attached to that ID. That’s another thing a lot of developers don’t realise: when you put something in session state in a web app, the app actually has to store it somewhere then provide the correct session state data back to its rightful owner. It looks like this:
In this example from the course, I’m talking about different mechanisms of session state persistence:
- In-process: This is the web server storing it in the worker process where the application runs (incidentally, that’s the default IIS implementation)
- State server: This is an example of out-of-process session persistence where a dedicated service maintains session state that’s preserved when the web process is recycled (it also means the data can be accessed by different web sites such as in a load balanced environment)
- Database: Similar upsides to the state server approach in terms of detaching session state from the web server process, in this example the session data just gets persisted in a database
You can read more in the Session-State Modes doco for ASP.NET but this paradigm is by no means limited to Microsoft’s web bits, the same concepts exist in other web stacks as well.
Getting back to the session fixation attack, if the attacker “fixates” the victim’s session ID by providing it to them in a link, anything the web app stores in session state for that victim will be accessible using the session token they access the site with… the one the attack already knows! This is where it starts to get interesting.
Let’s say the victim now logs in. There may have been nothing of consequence stored in the session state for that ID when the attacker gave it to the victim, but what often happens in web apps is that authenticated state is persisted in the session. In other words, when someone logs in their identity is stored against the session ID and persisted in one of the models in the diagram above. When the individual now goes to, say, the comments page on the site they’ve just logged into and leaves a comment, it’s their identity that’s pulled from session state and stamped on the comment. The web server is effectively saying “John Smith made this comment because he just gave us a session ID that corresponds to the session state persisted on the server that he’s logged in against”. And therein lies the problem: anyone who knows that session ID can now comment as John Smith, including the attacker.
In this particular case the fix is simply this: session IDs must be reissued on login. John can browse around anonymously with session ID 1004744 – even though it may have been assigned by the attacker – because while not authenticated, there’s usually not much of value that he’d accumulate in session state. However, as soon as he logs in he needs to be issued a new session ID otherwise you get the issue above. In fact more specifically, as soon as anything of a sensitive nature goes into session state, the ID needs to be cycled otherwise the fixation risk remains.
This is just one very brief look at one attack vector and there is much, much more involved in even just session fixation let alone the broader topic of session hijacking, but I thought it was a good way of illustrating some of what’s in the course.
More about the course
The course is broken down into six modules spanning about three and a half hours:
I begin by talking a lot about risk including referring to the canonical session hijacking attack – Firesheep (do read into this if it’s news to you, it was a fascinating example of the risk):
The next couple of modules talk a lot about what I’ve touched on earlier in this post, namely how web apps persist sessions and then a whole bunch of different ways these mechanisms can be exploited. In fact this is really the crux of the course and there’s a heaps of different attacks walked through and demonstrated first hand, for example:
One thing about all my technical courses is that they’re very practical; everything gets shown first hand so you actually see how attacks like the session fixation attack work in the browser.
The course also talks about session hijacking at the network level both over TCP and UDP. This is quite frankly a bit obscure these days (risks such as predictable TCP sequence numbers are very rare in the modern era), but because it’s something the CEH syllabus talks about, I wanted to include it here.
Finally, there’s also a bunch of info about actually protecting against the risk (because yeah, that’s kinda important!) and as with most things security, it’s about defence in depth and applying layer upon layer of security controls. I also then talk about automating testing for session hijacking risks. Some of this you may already be familiar with, some be quite new such as the ability to test for token strength using Burp Suite’s sequencer tool:
There’s a heap of content in here and it forms and important part of the ethical hacking syllabus we continue to build out at Pluralsight. I hope you enjoy this course, it’s now live under Ethical Hacking: Session Hijacking
BTW – in case Pluralsight is new to you and you want to check it out before committing a whole 95c a day (that gets you all 4,000+ courses by the way), you can always go and grab a free trial.