<h3>Weighing the Benefits of Project Management Applications Against the Risk</h3><p>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.</p><h2>Overview</h2><p>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.</p><p>The data types include:</p><ul><li>Credentials</li><li>Client information</li><li>Employee information</li><li>Internal documents</li><li>Source code</li></ul><p>Industries:</p><ul><li>Education</li><li>Finance</li><li>Government</li><li>Healthcare</li><li>Information Technology</li><li>Retail</li></ul><h2>Context for Confluence and Jira</h2><p>Confluence is a document collaboration software used by approximately 35,000 customers, according to the company’s website.<sup>[3]</sup> 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.</p><p>Jira is a product management and issue tracking software that is used by approximately 65,000 customers.<sup>[2]</sup> 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.</p><h2>Collection Methodology</h2><p>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.<sup>[4]</sup> 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.<sup>[5]</sup> 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.</p><p>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.</p><p>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`.</p><p>The following methods were used for collecting Atlassian domains, both cloud and self-hosted:</p><ul><li>Domain Name Permutation</li><li>Google Dork</li><li>Internet Census</li><li>Observed Domain Databases</li><li>Passive DNS</li></ul><h2>Domain Filtering</h2><p>The total amount of domains tested were 53,249 which are broken down as follows:</p><ul><li>Jira servers with viewable dashboard: 23,178</li><li>Jira servers with viewable projects: 706</li><li>Confluence servers with viewable spaces: 3,803</li></ul><p style="text-align: center;"><em><img alt="Breakdown of tested domains" src="https://cdn.filestackcontent.com/8LssIE33StiWEPpC7Exy"/><br/> Figure 1 - Breakdown of tested domains</em></p><p>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.</p><p style="text-align: center;"><em><img alt="Jira Server with viewable dashboard" src="https://cdn.filestackcontent.com/rXOGgXoR6qIKUxBfC5VQ" style="border:1px solid #e8e9ee;"/><br/> Figure 2 - Jira Server with viewable dashboard</em></p><p>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.</p><p style="text-align: center;"><em><img alt="Jira server with viewable tickets [200 HTTP Status Response]" src="https://cdn.filestackcontent.com/cs3KHxEUTnWG8oWoHoFE" style="border:1px solid #e8e9ee;"/><br/> Figure 3 - Jira server with viewable tickets [200 HTTP Status Response]</em></p><p style="text-align: center;"><em><img alt="Result of redirection because of no publicly viewable projects [302 Status Code Redirection]" src="https://cdn.filestackcontent.com/jlyh70CPQvZgiHFba7Og"/><br/> Figure 4 - Result of redirection because of no publicly viewable projects [302 Status Code Redirection]</em></p><p>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.</p><p>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.</p><h2>Misconfiguration Risk</h2><p>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:</p><ul><li>Corporate espionage</li><li>Credential-pivoting</li><li>Phishing</li><li>Reconnaissance</li></ul><h3>Corporate Espionage</h3><p>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.</p><p style="text-align: center;"><em><img alt="Publicly viewable meeting notes" src="https://cdn.filestackcontent.com/GSkjyjCRriGRhRVpJ66w" style="border:1px solid #e8e9ee;"/><br/> Figure 5 - Publicly viewable meeting notes</em></p><p style="text-align: center;"><em><img alt="Open Repository" src="https://cdn.filestackcontent.com/incFYsJMRbe36K1uGbax" style="border:1px solid #e8e9ee;"/><br/> Figure 6 - Open Repository</em></p><h3>Credential Exposure</h3><p>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.</p><p style="text-align: center;"><em><img alt="Active credentials in the Jira issue" src="https://cdn.filestackcontent.com/cHAf19RZSPmym5YuyhwL" style="border:1px solid #e8e9ee;"/><br/> Figure 7 - Active credentials in the Jira issue</em></p><h3>Phishing</h3><p>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 protected]” or “[email protected]” 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.</p><p style="text-align: center;"><em><img alt="Internal PDF Document" src="https://cdn.filestackcontent.com/8bKpVjpwSFKlY7pLhBAh"/><br/> Figure 8 - Internal PDF Document</em></p><p>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.</p><p style="text-align: center;"><em><img alt="Exposed Employee names" src="https://cdn.filestackcontent.com/Tp8dSctAS2WYFb5GI8gI" style="border:1px solid #e8e9ee;"/><br/> Figure 9 - Exposed Employee names</em></p><h3>Reconnaissance</h3><p>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.</p><p style="text-align: center;"><em><img alt="Publicly viewable project for each customer in Jira server" src="https://cdn.filestackcontent.com/imO48u95Qh2IAFz7eglr" style="border:1px solid #e8e9ee;"/><br/> Figure 10 - Publicly viewable project for each customer in Jira server</em></p><h3>General Data Protection Regulation Consequences</h3><p>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.”<sup>[6]</sup> 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.”<sup>[7]</sup></p><h3>Mitigation Guidance</h3><p>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.</p><p>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.<sup>[8]</sup> 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.<sup>[9]</sup></p><p style="text-align: center;"><em><img alt="Default Access Group with Product Access" src="https://cdn.filestackcontent.com/2VRy3ALDQAGMTwRLd2QL" style="border:1px solid #e8e9ee;"/><br/> Figure 11 - Default Access Group with Product Access</em></p><p>“Global Permissions” can be set in Jira through the Admin page. The permission categories are:</p><ul><li><strong>Administer Jira:</strong> Create and administer projects, issue types, fields, workflows, and schemes for all projects. Users with this permission can perform most administration tasks, except: managing users, importing data, and editing system email settings.</li><li><strong>Browse users and groups:</strong> View and select users or groups from the user picker, and share issues. Users with this permission can see the names of all users and groups on your site.</li><li><strong>Create next-gen projects:</strong> Create projects separate from shared configurations and schemes. Next-gen projects don't affect existing projects or shared configurations like workflows, fields or permissions. Only licensed users can create next-gen projects.</li><li><strong>Make bulk changes:</strong> Modify collections of issues at once. For example, resolve multiple issues in one step.</li><li><strong>Manage group filter subscriptions:</strong> Create and delete group filter subscriptions.</li><li><strong>Share dashboards and filters:</strong> Share dashboards and filters with other users.”</li></ul><p>These global permission categories can be assigned on a group basis, as shown in Figure 11.</p><p style="text-align: center;"><em><img alt="Adding Global Jira Permissions" src="https://cdn.filestackcontent.com/IxfnHNm1Tbqc064SJ52L" style="border:1px solid #e8e9ee;"/><br/> Figure 12 - Adding Global Jira Permissions</em></p><p>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.</p><p>A project-specific permission can be set on a project on an individual basis in Jira via “Permission Schemes.” Permissions to set include:</p><ul><li>Creating and editing issues</li><li>Managing watchers</li><li>Leaving comments</li></ul><p>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).</p><p style="text-align: center;"><em><img alt="Remove “Anyone” access to sensitive projects" src="https://cdn.filestackcontent.com/X42BnCRWSSCbvZxOvV6O" style="border:1px solid #e8e9ee;"/><br/> Figure 13 - Remove “Anyone” access to sensitive projects</em></p><h2>Conclusion</h2><p>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.</p><p>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.</p><h2>Endnotes</h2><ol><li>“Company,” Atlassian, accessed April 17, 2019, https://www.atlassian.com/company.</li><li>“Jira Software,” Atlassian, accessed April 17, 2019, https://www.atlassian.com/software/jira.</li><li>“Confluence,” Atlassian, accessed April 17, 2019, https://www.atlassian.com/software/confluence.</li><li>“Customers,” WayBack Machine, accessed April 17, 2019, captured September 8, 2018, https://web.archive.org/web/20181106225754/https://www.atlassian.com/customers?page=1&sortParam=date_created%20desc.</li><li>Catalin Cimpanu, “NASA internal app leaked employee emails, project names,” ZDNet, accessed April 17, 2019, published January 11, 2019, https://www.zdnet.com/article/nasa-internal-app-leaked-employee-emails-project-names/.</li><li>European Parliament, “REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation),” Official Journal of the European Union, L 119/1:Section (26), April 5, 2016, accessed April 17, 2019, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32016R0679.</li><li>Ibid., Article 83, paragraph 4.</li><li>“Create and update groups,” Atlassian Cloud Support, accessed April 17, 2019, https://confluence.atlassian.com/cloud/create-groups-and-update-permissions-744721627.html.</li><li>Ibid</li></ol>
Get the Latest Anomali Updates and Cybersecurity News – Straight To Your Inbox
Become a subscriber to the Anomali Newsletter
Receive a monthly summary of our latest threat intelligence content, research, news, events, and more.