Love in All the Wrong Places

Match.com has a cookie problem, and it doesn't want to admit it.

I stumbled across the vulnerability when I was preparing a workshop on wireless security: I went looking for sites with session cookies that could be sniffed easily and, much to my surprise, I found them on this popular dating site.

A little background first: what are cookies and how do they work?

A cookie is a little bit of data that a website uses to store information in your browser. It might remember what name you like to be called when you visit the site, it might track how many times you've submitted a form so that you don't abuse it, or it might carry around some of your browsing history in order to target you with better ads. It might also be used to store your session token, and that's where things start to get interesting.

OK, what's a session?

A lot of websites make you log in to use certain features, like posting a classified ad on Craigslist or collecting recipes for your favorite meals on Allrecipes. When you authenticate with a username and password, you are proving your identity to the website, and if you continue browsing you expect the site to remember who you are. The site could make you log in every time you request a new page, but that would be a terrible user experience and nobody would use the site.

Instead, the site creates a session after you log in the first time, and assigns you a token that you use to identify yourself each time you request a new page. The token is often stored in your browser as a cookie and passed up automatically so the site can remember who you are without the hassle of logging in more than once. Great - very convenient! As with most things, however, there are secure ways to implement session cookies and there are not-so-secure ways.

What makes a session secure?

In order to remain secure, a session should:

1. Use a token that does not include authentication credentials.
2. Use a token that does not follow a predictable pattern.
3. Protect the token from being intercepted.
4. Use external checks to detect unexpected use of the token.
5. Close the session when the user is finished.

Note that this list isn't exhaustive; these are just the basics.

What happens if a website fails to do these things?

Each one of these rules, if broken, leads to a separate vulnerability:

1. If a user's password is contained in the token, an attacker could steal the token, get the user's password, and impersonate the user. If it is absolutely necessary for these credentials to be stored in the token, then it must be encrypted. It is rare to find a clear-text password in a token, but sometimes a site will hide the information in a token by obscuring it rather than properly encrypting it.
2. Since the token is used to identify the user to the site, having a predictable pattern can be dangerous. A simple example would be putting the user's login name in the token: if the server relies solely on the token for identification, then an attacker only has to modify a token to include the name of the user they want to impersonate (such as "admin"). A more realistic example would be including numbers that correspond to the user account. If those numbers can be found anywhere else on the site (such as in the URL when viewing a user's profile), then changing the numbers in the token can again be used to impersonate a specific user. The solution here is to make sure each session has a unique ID that is generated randomly and does not correspond to the user's account in a predictable manner.
3. There are many situations where it is easy for attackers to "listen in" while you surf the internet (particularly on public wi-fi). Cookies get transmitted along with your browsing behavior, so they can be stolen easily if they are not protected. A stolen session token can be used by an attacker to impersonate you, so protecting this type of cookie is vital. One way a site can do this is with TLS, a form of encryption that protects the data in transit between your browser and the website (and puts that little padlock icon in your navigation bar). Once you log in to a site and a session begins, the site should force you to browse all subsequent pages using TLS so that the session token is never transmitted in the clear. It should also flag the cookie as "secure" so that your browser knows not to transmit it if TLS fails for some reason (unintentionally or as the result of an attack).
4. Websites need to be proactive about defending against impersonation. When you log in, the site can make a note of your IP address, what type of browser you're using, the last site you visited, and some other details that help to "fingerprint" you. These details shouldn't change as you continue browsing the site, so each time you request a new page using your session token, the site should double-check to be sure they stay the same. If something changes, that should raise a red flag and a smart website will make you log in again before you can continue. By failing to check these external factors, a site can make it much easier for an attacker to impersonate you with a stolen token.
5. Finally, knowing when to close a session is important. Clicking "sign out" gives a clear signal to a site that it's time to close the session and destroy the token that identifies you. Sometimes you forget, however, and so it's up to the site to figure out whether or not the session should be maintained. The danger here is leaving the session open for hijacking after you've left – like an attacker jumping on a public computer and browsing your Facebook profile after you walked away from it without logging off. Sessions need to close automatically after a certain period of time or when changes in other factors are detected as discussed above. Furthermore, the site needs to close the session completely, rather than simply deleting the token used to access it. If a user logs out and their token is deleted, but the site keeps the session open, then an attacker who managed to steal the token can still use it to impersonate the user.

