No Time to REST: Check Your Jira Permissions for Leaks

Executive Summary

A permissions misconfiguration in Jira exposes employee and project details of hundreds of companies, including members of the Fortune 1000. 

Varonis researchers enumerated a list of 812 subdomains and found 689 accessible Jira instances. We found 3,774 public dashboards, 244 projects, and 75,629 issues containing email addresses, URLs, and IP addresses in those instances.

We also discovered that the Jira REST API exposes more public info than the web interface. As a result, an admin may think nothing is exposed, while attackers can see more data via the API.

Note: this is NOT a vulnerability with Jira. Data is exposed when a Jira customer accidentally misconfigures their Jira settings. 

Impact

At first glance, URLs and email addresses may seem innocuous, but email addresses attached to Jira issues can reveal who a company’s customers are. Some of the Jira issue records we found expose bugs, product features, and roadmap details.

There are situations where a Jira user will want to expose a dashboard or filter intentionally.  However, our research shows that misconfigurations resulting in data exposure are still far too prevalent.

In one example, we found a shipping company’s default “System” dashboard with publicly visible URL to sensitive systems (e.g., build servers, source code repos, roadmap tools). This is the perfect starting point for an attacker to phish users or move laterally.

A banking service provider’s Jira instance we scanned exposed dozens of bank employee email addresses, which can be used to spoof phishing email senders or credential stuff / brute force the bank’s SaaS apps.

Background

Jira is a popular issue-tracking and agile software development product from Atlassian. It comes in two flavours: Jira Cloud and Jira server (on premises).

Jira contains dashboards that help product managers and developers track their projects. Dashboards can have filters. Both dashboards and filters have permissions settings to control who can view and modify them.

There are two permissions settings that Jira admins commonly misunderstand and accidentally misconfigure:

1. Public sharing. This setting allows users to share dashboards and filters with all users, including anonymous users.
2. Permissions scheme with the group “public.” Jira admins occasionally assume that “public” means open to everyone in the company when it means open to the internet.

Atlassian has made updates to its UI to help customers avoid making this critical mistake. 

Back in 2016, the company changed the wording of the settings from “Everyone” to “Public” and added a warning message:

The company also added a global setting that admins could use to disable public sharing entirely. This setting is found in JIRA Admin > System > General Configuration > Edit Settings.

Note, however, that disabling public sharing globally will not automatically remove public permissions from Jira objects that were previously made public. You’ll need to reconfigure sharing settings on each dashboard.

Old issue, new problems

This is not the first time someone has written about Jira permissions misconfigurations, but it’s worth digging deeper into what our researchers found.

First, given what our scans show, we wanted to raise awareness among Jira admins who may still have misconfigured instances that expose sensitive data to the public.

Second, our research team found that we can uncover more exposed data than previously discovered (via the web UI) using Jira’s REST API. With the REST API, an attacker can write a simple script to scan a company’s Jira account and rapidly extract sensitive data.

Here’s an example of a Jira customer dashboard in the web UI. Not much to see here:

Here’s the same dashboard via the REST API:

The API response reveals the owner, including their name, avatar, and user page URL.

What are the risks?

What can an attacker do with Jira dashboard information?

Reconnaissance. Knowing a project name, owners, and avatars can help an attacker craft a targeting phishing campaign. 

Lateral movement. We found that some Jira dashboards contain sensitive data about other tools and systems the company uses (internal IP addresses, URLs, credentials, etc.). Knowing the URLs of internet-facing systems, an attacker can launch a password spraying or credential stuffing attack or exploit known vulnerabilities in those systems.  

Exfiltration. In severe cases, an attacker won’t have to use information gleaned from Jira to pivot to more sensitive systems because the information they’re after is stored in the Jira dashboard itself. 

How much data is public?

Using the REST API, our team found 689 Atlassian subdomains with public projects, filters, dashboards, or issues. 

When we scanned subdomains matching companies on the Fortune 1000 list, we found many instances of the System dashboard with nothing more than the owner exposed. However, in other cases, we found hundreds of exposed issues.

• 812 Atlassian subdomains checked
• 689 sites found (84%)
• The average number of public objects per account:
  • 87 filters
  • 6 dashboards
  • 12 projects
  • 4,448 issues
• The total number of public objects found:
  • 23,135 filters
  • 3,774 dashboards
  • 244 projects
  • 75,629 issues
• Potentially sensitive info:
  • 2,922 email addresses
  • 5,424 IPv4 addresses
  • 60,411 URLs

Mitigation: How to perform a Jira settings audit

Here are some audit steps you can take to ensure your Jira instance is configured exactly how you expect.

1. Follow this excellent guide from Atlassian describing how to remove public access 
2. Check every public permission in the global permissions page:
   1. Go to Settings ? System ? Global Permissions
   2. Ensure there are no permissions that have the public group in the Users / Groups column that shouldn’t be public to the internet
   3. If there are, click “Delete” to remove the public group from any permission that shouldn’t be public

1. Check every public permission scheme:
   1. Go to Settings ? Issues ? Permission Schemes
   2. Check each permission scheme and remove public access where appropriate for your organisation
   3. Make sure there are no groups in the Granted to column that have the warning, “Any logged in or anonymous user can browse this project”
   4. If there are, click “Remove” to remove the Group – Public group. We recommend removing this group from all projects.

Conclusion

There’s a reason why “Broken Access Control” has catapulted to the top of the OWASP Top 10 Web Application Security Risks. 

Organisations have dozens of SaaS apps to manage—each with its own permissions schemes and settings. And many of them are interconnected and internet-facing, making the risk even greater. One misconfiguration can open sensitive data to your entire company or the entire world.

We’re going to keep hunting for SaaS misconfigurations and sharing what we find to educate admins on what they can check for to mitigate cloud data risk. 

We’re also continually building features in DatAdvantage Cloud to automatically scan your SaaS applications to find common misconfigurations, highlight sensitive data exposure, and alert you when something critical changes (like someone changing a sharing setting from private to public).