Reversing Bytecode into Bounties: Uncovering Vulnerabilities in Jira and Confluence Plugins

Reversing Bytecode into Bounties: Uncovering Vulnerabilities in Jira and Confluence Plugins

Speakers: Giuliana (Security Engineer, Atlassian), Jamal (Security Engineer, Atlassian)

Conference: Kawaiicon

YouTube: https://www.youtube.com/watch?v=UTwU9ljosus

Overview

In their Kawaiicon presentation, "Reversing Bytecode into Bounties," Atlassian security engineers Giuliana and Jamal provided a comprehensive guide to identifying and exploiting vulnerabilities within third-party plugins for Atlassian's Data Center (DC) products, Jira and Confluence. The talk revealed a critical security landscape: these plugins, widely used by large enterprises, often possess deep integration with the host application, sharing databases and core functionalities. This inherent integration means that a vulnerability in a seemingly innocuous plugin can directly compromise the entire Jira or Confluence instance, exposing sensitive customer data and leading to significant security incidents.

The speakers highlighted Atlassian's proactive "too big to fail" project, an initiative undertaken to address the widespread security risks posed by these third-party extensions. Their initial assessment of the top 20 riskiest DC plugins yielded alarming results: 18 vulnerabilities were discovered, with 13 classified as high or critical severity. This striking success rate underscores the prevalence of exploitable flaws within the marketplace ecosystem and points to a lucrative opportunity for security researchers. Giuliana and Jamal not only detailed their methodology—from target selection and bytecode decompilation to static analysis and practical exploitation—but also demonstrated how these techniques could translate into substantial bug bounty rewards, estimating a potential of over $20,000 in three months for the Atlassian team alone.

This article delves into the technical intricacies of their approach, offering insights into how security professionals and bug hunters can replicate these methods to uncover and responsibly report similar vulnerabilities. It serves as a call to action for defenders to understand the risks associated with third-party software and for researchers to leverage these techniques to improve the security posture of widely used enterprise applications.

Background

▶ Watch: Introduction: Atlassian plugins and their security risks (0:00)

Atlassian's Jira and Confluence are ubiquitous project management and collaborative documentation tools, respectively. While Atlassian offers a modern cloud-based version, many large enterprises continue to rely on the Data Center (DC) versions. These on-premise deployments provide organizations with full control over their data and infrastructure, making them a cornerstone for critical business operations. A key feature of both DC and cloud products is the Atlassian Marketplace, which allows users to extend functionality through third-party applications or "plugins."

For DC products, these plugins are fundamentally Java applications distributed as JAR files. When installed, they run on the same host as Jira or Confluence, sharing the application's database and borrowing core functionality. This deep level of integration, while enabling powerful extensions, introduces significant security risks. As Giuliana emphasized, a vulnerability within a plugin can directly impact the host product and all associated data, even though Atlassian does not develop these third-party extensions. Past incidents where compromised plugins led to full Confluence compromises spurred Atlassian's "too big to fail" project, aimed at proactively identifying and mitigating these ecosystem-wide risks. The project's initial focus on the top 20 riskiest DC plugins revealed a high density of critical vulnerabilities, validating the urgent need for a robust testing methodology.

Key Findings

▶ Watch: Decompiling Java Plugins: JAR files to source code (6:00)

The "too big to fail" project delivered compelling evidence of the widespread security challenges within the Atlassian Data Center plugin ecosystem. Out of the initial 20 top-risk DC plugins subjected to penetration testing, a staggering 18 vulnerabilities were discovered, with 13 of these classified as high or critical severity. This high success rate not only highlighted the significant security posture concerns within the marketplace but also demonstrated the effectiveness of the team's developed methodology. The speakers estimated that had these findings been submitted through Atlassian's public bounty program, they would have generated at least $20,000 in bounties within a three-month period.

The core contribution of their talk was the articulation of a practical, repeatable process for uncovering these vulnerabilities in third-party Java applications without access to their original source code. This methodology consists of four main steps:

