Security Flaw in Atlassian Products (Jira, Confluence,Trello, BitBucket) Affecting Multiple Companies

Published:
December 13, 2022
8
min read
We discovered that for Atlassian products (Jira, Confluence, and BitBucket), cookies are not invalidated, even if the password is changed, with 2FA (Two-factor Authentication) enabled, as the cookie validity is 30 days. They only expire when the user logs out, or after 30 days.

December 22: Atlassian has acknowledged the issue and has patched the same. On December 15, based on our research, they have simplified the self-service invalidation of tokens following a password change for Cloud users: Read the acknowledgment

Atlassian response to claims regarding session tokens/cookies vulnerability

On 6th Dec 2022, CloudSEK disclosed a cyber attack directed at the company. During the course of an investigation into the root cause of the incident, the internal investigation team identified that the threat actor gained access to a CloudSEK employee’s Jira account, using Jira session cookies present in stealer logs being sold on the darkweb.

Following further investigation, it was found that for Atlassian products (Jira, Confluence, and BitBucket), cookies are not invalidated, even if the password is changed, with 2FA (Two-factor Authentication) enabled, as the cookie validity is 30 days. They only expire when the user logs out, or after 30 days.

We have Informed Atlassian regarding this and they have acknowledged and are working to Resolve the issue.

CloudSEK researchers have identified that this flaw can take over hundreds of companies’ Jira accounts. Our records show over 1,282,859 compromised computers and 16,201 Jira cookies for sale on dark web marketplaces. And just in the last 30 days, over 2,937 compromised computers and 246 Jira credentials were made available. In the past 90 days, we have observed at least one compromised computer from a Fortune 1000 company. This is just considering their primary domains, not their subsidiaries.

CloudSEK is releasing a free tool that lets companies check if their compromised computers and Jira accounts are being advertised on dark web marketplaces.

With over 10 million users across 180,000 companies, including 83% of Fortune 500 companies Atlassian products are widely used across the globe. And threat actors are actively exploiting this flaw to compromise enterprise Jira accounts.

Stolen Atlassian Cookies Can Lead to Unauthorized Account Access even if 2FA enabled.

CloudSEK’s investigation shows that cookies of Atlassian products remain valid for a period of 30 days, even if the password is changed and 2FA is enabled. Hence, threat actors can restore Jira, Confluence, Trello, or BitBucket sessions, using stolen cookies, even if they don’t have access to MFA OTP/ PIN. The cookies, by default, expire when the user logs out, or after 30 days.

This is a known issue, and most companies do not consider it to be within the scope of security reporting, because to use this and get into systems, tokens are required. There are other vulnerabilities like XSS which can be used to get tokens and they are in scope for security reporting. However the use of social engineering is out of scope for Bug Bounty engagements and in this case, exploiting the malware and dumping information like cookies requires social engineering.

However, it is no longer very difficult for threat actors to get their hands on these tokens. With the rise in device compromise campaigns, breaches, and password leaks, cookie theft has become commonplace. And cookies are available for sale and one can simply search for a company, buy their logs, find relevant tokens to gain access to their internal systems.

In the case of Atlassian products, only one JSON web token (JWT) is required to hijack a session i.e. cloud.session.token. Atlassian JWT (JSON Web Token) tokens have the email address embedded in the cookie. Hence, it is easy to determine which user the cookie belongs to.

It seems that this bug is fixed now by Atlassian very silently after we reported it and without acknowledging it.

The response for the change password request which I was getting on 13th December is different from what I’m getting now. Please refer to the attached screenshots of my burp suite history. Check the “Date” header in the response.

Response of change password endpoint on 13th Dec

Response of change password endpoint on 13th Dec

Response of change password endpoint on 15th Dec

Atlassian added a redirectURL parameter in the response to change the password request now. This will invalidate the current session and will assign a new session token to the user. As of 13th Dec, there was no such parameter and upon changing the password users will just get a 200 OK response from the server. Please refer to the above screenshots.

You can Check if your organization’s Data is available for SALE on Dark web Marketplaces: Check Here

Proof of Concept

CloudSEK researchers obtained some log file dumps and found multiple Atlassian cookies which are still active for various enterprises. To know more about how stealer logs are collected and sold, please refer to the next section.