So what did Match.com screw up?

Numbers 3, 4, and 5. First, it fails to adequately protect the cookie where the session token is stored. The "secure" flag is not set, and although the login page is protected with TLS encryption, the site doesn't force TLS to be used after the user has authenticated. That means the session cookie gets transmitted in the clear when the user browses their matches. Here's what it looks like to an attacker who is snooping on the connection:

First, we see the victim browse to Match.com.

Next, the victim clicks "Member Sign In" and is redirected to the login page.

The victim then logs in. Since the login page is encrypted with TLS, we can't actually see anything here.

Finally, the victim has finished authenticating and their home page loads (without TLS).

Critically, their cookies are transmitted in the clear, including the session token.

From here, all the attacker has to do is copy the token into their own browser (which is easy to do with built-in developer tools or a cookie editor plugin) and browse to Match.com. They don't need to know the username or password – because the cookie takes care of authentication, they are already logged in.

This is the site's second mistake: it fails to detect when the session cookie is being used in a suspicious manner. It doesn't matter if the attacker uses a different browser or connects from a different location; the cookie is still accepted and the attacker is authenticated.

Finally, to add insult to injury, Match.com fails to properly destroy the session when a user logs out. Sure, your browser will forget who you are when you click the "Sign Out" button, but if an attacker managed to steal your session token while you were signed in, it's already too late. The site keeps the session open even after you leave, so anyone with a copy of your token can still sign in as you (at least until the next time you log in).

Ouch. What can I do?

Unfortunately, my attempts to contact Match.com about this vulnerability have gone unanswered, so I don't have any idea if they are aware of the problem or intend to fix it. If you are a regular user of the site, here's what I would recommend you do to stay safe:

1. Avoid browsing the site in a public setting. Anywhere there is the potential for strangers to listen in, don't check your matches. This goes for your phone as well as your laptop.
2. Stay logged out so your phone and computer don't check the site without your knowledge.
3. Use a VPN (such as IPVanish – avoid the "free" ones). These services don't cost much but provide encryption for all of your browsing, even when websites fail to.
4. Contact Match.com and tell them you care about this vulnerability. With enough pressure from their customers, they will be obliged to fix the problem.
5. Using your browser's developer tools, check the "SECU" cookie periodically to see if the "secure" flag has been set. If it has, chances are good they fixed the problem.

Concluding thoughts

I went looking around the internet for this particular vulnerability, and I found it in a surprisingly short period of time. Match.com wasn't the only site I found, either – Allrecipes.com also has the same vulnerability (to their credit, they responded positively to my report, though at the time of writing the issue has still not been resolved). Sadly, insecure cookies are a common problem among websites, which is why I wrote this article.

My intent here was to help you, the consumer, better understand the risks presented by websites with poorly implemented session cookies. Hopefully now you will have a better sense of how to spot them and protect yourself against them. At the very least, I hope you will take away the importance of demanding strong security from the sites and services you use online. Security is often lax because it doesn't help the company's bottom line; problems like this are everywhere because they are not considered important enough to solve until the customer demands they be solved. Know your power and wield it!

Disclosure timeline

February 8, 2017 - Identified potential vulnerability on Match.com

February 10, 2017 - Successfully hijacked authenticated session using two computers

April 7, 2017 - Contacted customer support, requested information about responsible disclosure/bug bounty

April 10, 2017 - Received automated response about reporting malicious users, replied to clarify the security-related nature of the issue

May 1, 2017 - No further response, sent a message indicating intent to disclose in 90 days

August 2, 2017 - Published this article

Read More