1. Choosing a good target: Identifying high-impact plugins based on download count, broad permissions, and risky functionalities.
2. Decompiling the marketplace app: Converting the distributed Java bytecode back into human-readable source code.
3. Code review with Static Analysis Security Testing (SAST): Utilizing automated tools and manual inspection to find vulnerability leads.
4. Penetration testing and exploitation: Setting up a local environment to confirm and exploit identified vulnerabilities.

The talk specifically demonstrated the discovery and exploitation of an XML External Entity (XXE) Injection vulnerability within a hypothetical "Spreadsheets for Jira" plugin. This practical example served to illustrate how the combination of decompilation, static analysis, and an understanding of common web vulnerabilities could lead to successful exploitation and sensitive data exposure.

Technical Deep Dive

▶ Watch: Code Review with Static Analysis: Finding XXE (10:10)

The technical core of Giuliana and Jamal's presentation revolves around overcoming the challenge of auditing third-party Java applications for which source code is unavailable. Their approach effectively transforms a black-box scenario into a white-box testing opportunity.

Target Selection

The first crucial step is selecting a high-value target. The speakers advised looking for plugins with high download counts, as these represent a larger attack surface and potential impact. Functionalities that inherently involve risky operations, such as "RCE as a service" (remote code execution), or those requiring large scopes and permissions, are prime candidates. The example given was a fictional "Spreadsheets for Jira" plugin, designed to mimic real-world risky applications, which involved importing and exporting data, making it susceptible to XML processing vulnerabilities. Crucially, researchers should also verify if the chosen plugin is part of a bug bounty program to ensure eligibility for rewards.

Decompilation of Java Bytecode

Since third-party developers do not provide source code, the team developed a process to reverse-engineer the distributed binaries.

1. JAR and OBR Files: Atlassian DC plugins are distributed as JAR (Java Archive) files, which are essentially standard zip files containing compiled Java .class files, metadata, and other resources. Occasionally, plugins are packaged as OBR files, which are also zip files but contain multiple JAR files within them. The first step is to simply unzip these archives to extract their contents.
2. Class Files and Bytecode: Inside the unzipped archive, the core components are the .class files. These contain Java bytecode, an intermediate binary format that is not human-readable. The challenge is to convert this bytecode back into comprehensible Java source code.
3. Decompilers: The speakers highlighted the use of open-source decompilers for this task. They specifically mentioned using Procyon and CFR, noting that different decompilers can produce slightly varied source code, which can be advantageous for broader analysis when used in parallel. The Atlassian team developed an automated script to orchestrate the decompilation process, producing an organized output directory containing both the original unzipped resources (like Velocity templates and the critical Atlassian-plugin.xml manifest file) and the decompiled source code from each decompiler. While the demo used a clean example, real-world plugins often include numerous third-party libraries (e.g., Jackson, Jsoup), making the decompiled output quite large and the process time-consuming.

Code Review with Static Analysis Security Testing (SAST)

With readable source code in hand, the next phase is to analyze it for potential vulnerabilities.

