nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The big question regarding Cloudsek report about stolen cookies, Atlassian please clarify

Grzegorz Szyło

@sparsh.kulshrestha @Dan Hranj I think we are missing the big picture here.
If what Cloudsek is claiming is true, then it means that cookies were stolen via malware infections on endpoint computers.
What we do not have is a list of those that we can check and verify.
If Cloudsek has this list from darknet then it should notify Atlassian and let Atlassian contact affected customers to investigate their enpoints for breaches.
This would be the responsible thing to do.
Otherwise changing login settings and session timeouts is just a bandaid for a malware infection and continuous data breach.
We need to establish if the claims are true and notify parties of breaches if confirmed.
@atlassian should verify with Cloudsek the claims and respond accordingly.

In the article there is a link to a tool that can check if your domain is affected but it does not report on details.

We need these details to be available to investigate in our companies potential malware infections.

Cloudsek website unfortunately does not even have a contact page to send them an email.

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

Comments

sparsh.kulshrestha

Hi @Grzegorz Szyło

We got some sample cookies from the dark web marketplaces for Atlassian and a lot of them are still valid. The list of valid cookies has been shared with Atlassian already.

But we just bought a sample of cookies available on the dark web marketplaces. Every day new passwords and cookies are posted for sale. We do not have this data because we haven't bought it yet.

The bigger and more responsible thing that Atlassian should do here is to implement device-based validation on the cookies so that even if the cookies are breached, a session can not be hijacked. For instance, google performs device and OS validation every 10-15mins and that makes it secure from session hijacking attacks.

Grzegorz Szyło

Hi, @sparsh.kulshrestha
This is not a contact page, it's a book a demo meeting form.
Why does your company does not publish an email , phone number or even your registered adress?
If @Atlassianhas got the list of cookies, then Atlassian should notify the affected companies and users of potential breach on their devices. This is a logical courtesy.
Regarding improving cookie security I agree but the more widespread and possibly impacting issue here is the potential breach via malware on the devices that cookies were supposedly leaked.
As a responsible cybersecurity company Cloudsek should also notify these companies/users of the exposure. The data available through your tool is not enough to verify these claims or to investigate further.

sparsh.kulshrestha

@Grzegorz Szyło

Agreed, CloudSEK has informed as many impacted companies as we can already. We have also released a tool during the process which can be used by other organizations to check the presence of their domains on the dark web marketplaces. This free tool is hosted here: <advert removed>

But see, malware infections are something that can not be controlled by us or Atlassian. We can only control the damage after the malware infection by making our applications robust for session-hijacking/password-reuse attacks.

There are other solutions implemented at the machine level to detect any malicious malware but they are also prone to bypasses. In the last 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% of 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.

Nic Brough -Adaptavist-

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

sparsh.kulshrestha

The Atlassian admin deleted my comments from the above thread. I have added them again. Please check. It seems like they silently patched the vulnerability and now they are claiming that there was no vulnerability. That's why they deleted my comments with screenshots of POC.

Andy Heinzer

It is not our practice to remove posts unless in violation of our Community Guidelines, and I have confirmed that your comment was not removed by an Atlassian employee. That said, I found that your comment was removed by a non-employee moderator without our consent.

As a reminder, if community members believe any content to be abusive or in violation of other Community Guidelines, please click “Report to moderators” on the post, and the moderators will be alerted.

I invite you to post your comment again to that thread. Sorry for the inconvenience here.

sparsh.kulshrestha

Hi @Andy Heinzer ,

Thank you for the response. I have posted my comments again. And I'm also posting them here. Please let me know if any additional information is required.

We highlighted in our report that Atlassian does not invalidate session cookies on password changes. It invalidates the cookies on password reset.

In case of compromise, the first thing victims do is that they change their password. They do not reset their password in most cases. And we have identified by changing the password, session tokens are not being invalidated. They stay active for 30 days.

We found that Atlassian did not invalidate the session cookies on the password change. However, this bug is fixed now by Atlassian after we reported it.

Another interesting observation. 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.

Screenshot 2022-12-17 at 1.03.16 AM.png

Seems like Atlassian quietly patched the vulnerability.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

security