Jira Information Gathering
What is Jira?
Jira is a web based issue tracking and project management application that can be used to manage a wide array of information. Using Jira, organizations can design workflows to do anything from bug tracking to physical asset management. The flexibility of Jira, while great, can also lead to several issues, if it’s not configured properly.
Authorization
There are a couple of settings in Jira that, when not configured properly, may disclose information about the application and its users. This information may aid an attacker in gaining access to the application. This information disclosure is the result of an authorization misconfiguration in Jira’s Global Permissions settings. Jira uses role-based authorization where users are assigned to groups, and groups are assigned to one or more of the global permissions below.
- Jira System Administrators
- Jira Administrators
- Browse Users
- Create Shared Objects
- Manage Group Filter Subscriptions
- Bulk Changes
Configuration of global permissions is completely up to the application administrator. If they want to give Bob in accounting Jira System Administrators access, they can certainly do that. There are other less obvious configuration mistakes the results of which may be catastrophic.
Browse Users
Upon discovering an instance of Jira, one of the first things I like to do is check for anonymous access to the user picker functionality located at /secure/popups/UserPickerBrowser.jspa
The Issue
By default, it’s only accessible to authenticated users. This function is used to search for a user and assign them tasks. It is a complete list of every user’s username and email address. There are three standard user groups in Jira: Administrators, Jira Users, and Anyone. For one reason or another, an administrator may grant the ‘Anyone’ group access to this functionality. This grants anyone access to the function – even anonymous users.
The Fix
- Log in as a user with administrative privileges
- Click on the options menu at the top right of the window
- In the drop-down menu, Click System
- On the left-hand side under Security click the Global permissions link
- In the center screen under Jira Permissions the Browse Users permission should not contain the Anyone user group
Manage Filters
While not as severe, this issue is similar to the browse users issue.
The Issue
This page lists the most popular filters used to categorizes issues and tasks within the application. It also lists the username of the person who ‘owns’ each of these filters. This will likely not be a complete list of users like the browse users function, but can glean useful information about how usernames are formatted. Additionally, it can give an attacker an idea of what kind of information may be housed within the application.
The Fix
- Log in as a user with administrative privileges
- Click on the options menu at the top right of the window
- In the drop-down menu, click System
- On the left-hand side under Security click the Global permissions link
- In the center screen under Jira Permissions, the Manage Group Filter Subscriptions permission should not contain the Anyone user group
In the end, the Anyone group should not be set on any of these global permissions. Additionally the visibility can be set on a per issue basis, and modifying this setting does not fix issues that were configured this way.
Potential Impact
I wrote a quick python script to show how easy it would be for an attacker to parse this information, which can be found here. This information would be extremely useful in a more targeted password guessing or phishing campaign. If you can compromise an administrator account, all other users are effectively compromised. It’s best to assume that, no matter the security controls in place, at some point an attacker is going to find a way in. Therefore, storing sensitive information such as usernames, passwords is not recommended.
References
Explore more blog posts
Part 1: Ready for Red Teaming? Intelligence-Driven Planning for Effective Scenarios
Take time for dedicated planning and evaluation ahead of red team testing to prepare your organisation for effective red team exercises.
The Strategic Value of Platformization for Proactive Security
Read about NetSPI’s latest Platform milestone, enabling continuous threat exposure management (CTEM) with consolidated proactive security solutions.
Backdooring Azure Automation Account Packages and Runtime Environments
Azure Automation Accounts can allow an attacker to persist in the associated packages that support runbooks. Learn how attackers can maintain access to an Automation Account.