1. SAST Tools: The team primarily used Semgrep, a versatile SAST tool known for its community-driven rulesets and ability to apply custom rules. For Java applications, Semgrep can be configured with specific Java rule sets to identify common insecure coding patterns.
2. Identifying Vulnerability Leads (XXE Example): In the "Spreadsheets for Jira" example, running Semgrep against the decompiled code flagged a potential XML External Entity (XXE) Injection vulnerability. The finding pointed to a line in SpreadsheetServiceImplement.java involving DocumentBuilderFactory.newInstance(), indicating the creation of an XML parser instance without explicit security controls.
3. Understanding XXE: An XXE injection occurs when an XML parser processes external entities defined within an XML document, allowing an attacker to include arbitrary files or fetch data from external URLs. By default, many XML parsers are configured to process external entities, which can be exploited to read local files (e.g., file:///etc/passwd), perform server-side request forgery (SSRF), or even trigger denial-of-service attacks. The critical vulnerability arises when the DocumentBuilderFactory instance is created without disabling features like FEATURE_SECURE_PROCESSING or DISALLOW_DOCTYPE_DECL.
4. Tracing the Vulnerability: To confirm the vulnerability, the next step is to trace how user-controlled input reaches the insecure XML parser. Using an IDE like IntelliJ, the speakers demonstrated how to find all usages of the DocumentBuilderFactory.newInstance() call. This led them to a REST endpoint defined in SpreadsheetRestResource.java at /process-xml. This endpoint, exposed via an HTTP POST request, directly accepts XML input and passes it to the vulnerable parsing method.
5. Atlassian-plugin.xml Validation: To verify that this REST endpoint is indeed exposed by the plugin and accessible within Jira, the Atlassian-plugin.xml manifest file is crucial. This file defines the plugin's modules, including REST modules, specifying their base paths and versions. By inspecting this file, the team confirmed the base path (/rest/spreadsheets/1.0) and the package containing the vulnerable REST resource, thus constructing the full vulnerable endpoint: Jira/rest/spreadsheets/1.0/process-xml.
6. Atlassian-Specific Annotations: The speakers also noted the utility of Atlassian-specific annotations, particularly those related to authorization. The presence or absence of these annotations (e.g., @RequiresJiraAdmin, @AnonymousAllowed) can quickly indicate potential broken access control vulnerabilities or endpoints exposed unintentionally. Atlassian's public documentation provides details on these annotations, serving as a valuable resource for researchers.

Demo / Proof of Concept

▶ Watch: Joining Atlassian's Private Marketplace Bug Bounty (21:40)

The ultimate validation of a discovered vulnerability is a successful proof of concept (PoC) in a controlled environment. Giuliana and Jamal outlined a straightforward process for setting up a local Jira Data Center instance and exploiting the identified XXE vulnerability.

Setting Up the Test Environment

1. Atlassian SDK: The easiest way to run Jira or Confluence Data Center locally is by using the Atlassian SDK. This provides a command-line interface (CLI) tool for downloading and running various Atlassian products.
2. Version Compatibility: Before launching, it's essential to check the marketplace listing for the plugin to determine its compatible Jira/Confluence versions (e.g., Jira Data Center 10 to 10.61).
3. Launching Jira: The atlas-run-standalone command is used to start a specific product and version: atlas-run-standalone --product jira --version 10.61.0. This process downloads necessary components and compiles the instance, eventually making it accessible at localhost:2990/jira with default admin/admin credentials.
4. Uploading the Plugin: Once Jira is running, the plugin's JAR file is uploaded via the Jira UI: Manage Apps -> Upload app. The plugin then appears in the list of user-installed apps.
5. Accessing Plugin Functionality: The "Configure" button next to the installed plugin often provides direct access to its web-based functionalities. For the "Spreadsheets for Jira" demo plugin, this led to an "XML Processor" page.

Exploiting the XXE

The demonstration showed two primary ways to trigger the XXE vulnerability:

1. Via the Plugin UI: On the "XML Processor" page, a user could upload a malicious XML file. This file would contain an external entity declaration attempting to read a sensitive local file, such as /etc/passwd. For example:

Upon processing this XML, the contents of /etc/passwd would be displayed on the screen, confirming the XXE.

1. Via a cURL Request: Alternatively, leveraging the identified REST endpoint, a cURL request could be crafted to send the malicious XML directly to the vulnerable API:

This method would yield the same result, printing the contents of /etc/passwd to the console, demonstrating a successful exploitation without relying on the plugin's graphical interface. This white-box testing approach, combining static analysis leads with a controlled dynamic testing environment, significantly accelerates the bug-hunting process and is applicable to any Java application distributed as a JAR file.

Defensive Implications

▶ Watch: Resources and Expanding Your Java Bug Hunting Skills (24:00)

The findings presented by Giuliana and Jamal carry significant implications for both plugin developers, Atlassian, and organizations using Jira and Confluence Data Center.

For Atlassian (and other marketplace operators):

Atlassian is actively working to mitigate these risks. Their key defensive strategies include:

• App Scanning: All apps uploaded to the Atlassian Marketplace (both cloud and DC) undergo automated scanning. This includes checking for:
• Secrets: Hard-coded API keys, tokens, or passwords.
• Vulnerabilities: Automated decompilation and scanning for critical, high-confidence vulnerabilities, which are then reported back to app developers. This mirrors the process described in the talk.
• Dependencies and CVEs: Identification of vulnerable packages and known CVEs within the plugin's libraries.
• Malware: Detecting malicious plugins designed to cause damage or exfiltrate data.
• Encouraging Cloud Adoption: Atlassian strongly advocates for customers to migrate from Data Center to their cloud offerings. Cloud apps run in isolated, sandboxed environments on Atlassian's infrastructure, providing significantly more granular authorization controls and limiting the capabilities of third-party apps compared to the extensive permissions a DC plugin can wield. This architectural shift inherently reduces the attack surface and impact of plugin vulnerabilities.

For Plugin Developers:

The talk implicitly provides crucial guidance for developers:

• Secure XML Processing: When handling XML input, developers must explicitly disable external entities and other dangerous features in their DocumentBuilderFactory instances. This typically involves setting specific features to false (e.g., setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)).
• Robust Authorization: Implement and utilize Atlassian's authorization annotations (e.g., @RequiresJiraAdmin, @AnonymousAllowed) consistently and correctly to ensure that REST endpoints and other functionalities are only accessible by authorized users.
• Dependency Management: Regularly audit and update third-party libraries to avoid known vulnerabilities (CVEs).

