Cyber Attacks (Session Hijacking)

The Attack

Yesterday we explored cross-site scripting (XSS) and today this exact attack will lead us to our next attack, which is “session hijacking”, but before we dive into let’s talk about cookies. 

Anytime you login to a website you’ve most likely given a cookie from the server. This tasty little cookie is like the key to your personal kingdom. 

When you log into a website you’re authenticating yourself, so the server knows its truly you, once they’ve confirmed this, they’ll send over the cookie (see below). Once you have the cookie you’re able to access most of the services on this site without logging in again, but imagine if this cookie was stolen. 

There are ways to actually steal this “cookie” and pretend to be you, allowing the attacker access to your account, let it be on social media, banking, or anything else. Some common ways attackers are able to steal this special cookie are… 

• Cross-site scripting (XSS) - This is a topic we’ve chatted about in previous posts, but in a nutshell, our attacker will insert Javascript into a website that a user visits. Once the user enters their credentials, this is sent off to our attacker and the intended location (e.g. some server), with this info the attacker can now log on as our user via their cookie. 
• Sniffing unencrypted traffic - Anytime you visit a site that has “HTTP” in the URL, without the additional “S” (e.g. https), run! This traffic is most likely being sent across the interwebs in plaintext, so attackers are able to see everything. When logging in via HTTP your cookie will be in plain sight, so our attacker can snag it while it’s traveling across the interwebs. 
• Bruteforce - Some cookies are short and predictable, so attackers have a good chance of guessing what your cookie is if they have enough computation. This rarely happens today, but it’s still a good thing to be aware of.

These cookies are long random numbers, but they’re named specifically for each service, below are some of the more popular services and their naming conventions. 

The Defense 

Luckily, like many attacks throughout this series, there are many ways to defend against this session “cookie” hijacking attack.

• Multifactor - By enforcing multifactor before critical activities such as transferring money, purchasing something, or anything else that’s labeled critical, there should be another login with multifactor waiting for our user. Yeah… it’s not very convenient, but neither is having all of our info or money stolen. 
• Cookie persistence - Ensure that your website is configured to delete persistent cookies, as well as creating cookies that are timed. By not allowing cookies to stick around forever or long periods of time, we’re lowering the chances of these cookies being reused by bad people. 
• Complex cookies - This helps combat “brute-force” attacks. By lengthening our cookies and sprinkling randomness into them, we’re setting ourselves up for success. 
• Checking for abnormal behavior - If a valid user is logged onto a banking website looking at their balance and all of the sudden there’s a request for a bank transfer, there’s obviously some fishy business going on. By checking for anomalies like this, there’s a good chance you’ll be able to catch bad people before they can do anything too damaging with their stolen cookies. 
• Encrypted traffic (HTTPS via TLS) - As I mentioned earlier if the website you’re logging into doesn’t use HTTPS, then run away as fast as possible! This traffic is being sent in the clear, so it’s suitable to sniffing attacks. 
• … There are many others, but we’ll stick with this for now... 

Observing it in the wild

This cookie monster hijacking has happened many times in the past and here’s one of the more popular attacks.

• Firesheep - In 2010, a Firefox extension called “Firesheep” was released that made it easy for session hijackers to attack users of unencrypted public Wi-Fi. Websites like Facebook and Twitter allowed the Firesheep user to easily access private information from cookies. Only months later, Facebook and Twitter responded by offering HTTPS.