Disclaimer: With the sensitive information possibly being leaked by a number of entities and it being hard to discern those intended to be open as opposed to those intended to be private. Anomali has contacted Atlassian to work with and inform affected customers.
Project management resources and information collaboration workspaces can increase productivity through organisation and employee communication, however, the need for internet access for employees may inadvertently leave access open to malicious actors. Large companies often have employees around the globe who need to share information with colleagues and customers, thus accessibility is crucial to be able to effectively coordinate. Some of the widely-used project management applications include Atlassian’s “Confluence” and “Jira” collaboration programs. Anomali researchers have identified instances of these programs in which companies may be inadvertently exposing data to anyone who travels to certain URLs. Various forms of information owned by companies in multiple industries were observed on these company pages. The publicly available information could be utilized by threat actors to conduct malicious actions such as account takeover, credential theft, data theft, blackmail/scare tactics, Business Email Compromise (BEC), phishing, and watering hole attacks.
The data types include:
Confluence is a document collaboration software used by approximately 35,000 customers, according to the company’s website. The platform is commonly used for documentation, release notes, meeting notes, blog posts, strategic plans, and other general corporate “wiki” features. Confluence divides sections into “Spaces” and visibility settings can be set per space.
Jira is a product management and issue tracking software that is used by approximately 65,000 customers. It is commonly used for agile sprint tracking, bug tracking, issue tracking, reporting, and workflows, as well as more novel uses such as property management and food ordering. Jira users can create “Projects” with “Issues” tickets created inside Projects to track the progress of tasks.
In November 2018, Anomali researchers noticed the company's own Jira dashboard (homepage) was publicly viewable even when not logged in, however, no issues could be viewed. A brief look at the “customers” page on the Atlassian website showed a listing of recent customers. Looking at the customers’ Jira dashboards also showed that, again, the dashboards are visible, but no issues are accessible. Researchers decided to delve deeper with the news of the National Aeronautics and Space Administration (NASA) Jira server leaking information in January 2019. The objective of the collection efforts were conducted to discern what level of misconfiguration may be leaking data belonging to other organizations, and what information was purposely left publicly accessible.
Confluence and Jira are commonly used for open-source projects and public documentation such as API documentation, bug tracking for open-source projects, and release notes. While much information on these products is purposely left publicly accessible, there is some data that appears to have been inadvertently left open to anyone who navigates to the correct URL. Between Confluence and Jira, it appears that Confluence sites are more frequently open to public view. In a sample of 5,000 Jira Software Cloud sites, there were 273 Jira sites with publicly viewable issues and 1,214 Confluence sites with publicly viewable spaces. The larger number of viewable Confluence sites compared to Jira is likely explained by companies having documentation/release notes on a publicly viewable space.
There are two types of hosting for Jira, either on “Jira Software Cloud” or hosted by the company on their own infrastructure. Jira Software Cloud site domains take the form of `[customer].atlassian.net` or `[customer].jira.com` and self-hosted will commonly, but not always, be on a subdomain in the form of `jira.[customer].tld`.
The following methods were used for collecting Atlassian domains, both cloud and self-hosted:
The total amount of domains tested were 53,249 which are broken down as follows:
Figure 1 - Breakdown of tested domains
The path `/secure/Dashboard.jspa` was used, to test for viewable Jira dashboards. Very little information was able to be ascertained for sites that the dashboard was viewable but contained no issues, except for if the dashboard had been personalised with company teams or contact information for administrators and employees. An example of a site with a viewable dashboard is shown in Figure 1.
Figure 2 - Jira Server with viewable dashboard
The path `/secure/MyJiraHome.jspa` was used to filter Jira servers with viewable tickets. If a “200” HTTP status response code was returned from the server, as in an observed instance, then issues from at least one “Project” were publicly viewable, however, not all Projects contain issues. A “302” status code is returned and the requester is redirected to a login page in the case of needing permission to view tickets. Both of these responses (viewable and not-viewable) are shown in Figures 2 and 3 respectively. Researchers used the path `/wiki/` to filter sites with open Confluence spaces to search for a 200 HTTP status code response.
Figure 3 - Jira server with viewable tickets [200 HTTP Status Response]
Figure 4 - Result of redirection because of no publicly viewable projects [302 Status Code Redirection]
The subjective analysis of the viewable content was used to filter out those intentionally left open for legitimate reasons from those unwittingly exposed. If the context was ambiguous as to whether the information was intended to be publicly viewable, the benefit of the doubt was given and it was determined that the information was purposefully left accessible; these pages were removed from the set of sites believed to be misconfigured and leaking information.
Researchers then analyzed the remaining sites to make observations as to what types of data was publicly accessible and what risk would be posed to Confluence and Jira customers leaking this type of information.
The exposed information hosted on publicly accessible Confluence and Jira URLs and servers can be utilized for numerous malicious purposes. These purposes range from reconnaissance for future attacks or even corporate espionage. Some of the malicious activities that can be conducted from viewing the exposed data include the following:
It is important in acquisition negotiations to keep plans and tactics as private as possible because exposing internal information can lead to potential buyers getting insight into a seller negotiating team’s strategy or company flaw that would reduce the amount the company could be sold for. An example is leaving meeting notes open to be publicly viewable as shown in Figure 4. Insight into an industry competitor could potentially allow one company to view information inside a companies Atlassian products to gain an advantage. The data can give an insight into strategic, technological, research, and design advantages that will be open to the competitor to utilise and implement themselves. This can be detrimental to a company’s competitive advantage. Researchers observed that, in some cases, the company’s “BitBucket” account accidentally had an open repository, and thus source code for a product was viewable. BitBucket is an Atlassian product for code version control and repositories using “Git” and “Mercurial.” An open repository is shown in Figure 5.
Figure 5 - Publicly viewable meeting notes
Figure 6 - Open Repository
Exposed usernames with associated passwords were observed on multiple Jira sites. An example of how the exposed credentials appeared in Jira is shown in Figure 6. These credentials can give an actor access to sensitive information and can be used to launch phishing attacks from legitimate accounts for lateral movement within a target company. An example of this could be if an email account of an executive or senior-level employee being used to trick another employee to authorise wire transfers or hand over sensitive information. The actor could use the credential data to detect patterns and common words if a large number of passwords are visible. Dictionary-style and brute-force attacks could be performed on accounts with no visible passwords.
Figure 7 - Active credentials in the Jira issue
Company information (comments, informal employee communication, issues, wiki pages) and documents (error logs, proprietary information, spreadsheets) gathered on exposed Confluence and Jira sites can be used to craft convincing spear-phishing emails to target other company email accounts. Spear phishing is one of the most effective tactics that is utilised by some of the most sophisticated threat groups around the globe. These emails can be specifically targeted towards the individual with only relevant information to increase the likelihood that the recipient will follow an embedded malicious link or open a malware-laden file attachment. The risk of detection can be reduced because the phishing emails can be aimed directly at a small number of users to achieve their objective. Targeting of generic emails such as “email@example.com” or “firstname.lastname@example.org” could then be avoided by an actor because email accounts deemed more valuable would be targeted instead to minimize the chances of detection. Microsoft Word and PDF documents collected, particularly from Confluence because that platform was observed to contain a larger volume of documents, can be weaponized to drop malware or attempt to redirect to a malicious website. A document that contains internal information in a phishing email is far less likely to raise suspicion of potentially malicious activity because a recipient would be familiar with the content. An example of an internal document is shown in Figure 7.
Figure 8 - Internal PDF Document
Anomali researchers have observed Jira services that expose companies’ entire employee list. This can give an actor a full range of people to target and conduct further reconnaissance on. If an actor can find one email and infer an email pattern, they will be able to derive the email addresses for the rest of the employees in the company given only their full name. An example of exposed employee names is shown in Figure 8.
Figure 9 - Exposed Employee names
Threat actors can exploit the information hosted on the open Confluence and Jira servers for various malicious purposes. Vast amounts of reconnaissance is able to be conducted related to customers, employees, infrastructure, and software and version being utilised. This information can be aggregated and used in social engineering schemes by contacting employees and leveraging particular material to elicit more intelligence. General understanding of an organisation’s inner workings is valuable to a threat actor because of numerous pivot points that could be used for corporate espionage, data-theft, and malware infection. The same pivot point logic can be applied to a company’s client for a supply chain style attack. It is not uncommon for some servers to have a project for each individual customer, as shown in Figure 9, from which an actor can gather specific data such as customer portal passwords, customer requests, email conversations, meeting notes, and product orders, to target that customer. Exposed information can be used to pivot into other malicious activity of the actors choosing, and depending on what data is left publicly accessible.
Figure 10 - Publicly viewable project for each customer in Jira server
Exposing customer information can also lead to a violation of the General Data Protection Regulation (GDPR) that was implemented by the European Union (EU) in 2018. GDPR applies to organisations located within and outside the EU that hold the data of subjects residing in the EU. Article 4 of GDPR broadly defines “Personal Data” as “any information relating to an identified or identifiable natural person.” Failing to protect customer data and disclosing any leaked information to affected clients can result in affected entities filing a complaint to the Data Protection Authority (DPA). Entities can be in subject of “administrative fines up to 10 000 000€ EUR, or in the case of an undertaking, up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher.”
Any company that uses a project management software should have periodic audits of what material may be publicly accessible because as this research shows there are numerous companies unwittingly exposing data that can be utilized by threat actors. Policies should be in place to ensure that potentially sensitive information is only accessible by individuals who are associated with that project.
Permissions and restrictions can be managed via “Groups” in Atlassian Cloud (Confluence and Jira) sites and when a user is created they are automatically added to a default group. The Jira default access group is “jira-users” that allows users to see project issues and create new issues. In Confluence, the default group is “confluence-users” that gives the permissions to view and create content, and create personal and global spaces.
Figure 11 - Default Access Group with Product Access
“Global Permissions” can be set in Jira through the Admin page. The permission categories are:
These global permission categories can be assigned on a group basis, as shown in Figure 11.
Figure 12 - Adding Global Jira Permissions
A global permission that has been determined to be sensitive, such as those out of the global permission categories listed above, should NOT be added to the group “Anyone.” It is paramount to clarify to employees responsible for maintaining the product management software to know that the group category “Anyone” applies to any individual inside or outside the company (general public) who navigates to the correct URL. Adding the Anyone group to a permission will negate the safety measures previously put in place with said permissions.
A project-specific permission can be set on a project on an individual basis in Jira via “Permission Schemes.” Permissions to set include:
Similar to the “Anyone” group category for global permissions, permissions in a scheme should not be granted to the Anyone group because it WILL make the information publicly accessible (Figure 12).
Figure 13 - Remove “Anyone” access to sensitive projects
Project management, is a key to the success of any company no matter what industry they’re in by maintaining workflows on assignments, record keeping, and sharing information. It is also possible that if this critical information falls into the wrong hands it could be exploited for malicious purposes. It is for this reason, the information the project management software contains, that administrators should control who gets access to what information, and only on a need-to-access basis. A malicious use case of the stolen information includes but not limited too, phishing emails containing legitimate documents employees or clients are expecting to see. This capitalizes on a trust relationship which increases the likelihood that a weaponized version of the document will be opened. Additional data stored could consist of maintenance schedule and products for infrastructure improvements. This would give insight into how and when a threat actor may attack an organization with exploits and tools specifically crafted to work on the target network.
Periodic auditing of project management software is crucial to ensure that sensitive information is unaccessible to anyone without the need to know. The Mitigation Guidance section above offers some specific information on Confluence work group functions and how to assist in creating spaces that can only be accessed by users who have a need to know. Furthermore, there have been cases after this research was conducted in which individuals reported that their project management systems were breached, or malicious activity was directly targeting said systems. Threat groups in the reconnaissance phase of their operation will target places that store information, project management software is a prime treasure chest with key information threat actors desire.