Step 1: Using a cookie obtained from a stealer log, send a GET request to the /manage/rest/user endpoint on id.atlassian.com, This request will validate the token. If the user has logged out, you will get a “session expired” response from the server.

Step 2: In order to get the accessible products, send a POST request to the /gateway/api/accessible-products endpoint on id.atlassian.com.

The workspace URLs associated with the victim are available
The workspace URLs associated with the victim are available

 

Step 3: From the above request, you will get the workspace URLs. You can further compromise the workspaces using the same session token. Please see the screenshots below:

The victim’s JIRA Projects are accessible
The victim’s JIRA Projects are accessible
Screenshot of The Bitbucket workspace ( notice hostname in request)
Screenshot of The Bitbucket workspace ( notice hostname in request)

 

The victim’s Bitbucket user settings page
The victim’s Bitbucket user settings page

 

Atlassian Credentials/ Cookies for Sale on Darkweb Marketplaces

In the last 30 days, more than 200 unique instances of atlassian.net related credentials/ cookies have been put up for sale on dark web marketplaces. Given that the credentials were put up for sale in the last 30 days, it is highly likely that many of them are still active.

Instances of atlassian.net credentials for sale
Instances of atlassian.net credentials for sale

 

Among them, a large Identity and Access Management company employee’s Atlassian cookies were available for sale (which are now expired):

Credentials of a large organization’s Atlassian product instance
Credentials of a large organization’s Atlassian product instance

 

The anatomy of a Stealer-Log File

Stealer logs sold on dark web marketplaces, typically have the following folder structure:

The folder structure of data in a stealer log
The folder structure of data in a stealer log

 

On parsing the files present, the data is displayed in the following format:

Folder structure displayed after parsing
Folder structure displayed after parsing

 

As visible in the screenshots, some of the victim’s information included in the stealer log are:

Other Companies’ Data Available on the Dark Web

In the past 90 days, over 70% of Fortune 1000 companies’ data was available for sale on dark web marketplaces. This is just considering their primary domains, not their subsidiaries.

Out of these, for 50% companies, credentials of various internal endpoints were put up for sale. These included endpoints to their Jira, Gitlab, ADFS (Active Directory Federation Services), intranet, VPN (Virtual Private Network) instances, etc.

Some Endpoints for which were available for sale
Few endpoints available for sale

 

Some internal endpoints available for sale
Some internal endpoints available for sale

 

Most Common Stealer Malware

Currently, the most common stealer malware collecting and selling data in the form of stealer logs on dark web marketplaces are:

Most common stealer malware
Most common stealer malware

 

Most Common Operating Systems Affected

Analysis of data advertised on dark web marketplaces shows that victims using Windows OS were most commonly affected by stealer malware.

Most common OS
Most common OS

 

Most Affected Countries

The top 3 countries, whose data is present in stealer logs are the US, India, and Brazil.

Most affected countries
Most affected countries

 

Mitigation Measures

  • Encourage employees to log out of sensitive applications on regular basis
  • Set a shorter idle session for Atlassian products via the admin.atlassian.com under Security → Authentication policies section until a fix is released by atlassian.
  • Implement idle-session timeout to enforce re-logins
  • Monitor cyber crime forums for latest tactics used by threat actors.
  • Check if your organization’s data is available for sale on dark web marketplaces
You can Check if your organization’s Data is available for SALE on Dark web Marketplaces: Check Here


Share this post
Contributors to this Article
Deepanjli Paulraj
Deepanjli Paulraj
Deepanjli is CloudSEK's Lead Technical Content Writer and Editor. She is a pen wielding pedant with an insatiable appetite for books, Sudoku, and epistemology. She works on any and all content at CloudSEK, which includes blogs, reports, product documentation, and everything in between.
Mayank Satnalika
Mayank Satnalika
Mayank is a Senior Machine Learning Engineer at CloudSEK. In this role, he ensures that all of CloudSEK's ML services are up and running.

Join our Newsletter

Sign up so that you don't miss any updates from us

We care about your data in our privacy policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Search

Didn't Find what you are looking for search here