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

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 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.

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:

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.

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

The anatomy of a Stealer-Log File

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

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

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.

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 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 Affected Countries

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

Mitigation Measures

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

‍