How we found an IDOR in Jira

This blog details our discovery of an Insecure Direct Object Reference (IDOR) vulnerability in JIRA, a product by Atlassian. You may be familiar with Atlassian platform from our previous blog, where we discussed how we found a wormable XSS vulnerability in their web application. If you haven't already, we encourage you to read that blog after completing this one. In case, if you're new to IDORs let's have a brief intro about them:

What is an IDOR

IDOR (Insecure Direct Object Reference) is a security vulnerability that occurs when an application provides direct access to objects based on user input without proper access controls. This can allow attackers to bypass authorization and access sensitive data or perform unauthorized actions.

What is JIRA

Jira is a project management tool developed by Atlassian, widely used by software development teams for tracking issues, managing projects, and fostering collaboration.

Finding IDOR in JIRA

During our testing of Jira, we observed that creating an account in Jira grants you access to a diverse range of Atlassian products beyond core Jira functionality. These products, including Jira Confluence, Atlas, Trello, Compass, Opsgenie, and Product Discovery, which can be utilized based on individual team or project needs. During our in-depth analysis of Jira, we discovered a significant vulnerability:

Unauthorized users, those without any connection to the organization established within Jira, were able to add specific Jira products to their accounts. These products included Compass, Atlas, Product Discovery, Opsgenie etc. This unauthorized addition of products poses a potential risk, as it could lead to unintended consequences or security risks. This vulnerability highlighted a potential gap in the access control mechanisms for Jira accounts, allowing individuals outside the intended user base to gain access to features and functionalities that they should not have access to.

Now that we have understood the nature of this vulnerability, let's delve into the step-by-step process we followed to successfully add products from our own account to a victim organization without requiring any prior access to their workspace.

Adding New Products to Victim's Organisation:

We began by logging in to our account at admin.atlassian.com. To gain a comprehensive understanding of the application's logic and functionality, we then navigated through its interface. During this exploration, we noticed a mosaic icon in the top left corner. Clicking this icon revealed a drop-down menu that included an "Administration" section. Once we selected administration section, it displayed many tabs but the "Products" tab looked interesting. So upon clicking, it directed us to the product page where we could add new products by selecting our site.

During our exploration of this page, we utilized BurpSuite to intercept and analyze the HTTP requests generated when adding new products. To illustrate, let us consider a scenario where "Jira Compass" was added as a new product to our site. The following HTTP request was observed:

POST /gateway/api/bxp/signup/product/activate HTTP/1.1
Host: admin.atlassian.com
Connection: close
Content-Length: 215
sec-ch-ua: "Google Chrome";v="107", "Chromium";v="107", "Not=A?Brand";v="24"
sec-ch-ua-platform: "Windows"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
Content-Type: application/json
Accept: */*
Origin: https://admin.atlassian.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://admin.atlassian.com/gpa-cross-flow/?cloudId=3e4c1674-29d7-
42fb-aceb-8f0a0fafc1f7&journey=get-
started&locale=en&originProduct=admin&parentUrl=https%3A%2F%2Fadmin.atlassia
n.com%2Fs%2F3e4c1674-29d7-42fb-aceb-
8f0a0fafc1f7%2Fbilling%2Faddapplication&sourceComponent=BUX%23addapplication
%3EProductStoreTryNow&sourceContext=addapplication-
page&targetProduct=compass&_c=2
Accept-Language: en-US,en;q=0.9
Cookie:
{"cloudId":"<<paste the cloud id of unauthorized
account>>","entitlementId":"1eceb447-ba64-435d-8e60-
659dcfe79c56","offerings":[{"offeringId":"7af07cb3-d4e5-473e-
87b33ae3bc9248a6","pricingPlanId":"","chargeElement":"user"}]}

Our analysis revealed that the product addition process included a unique cloud ID parameter for each user. This prompted us to investigate the potential consequences of modifying this parameter with another user's cloud ID. In the above mentioned HTTP request, we replaced the cloud ID value with that belonging to a victim organization. To further explore this scenario, we employed an unauthorized domain, such as example.atlassian.net, and utilized its cloud ID to attempt adding Compass as a new product to that domain. Upon sending this modified request containing the unauthorized cloud ID, we received a 200 OK response, indicating successful product addition to the unauthorized account.

Upon reviewing the product section within the victim's account, we confirmed the addition of Compass by an unauthorized entity.

Furthermore, by modifying the cloudId parameter within the respective HTTP request bodies, an attacker could potentially add other products, such as Atlas and Jira Product Discovery, to the victim's organization.

Obtaining the Cloud ID

This process was facilitated by enumerating the cloud ID by simply visiting the target organization's subdomain (target.atlassian.net) and analyzing the captured network traffic using BurpSuite, we were able to identify the endpoint containing the site ID (which is equivalent to the cloud ID). The specific endpoint is provided below:

Removing Installed Products from Victim's Org:

As an attacker, we couldn't just delete any product from the victim's organization but only those products that were added by us. For instance, if we initially added Atlas to the victim's environment, we could only subsequently delete the Atlas product. To manually remove the added products, it was necessary to navigate to the JIRA administration page.

Following the successful addition of products to the victim's organization, we were able to manage these products from our own subscription page. To access subscription management functionalities, we navigated to the Atlassian Billing Console. Within the console, we observed a comprehensive list of added products, including those that had been provisioned within the victim's organization.

Upon clicking the "Manage Subscriptions" button associated with the added products, we were redirected to the product management page. Within this page, we could locate the products that had been previously added to the victim's organization (e.g., Compass) by scrolling through the product list. Subsequently, by clicking the ellipsis menu (represented by three dots) next to each product and selecting the "Delete" option, we successfully removed the corresponding product from the victim's organization as well.

The successful deletion of products from the victim's organization had a severe and lasting impact. Notably, the victim was permanently prohibited from re-adding those deleted products, even through legitimate means. This effectively restricted the victim's ability to utilize essential tools within their Atlassian ecosystem. By repeatedly installing and subsequently removing all JIRA products associated with a particular cloud ID, attackers could effectively deny the victim the ability to install and utilize those products indefinitely.

The primary impacts of this vulnerability were:

• Unauthorized Product Provisioning: We were able to add new products to the victim's organization without their consent.
• Unauthorized Product Removal: We could remove installed products from the victim's organization, disrupting their workflows.
• Persistent Service Disruption: By repeatedly installing and removing products, we effectively denied the victim's organization the ability to utilize specific products.

Conclusion:

This IDOR vulnerability exposed a critical security flaw within Jira. By exploiting this vulnerability, attackers could've manipulated product installations and removals within victim's accounts, effectively disrupting their service access. This highlights the importance of robust access control mechanisms and thorough security testing to prevent such vulnerabilities from impacting users and compromising digital security.