The Year 2022 definitely wasn’t the best year for Jira and Bitbucket users in history. Atlassian outages, warnings about data breaches, being on the first lines of media are all about Atlassian this year. So, let\u2019s analyze Atlassian Status and different media alerts to see what really happened to this giant cloud service provider. <\/p>\n\n\n\n\n\n\n\n
December 2022 The researchers from CloudSEK noticed a vulnerable flaw in such Atlassian products as Jira, Confluence, and Bitbucket. They stated that threat actors can use this flaw to take over a company\u2019s Jira account. The problem was hidden in cookies which were invalidated, even if the user changed the password, with 2FA enabled. According to those security researchers the reason hid in the cookie validity, which is 30 days, as they only expire at the moment when the user logs out, or after 30 days. <\/p>\n\n\n\n At the same time, Atlassian security team<\/a> had its own investigation into unauthorized access of a customer\u2019s Cloud account, which took place in December and triggered the buzz in the network. As it turned out during the investigation, it was an isolated case caused by malware on the customer\u2019s computer: \u201cThis incident was in no way caused by a vulnerability in Atlassian products or a compromise of Atlassian systems.\u201d <\/p>\n\n\n\n For those Cloud customers who have some concerns about the security of their tokens, the Atlassian team recommended \u201creset their passwords, which will automatically log users out of all active and current sessions.\u201d<\/p>\n\n\n\n Atlassian Status<\/a> | Dark Reading<\/a> <\/p>\n\n\n\n November 2022 After noticing critical security vulnerabilities that the Atlassian characterized as 9 out of 10 in severity rating, the cloud service provider released some updates to address those problems in its centralized identity management platform – Crowd Server and Data Center, as well as git-based code and CI\/CD tool – Bitbucket Server and Data Center. <\/p>\n\n\n\n According to Atlassian, is the command injection flaw, tracked as CVE-2022-43781, which affects Bitbucket Server and Data Center, and could permit the attacker with permission to control their username to gain code execution on the target system. Another flaw, CVE-2022-43782, which affected Crowd Server and Data Center, was a misconfiguration that cloud give an attacker a possibility to bypass password checks during the authentication as the Crown app and to call privileged API endpoints. <\/p>\n\n\n\n Atlassian security advisory presented a step-by-step guidance for administrators to check if their products were compromised and what actions to take in that case. <\/p>\n\n\n\n Bleeping Computer<\/a><\/p>\n\n\n\n October In October Bishop Fox, a cybersecurity services firm issued an advisory about two vulnerabilities they noticed in Atlassian Jira Align which allowed a user, who had an access to the service to easily gain access as an application administrator and, consequently, make an attack on the Atlassian service. <\/p>\n\n\n\n Those two vulnerabilities were Server-Side Forgery (SSRF), tracked as CVE-2022-36802, and Insufficient Authorization Controls, tracked as CVE-2022-36802. The first one allowed the threat actor to get the AWS credentials to the Atlassian Jira service account and then access the Atlassian Cloud<\/a> infrastructure as a user of Jira Align, The second one permitted those users who had People role permission to upgrade their and any user\u2019s role up to Super Admin. With this role, a user gained control over any settings in the Jira Align tenant, allowing him to modify Jira connections or security settings, reset user accounts.\u00a0<\/p>\n\n\n\n Jira<\/a> | Dark Reading<\/a><\/p>\n\n\n\n September In September Atlassian experienced two partial outages. The first one took place on September 8th and lasted for about an hour. As the Atlassian team posted later on Atlassian Status <\/a>\u201cwe experienced requests timing for some of our customers for Atlassian Bitbucket. The issue has been resolved and the service is operating normally.\u201d<\/p>\n\n\n\n The other outage happened later on September 25th and lasted much longer than the previous one – 7 hours and 33 minutes. According to Attlassian<\/a> some customers \u201cusing Bitbucket Cloud<\/a> were unable to access their repositories.\u201d As it turned out this incident was triggered due to the storage vendor\u2019s outage (that Atlassian uses at their data center) caused by a firmware upgrade. However, the Atlassian team detected the incident within 14 minutes, it took hours to resolve the problem.\u00a0\u00a0<\/p>\n\n\n\n Atlassian Status<\/a><\/p>\n\n\n\n August There was another security advisory warning issued by the Atlassian, yet for Bitbucket Server and Data Center users. They tracked a vulnerability, aka CVE-2022-360804 – a security flaw, which received a CVSS severity score of 9.9 out of 10 and needed to be patched immediately. Using this critical vulnerability a threat actor could leverage to execute arbitrary code on vulnerable instances (according to Atlassian this vulnerable security flaw affected all Bitbucket and Data Center versions over 6.10.17, as well as from 7.0.0 to 8.3.0).<\/p>\n\n\n\n Here is the Atlassian advisory commented on the issue: \u201cAn attacker with access to a public repository or with read permissions to a private Bitbucket repository can execute arbitrary code by sending a malicious HTTP request.\u201d Thus, to solve the problem the Atlassian had nothing but applying the available security update or some other mitigations immediately. Remote code execution (RCE) is the most potent of all vulnerability types, enabling crooks to do extensive damage while bypassing security measures, so this motive should be considered here.<\/p>\n\n\n\n Bleeping Computer<\/a><\/p>\n\n\n\n July June Researchers from Assetnote<\/a> tracked a server-side request forgery (SSRF), tracked as CVE-2022-26135, in Jira and Jira Service Management. This vulnerability permitted the attackers \u201cto make requests to arbitrary URLs, with any HTTP method, header and body.\u201d<\/p>\n\n\n\n Later Atlassian explained in its security advisory<\/a>: \u201cDepending on the environment the Jira instance is deployed in, the impact of this bug varies. For example, when deployed in AWS, it could leak sensitive credentials.\u201d To solve the issue Atlassian suggested the users, who didn\u2019t have their Jira site accessed via the atlassian.net domain, to update their Jira app, as they could be affected by the mentioned vulnerability. <\/p>\n\n\n\n The Daily Swig<\/a><\/p>\n\n\n\n May April About 775 Jira customers couldn\u2019t access their data for almost two weeks, from April 5th to April 18th. To make a long story short – the reason behind it was a maintenance script that accidentally wiped hundreds of customer sites due to communication issues between two Atlassian teams working on deactivating a legacy app. The team used the wrong execution mode and wrong list of IDs. <\/p>\n\n\n\n As a consequence, this human mistake led to catastrophic results for those who didn\u2019t have a backup plan in place. Once analyzed the data, the Atlassian managed to gather during the incident\u2019s investigation, Sri Viswanath, the Atlassian engineer, said \u201cThe result was an immediate deletion of 883 sites (representing 775 customers) between 07:38 UTC and 08:01 UTC on Tuesday, April 5th, 2022.\u201d <\/p>\n\n\n\n Bleeping Computer<\/a> I GitProtect.io blog<\/a><\/p>\n\n\n\n Another incident that\u2019s worth our attention is Atlassian’s announcement about the critical vulnerability which affected Jira.They noticed the security flaw, later identified as CVE-2022-0540, which was aimed at Seraph, the web authentication framework of Jira and Jira Service Management. Exploiting this vulnerability the threat actor could bypass authentication and authorization using specially crafted HTTP requests. <\/p>\n\n\n\n Atlassian issued a statement: \u201cAlthough the vulnerability is in the core of Jira, it affects first and third-party apps that specify roles required at the WebWork1 action namespace level and do not specify it at an action level.\u201d<\/p>\n\n\n\n In a nutshell: this security flaw can bypass the authentication and authorization requirements in WebWork actions where a vulnerable configuration is used, yet the threat actor can only do it if no other authentication or authorization checks are used. <\/p>\n\n\n\n
Atlassian Status for Jira:<\/strong> 2 incidents
Atlassian status for Bitbucket:<\/strong> 3 incidents<\/p>\n\n\n\nSecurity flaw noticed in Atlassian can lead to taking over hundreds of Jira accounts<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 4 incidents
Atlassian status for Bitbucket:<\/strong> 4 incidents<\/p>\n\n\n\nAtlassian remediates its critical vulnerabilities (9 out of 10!)<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 1 incident
Atlassian status for Bitbucket:<\/strong> 1 incident<\/p>\n\n\n\nTwo vulnerabilities noticed in Atlassian Jira could let an attacker steal account credentials<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 8 incidents
Atlassian status for Bitbucket:<\/strong> 4 incidents<\/p>\n\n\n\nBitbucket suffers two outages in a month<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 5 incidents
Atlassian status for Bitbucket:<\/strong> 2 incidents<\/p>\n\n\n\nAtlassian warns its Bitbucket Server and Data Center users about another RCE vulnerability (9.9\/10)<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 9 incidents
Atlassian Status for Bitbucket:<\/strong> 5 incidents<\/p>\n\n\n\n
Atlassian Status for Jira:<\/strong> 3 incidents
Atlassian status for Bitbucket:<\/strong> 9 incidents<\/p>\n\n\n\nSSRF flaw tracked in Jira could lead to leaked sensitive credentials<\/h2>\n\n\n\n
Atlassian Status for Jira:<\/strong> 5 incidents
Atlassian status for Bitbucket:<\/strong> 5 incidents<\/p>\n\n\n\n
Atlassian Status for Jira:<\/strong> 2 incidents
Atlassian status for Bitbucket:<\/strong> 2 incidents<\/p>\n\n\n\nAn all-time Jira outage affects 775 customers and lasts for almost two weeks<\/h2>\n\n\n\n
A detected vulnerability found in Jira could permit an attacker bypass authentication to customer\u2019s account<\/h2>\n\n\n\n