How true is this security flaw - Atlassian products cookies are not invalidated for 30 days

[Pavankumar Shukla]

any comments on below flaw, how true is this and what's the severity - apparently it mentions:

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.

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.

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

[Abraham Regules · Accepted solution]

This is the official response I got from Atlassian support today:

Thank you for contacting Atlassian Support, ... I will be assisting you throughout this ticket.
I understand you are interested in getting more information about the reported vulnerability.

Atlassian's security team is aware of the report that a customer’s session tokens may have been compromised during a breach of their systems, and we have followed security protocol to invalidate affected session tokens. Atlassian is conducting a comprehensive investigation, though our security team has not found evidence of a compromise within our systems or products.

No customer action is required at this time. We will share another update once our investigation concludes.

Please feel free to respond here with any questions or concerns.

Kind regards,
Atlassian Support | Cloud

[Miquel Cano]

Thanks Abraham! I've just raised a ticket to them. I'll post here if I get any new information.

[Miquel Cano]

Received exactly the same answer from Atlassian support... 

[Filipi Lima · Accepted solution]

Hi, all,

I just wanted to circle back and let you know that we've released an official Community post here:

https://community.atlassian.com/t5/Trust-Security-articles/Atlassian-response-to-claims-regarding-session-tokens-cookies/ba-p/2217925

[Eric Tolliver]

The article gives a workaround "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."  I am unable to find this selection on Confluence Cloud as admin.  Any suggestions on how to shorten the idle session time in Confluence Cloud?

[Abraham Regules]

We use Atlassian Access for both Jira Software / Confluence and we are reducing our idle session timeout directly on our SSO auth policies...

Try this article: 
Update idle session duration | Atlassian Support

[Kevin Cherry]

In my instance I did this and then followed the steps in the article:

[Kevin Cherry]

[Kevin Cherry]

I was able to adjust the idle session duration in the above way. I also tried going to Confluence first, but couldn't find the idle session in there either.

[Eric Tolliver]

I am not able to get the security settings screen.  When I pick Administration is asks with organization.  Once I select the organization it drops me back to the Confluence configuration screen.  Could this be due to us using the "Standard" version? 

[Kevin Cherry]

I'm not sure. Our products (under the products tab at the top of the screen) are: Atlassian Access, Confluence (standard), Jira Administration, Jira Service Management (Premium), and Jira Software (Premium).

I would open a ticket with support, grant them access to your system (in the ticket), and let them investigate and help you. That's what I do.

[Pavankumar Shukla]

here is the reference link, can you please advise on priority?

https://cloudsek.com/security-flaw-in-atlassian-products-jira-confluencetrello-bitbucket-affecting-multiple-companies/

[Abraham Regules]

I just received a notification from one of our team members about this same link... I think focusing on the first 3 mitigation measures could be a priority...

• 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

[Kevin Cherry]

Do you know how to perform the 3rd item listed above?

"Implement idle-session timeout to enforce re-logins"

[Abraham Regules]

Try this article: 
Update idle session duration | Atlassian Support

[Miquel Cano]

Hi!

Do you have any idea if this flaw is affecting users from the support portal?

Thanks!

[John Price]

I got the same response from support.  I have asked some follow-up questions and will post any info here.  First question is to confirm whether this is a Cloud-only issue.  If you enter a publicly accessible DC/Server URL on the CloudSek tool, it gives a positive result, but that could be just how their tool works.  That is, "info about jira.**.com exists in X number of data records on the dark web, but there aren't any that are affected by the cookie hack."