Skip to main content

If you give a hacker a cookie, he'll ask for a session ID.

Most clients I talk to have a basic understanding that a wireless network should be "secure". They do what they can to make their home and office wireless networks have some semblence of security. However, no one seems to have an issue checking their Facebook account from the local bookstore or pulling up some sensitive company emails at the airport. People make the assumption that since they have no sensitive information on their hard drive and they are running a really good anti-whatever, safety is assured.

I can promise you, it is not. And seeing what you are searching for is not the worse thing that a hacker can do. Let me explain:

You walk into your local bookstore and pop out your laptop. You find the wireless signal with the best strength, connect, and off you go to check your Yahoo! or Hotmail account. SuperAntiEverything 2009 tells you that you are secure, have no viruses, and no hacker in the world can access your computer. That's no problem for the hacker sitting in his car with a laptop and $5 worth of parts, because he doesn't want to get into your computer. He wants to become your computer.

When you logged into your email account, you typed in your password and sent it to Yahoo. This was probably an encrypted transaction (most sites will use SSL to encrypt your login) so a prying hacker would not be able to see this information. The site verifies the information and provides you with a Session Cookie. This bit of information is what prevents you from having to login constantly as you move from page to page. It contains an ID of sorts that is meaningless by itself (it doesn't contain a username or password), but uniquely identifies you to the website until you logout.

As you navigate from the inbox to your address book, this session-id is passed to the server which replies with the page you requested. The information is not secured like the login page was, and since this is an unsecured network at the book store, all of this information is unencrypted as it travels the air waves.

The hacker sitting in his car picks up this signal on his laptop and uses a packet sniffing utility to view the contents of the information you are sending. Including the cookie information you just passed. Now all he/she has to do is take the session cookie and inject it into their own browser. They can now surf around the site you are on as if they are you, without having to steal your username or password. Even after you have closed your browser and gone home, the hacker can take this session ID (provided you did not logout properly, which no one does unfortunately) and search every corner of your account with it. Post status updates. Send messages. Delete emails. Change your password. Worst of all, your firewall/antivirus/antispyware/browser/etc. won't protect you because the information is not being stolen until after it leaves your mobile device. It is a completely passive attack, nearly undetectable, and the tools to do it are easily found on the internet.

So how do you protect against this attack (known as "Sidejacking", a form a session hijacking)? The three most important things to remember are:

  1. Ensure when you are browsing to a site that associates you to an account, the session is encrypted with TLS/SSL. This means looking for "https" at the beginning of every page, not just the login page.
  2. Get your wireless network encrypted using strong protocols (WPA2) with strong passphrases and strictly control access to it. Avoid open networks for any work that is even remotely sensitive. 
  3. Properly logout of websites when you are done using them. This usually clears the session and renders any stolen cookies invalid. Look for the "logout" option, don't just close the window.
 Got questions about sidejacking or wireless security? Respond below.

Comments

Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.