For Organizations Using Jira/Confluence Data Center:

Customers running DC instances should be highly aware of the risks posed by third-party plugins:

• Scrutinize Plugin Selection: Exercise extreme caution when installing plugins. Prioritize plugins from reputable vendors with strong security track records.
• Review Permissions: Understand the permissions and scopes requested by each plugin, as these indicate its potential impact on the system.
• Consider Cloud Migration: If security is a paramount concern, migrating to Atlassian Cloud can significantly reduce the risk exposure from third-party applications due to its sandboxed architecture.
• Internal Auditing: Consider applying similar decompilation and analysis techniques internally to plugins deemed critical or high-risk, especially if source code is unavailable.

Key Takeaways

• Atlassian Data Center plugins pose significant security risks due to their deep integration with the host application, sharing databases and core functionalities, making plugin vulnerabilities a direct threat to the entire Jira or Confluence instance.
• Decompilation of Java bytecode is a powerful technique for security researchers to perform white-box testing on third-party Java applications (JAR/OBR files) when source code is unavailable, enabling detailed code review and vulnerability discovery.
• Static Analysis Security Testing (SAST) tools like Semgrep are effective for identifying vulnerability leads in decompiled Java code, especially when configured with specific rulesets for common insecure patterns.
• XML External Entity (XXE) Injection remains a prevalent vulnerability in XML-processing applications, allowing attackers to read local files, perform SSRF, or trigger DoS attacks if XML parsers are not securely configured.
• Atlassian's private marketplace bug bounty program offers a lucrative opportunity for security researchers to find and report vulnerabilities in third-party plugins, with a lower barrier to entry and a high likelihood of discovering impactful bugs.
• The methodology presented is broadly applicable to any Java-based application distributed as bytecode, extending its utility beyond Atlassian products to other enterprise software and custom applications.

About the Speaker(s)

Giuliana is a Security Engineer at Atlassian, specializing in security testing. Her work involves proactively identifying vulnerabilities within Atlassian's products and ecosystem, including the in-depth analysis of third-party marketplace plugins.

Jamal is also a Security Engineer at Atlassian, primarily working in product security. He previously completed a three-month stint within Giuliana's security testing team, during which the foundational work for this talk, including the "too big to fail" project, was conducted. Together, they bring a wealth of experience in both offensive and defensive security practices within the Atlassian environment.