Atlassian response to claims regarding session tokens/cookies vulnerability

[#1]

On December 7, 2022 (UTC), Atlassian's security team opened an investigation into unauthorized access of a customer's Cloud account. On December 8, we concluded that the bad actor used session tokens, stolen by a piece of malicious software on the customer's computer, to facilitate this access. We promptly invalidated the customer’s affected session tokens. This incident was in no way caused by a vulnerability in Atlassian products or a compromise of Atlassian systems.

Are my session tokens at risk?

Our security team did not find a vulnerability in Atlassian Cloud or On-Premise products or a breach of Atlassian systems related to the incident.

We understand that this incident has spurred many of you to look into the availability of your data on similar dark web marketplaces. We want to emphasize that this was an isolated customer incident caused by malware on the customer’s computer.

Cybercriminals deploy malware as a means to obtain session token data, regardless of cloud or on-premise deployment. If you have any concerns about the security of your account, we recommend that Cloud customers reset their passwords, which will automatically log users out of all active and current sessions. Cloud customers can reset their passwords here: https://id.atlassian.com/manage-profile/security. Server and Data Center customers can contact their administrators to reset their passwords.

If you have further questions, please reach out to our team by filing a support ticket: https://support.atlassian.com/contact/#/.

Regards,
Atlassian

---

[Update] December 22: We would like to thank CloudSek for alerting us to this issue. On December 15, based on their research, we simplified the self-service invalidation of tokens following a password change for Cloud users: a separate user logout is no longer required to invalidate the current session token. For further questions, please reach out to your support representative or file a ticket here: https://support.atlassian.com/contact/#/.

[Mike Rathwell]

Thanks for getting this out there @Dan Hranj . I have been pestered a lot about this since this came out. I wrote a rather long explanation to be shared citing corroborating evidence that the OP was blaming their hack on someone/something else whilst apparently trying to get business to confirm that water is wet and the sky is blue.

[Sachin Dhamale]

@Dan Hranj How Frequently we need to reset the password? 

Does reducing idle session timeout helps to mitigate this issue? 

Is there any other way to invalidate session cookies or token?

[Tom Bakry]

I am not sure that I am getting the correct read from your post, @Dan Hranj. It seemed that what was reported was that bad actors could be successful in replaying captured session tokens to gain access to Atlassian products. Are you saying that there is more to this issue required to allow a bad actor to leverage the stolen session cookies? From my reading, it seems that the session token is valid for up to 30 days, by default, unless the user logs out. 

Thanks,

Tom

[Dan Hranj]

Hi @Tom Bakry

By default, these sessions expire when a user is idle for more than 30 days or when they manually log out of their account.

• Cloud Admins can configure the idle session duration by creating or modifying authentication policies for their organization. More information here: https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/.

• Server and Data Center customers can modify idle session duration for Jira, Confluence, and Bitbucket.

Various malware families have the ability to steal cookies from your browser. If your cookies are stolen, they can be used by cybercriminals to access your account. Malicious software running on a user's computer is the root cause of the issue addressed in this post. To protect yourself from cookie theft, ensure all software, including anti-virus, is up-to-date, and avoid installing unfamiliar software.

[John Price]

Thanks, Dan.  That was our take as well.  To put it another way, this is a vulnerability that has always been out there and applies to many apps that use cookies; it's not specific to Atlassian apps:

• App uses cookies with a non-zero expiration time - that describes a lot of apps!
• Someone installs malware on a user's computer.
• That gives them access to the user's web data in unencrypted form.
• Hacker grabs a session cookie/token from the app.
• Hacker later uses that to reconstruct a session impersonating the user.
• Can be mitigated by shortening default session length from 30 days, but at some very short setting, users will complain.
• Also, for any user who is hacked, disable their account!

Is that about right?

[Sjoquist, Carl]

Cookies can also be harvested in any public wifi environment, so it doesn't require malware to be installed on a user's computer.   Ferret and hamster are evidently popular tools, readily available, for exactly this purpose. 

[Zero Byte]

I feel that Atlassian is falling short on providing adequate session protection to ensure that session data is not portable. We know well that malicious actors will try to still session cookies. The question is what is Atlassian doing about it?   

Atlassian should bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, then it should terminate the suspicious session. This is a very good indicator of session manipulation and hijacking attempts. Nonetheless, from my testing Atlassian is not doing any of this, reason why malicious actors see an opportunity harvesting the session cookie.

[HarryH]

Hi @Dan Hranj , like above @Zero Byte mentioned, is there any mitigation from Atlassian regarding session tokens/cookies protection?