Well, it’s the last full work week of the year. If you’re like me, you might be dreading the inevitable addition to the Common Vulnerabilities and Exposures (CVE) database that will ruin everyone’s holiday break. Last night, a friend sent me this blog post from CloudSEK about attackers stealing and abusing the session cookie used across Atlassian products (Jira, Confluence, Trello, Bitbucket, etc.). My initial reaction was, “Okay, is this the ‘one that will totally ruin everyone’s holiday’”? My current answer is “Not really.” However, cookie theft (both this instance and in general practice) is something we should all pay attention to.
We’ve all spent time thinking about how to implement credential management best practices. Password theft has been around forever, and MFA phishing and fatigue attacks have become a huge deal over the past year. Even if we can defend against both credential theft and MFA compromises, the crazy thing is that the attacker can sometimes bypass all these defenses by stealing a session cookie.
This got me thinking about session cookie theft. The interesting thing is that MFA doesn’t do much to stop session cookie theft. But here’s the neat thing — the way we do MFA with BastionZero does limit the scope of this attack by shortening the time window the session cookie can be exploited.
Have you ever thought about session cookie theft? Well, that time has come.
In this post, I’ll cover session cookie theft, how it’s done, and why it matters. Then, I’ll explain how BastionZero’s unique security architecture neutralizes this attack.
What’s A Session Cookie?
When you log into a site, you enter your username and password and do your MFA. After that, you’re free to browse the site without logging in again until your session expires. You are free to browse the site because, after login, the site presents you with a session cookie. After that, every time you make a request to the site, you must provide the session cookie. The session cookie is what proves to the site that you are really you.
MFA Usually Does Not Stop Session Cookie Theft
Here’s the key point. You get your session cookie after you do your MFA. If your session cookie is long-lived, and the adversary steals it, then they can impersonate you without compromising your MFA.
Cookie Theft is a Real Thing — It’s Happening
While many firms may fall short of implementing credential management best practices, some firms are more impacted than others. Some session cookies, such as the ones that banks use, are very short-lived. Even if these are stolen, the window of exploitation is so short that reselling them on the dark web isn’t likely to have much impact.
However, other sites, such as Gmail and Slack, have very long-lived session cookies. (When’s the last time you had to log in to your Gmail account?) Attackers are stealing and reselling these cookies. VICE did a great expose on cookie theft last year; there are entire marketplaces for selling these cookies, which are often harvested by botnets and resold to other threat actors. Another way these cookies can be stolen is via cross-site scripting (XSS) vulnerabilities. Last year, an attacker used this technique to hack into the gaming giant Electronic Arts (EA).
You would think that session cookies should be tied to a user’s device, so they could not be stolen from a legitimate device and reused on an attacker’s device. However, this isn’t the case with most of the session cookies we use daily. Thus, stolen session cookies are being bought and sold.
UPDATE: After this blog was initially posted, a colleague told me about trying to tie session cookies to the browser footprint. They calculated a hash of browser, plugins, OS, screen resolution, etc., and then put that hash in the session cookie. But this didn’t help. The botnet stole that logic and then replicated the browser footprint on the adversary machine where they sent the stolen cookie.
Atlassian is Using Long-Lived Session Cookies, and These Have Been Stolen
Here’s what the folks at CloudSEK found. Atlassian uses session cookies that last 30 days, making them vulnerable to cookie theft. Thus, the adversary (e.g., botnet operator) has 30 days to sell them to someone else and make a profit.
Even worse, these session cookies were not expiring after users changed their passwords. That means that if my session cookie is stolen, and I try to lock the adversary out of my account by changing my password, nothing happens. The cookie only expires if I log out, or if the cookie’s natural validity period (30 days) expires. CloudSEK folks even have a tool that allows you to search to see if session cookies from your organizations are being bought and sold. I tried the tool this morning and found that there are some okta.com cookies out there.
How BastionZero Helps
Now let’s look at how sessions are created with BastionZero and how our MFA limits the risk of session cookie hijacks.
BastionZero has two roots of trust: One is your single sign-on (SSO) provider (Okta, AzureAD, or GSuite) and the other is BastionZero’s cloud service. To log into a target with BastionZero, you first must authenticate with your SSO provider (username, password, and whatever MFA and device context checks that your organization has with your SSO provider). Then, you must MFA to BastionZero.
Now you probably know that one of the great things about SSO is that you don’t always need to enter your username, password, and MFA each time you log in. Sometimes you can just click on that handy button that shows your account name, and you are logged in. The reason you can do that is because your SSO provider has given you a session cookie. Thus, session cookie theft can swiftely derail credential management best practices if those cookies are long-lived.
So, how does this work with BastionZero? First, you authenticate with your SSO provider. Then, you must complete MFA via BastionZero’s independent cloud service. This ensures there is still an independent MFA (to the BastionZero cloud service) to protect you in the event your SSO provider falls victim to a cookie theft attack.
If an attacker steals your session cookie, they will not be able to access targets without first completing MFA with BastionZero. Access cannot be achieved via BastionZero unless the attacker also compromises the user’s MFA — or if the user has completed a valid MFA with the system at the time of the attack.
BastionZero’s MFA is also timed to expire after 24 hours by default. After this, users must enter their MFA again in order to access targets with BastionZero. If an attacker steals your SSO session cookie and sells it to someone, the stolen cookie is useful only while you are logged in with an unexpired MFA to BastionZero. Shortening the MFA time window would limit the window of this attack even further.
By limiting the blast radius of attacks that steal cookies via XSS, BastionZero makes it harder for botnets to profit from reselling cookies to other threat actors (In fact, a short validity window for session cookies would effectively force the botnet to resell access to compromised machines rather than just selling stolen cookies).
This is the power of Trustless Access and having multiple independent roots of trust!
Curious to Learn More?
BastionZero protects your organization’s crown jewels from the consequences of credential theft and unauthorized access. Our trustless approach to access keeps your team moving while strengthening your security posture against attacks you haven’t even thought of — like session cookie theft!
P.S. Thanks to Gerald Beuchelt at Sprinklr for inspiring this blog post.
P.S.S. And the colleague who reached out to share their personal experience with fighting session cookie theft; this blog was revised on 12/15/2022 in response to their comments.
