Secret Scanner for Jira and Confluence: CVE-2023–22515 Defense in Depth

TLDR; Upgrade Confluence to a patched version and employ the open-source security scanner n0s1 to proactively address potential secret leaks.

Why do I need a secret scanner?

It is a widely recognized best practice for Product Security Engineers to conduct scans of the software codebase in search of potential inadvertent secret leaks. Developers may find themselves working on a new feature that requires integration with AWS and might, initially for convenience during testing, hardcode the AWS access key. This practice is acceptable for local testing, with the intention of removing the secret prior to pushing the final code to Source Code Management (e.g., GitHub, GitLab, etc.).

However, it is not unusual for individuals to forget to remove the sensitive data before committing changes, resulting in sensitive data being inadvertently exposed within the source code. Consequently, anyone with read access to the repository gains access to the AWS resources associated with the exposed AWS access key in our example.

That is a very common mistake, and well-established Product Security Programs often implement controls, such as pre-commit hooks, or secret scanning tools like GitHub Secret Scanning or GitLab Secret Detection, to mitigate the risk of secret leaks.

In this article, I aim to address a frequently overlooked but similar use case: the inadvertent exposure of secrets within Project Management platforms like Jira, Confluence, and Linear.app.

Confluence page exposing AWS access key

Development teams commonly employ tools like Jira and Linear.app for ticketing and rely on knowledge base platforms such as Confluence to facilitate their software development life cycle (SDLC) processes. Even before a developer writes their initial code, including for instance, an API call to AWS, it’s quite likely that there is already a Jira ticket assigned to that developer, specifying which AWS account to utilize. On top of that, there might be a software documentation page on Confluence outlining the software’s cloud integration. Unfortunately, at times, individuals may inadvertently post sensitive data (such as AWS credentials) on a platform that isn’t suitable for securely storing secrets, like Jira or Confluence.

Why should I scan Jira/Confluence for secrets?

Some people may contend that the consequences of a secret leak within a platform like Confluence are not as significant as a leak within the source code. After all, source code is intended for building and public distribution, while Confluence and Jira implement access controls to restrict access to authorized personnel. I firmly disagree with this perspective, and to illustrate my point, we can examine the disclosure of CVE-2023–22515.

CVE-2023–2215 Confluence unauthorized administrator access

In the event of full exploitation, the CVE-2023–22515 vulnerability could potentially grant external attackers unauthorized administrative access to Confluence Data Center or Confluence Server. Both the vendor (Atlassian)and the US government have issued warnings regarding active exploitation of this vulnerability by nation-state actors. Companies that previously relied on the assumption that Confluence data would only be accessible to authorized users are now confronted with a situation in which they must not only be concerned about attackers attempting to use Confluence as a pivot to access their internal infrastructure but also gaining access to all of their confidential content within Confluence. If attackers can locate secrets within Confluence, as exemplified by our AWS key scenario, we just made their pivoting goal incredibly easy to accomplish.

That’s why it’s considered a sound security practice to exclusively permit the sharing of secrets through approved secret management software (e.g., Vault, 1Password, etc.), and additionally, to employ a secret scanner to proactively monitor the exposure of secrets on unapproved platforms.

What is a secret scanner?

What is n0s1 secret scanner?

n0s1 is an open-source secret scanner designed by Spark 1 Security for use with Jira, Confluence, and Linear.app. It can be executed as a command-line interface (CLI), within a Docker container, as part of GitHub Actions, or integrated into GitLab CI. n0s1 employs predefined and customizable regular expressions to identify a wide range of secret classes that you wish to monitor. Its versatility enables it to address various use cases, which we will explore in the following sections.

n0s1 install

Simply install it via pip and use “-h” to get help. More details at n0s1 documentation page:

python -m ensurepip --upgrade
python -m pip install n0s1
n0s1 confluence_scan -h

Scan Jira from CLI:

Simply install it via pip and scan your Jira server:

n0s1 jira_scan --server "https://<YOUR_JIRA_SERVER>.atlassian.net" --api-key "<YOUR_JIRA_API_TOKEN>"

Scan Jira and Confluence from GitLab CI:

The advantage of integrating with GitHub and GitLab is the ability to centralize all the findings within a unified platform. If you are already scanning for secrets in your codebase and keeping track of these findings in the GitHub Security tab or the GitLab Vulnerability Report, it makes sense to also have the results from the secret scanner sent to the same location. This streamlines the management of security information and enhances overall visibility.

n0s1 findings as part of GitLab Vulnerability report

To create a GitLab Vulnerability report akin to the one displayed in the screenshot, you can achieve this by incorporating the following configuration into your .gitlab-ci.yml file.

jira-scan:
  stage: test
  image:
    name: spark1security/n0s1
    entrypoint: [""]
  script:
    - n0s1 jira_scan --email "<EMAIL>" --api-key $JIRA_TOKEN --server "https://<YOUR_DOMAIN>.atlassian.net" --report-file gl-dast-report.json --report-format gitlab
    - apt-get update
    - apt-get -y install jq
    - cat gl-dast-report.json | jq
  artifacts:
    reports:
      dast:
        - gl-dast-report.json

confluence-scan:
  stage: test
  image:
    name: spark1security/n0s1
    entrypoint: [""]
  script:
    - n0s1 confluence_scan --email "<EMAIL>" --api-key $JIRA_TOKEN --server "https://<YOUR_DOMAIN>.atlassian.net" --report-file gl-dast-report.json --report-format gitlab
    - apt-get update
    - apt-get -y install jq
    - cat gl-dast-report.json | jq
  artifacts:
    reports:
      dast:
        - gl-dast-report.json

*Note: you will also need to add protected JIRA_TOKEN CI/CD variable to your GitLab repository CI/CD settings.

Scan Jira using GitHub Actions:

Additionally, you have the option to use GitHub Actions for running a secret scan and exporting the results into a SARIF report. If you’re utilizing GitHub Enterprise, your report will also be accessible through the Security scanningtab, providing a comprehensive view of your security assessment.

name: jira_secret_scanning
on:
  schedule:
    - cron: "0 10 *  *  *"
  workflow_dispatch:
    
jobs:
  jira_secret_scanning:
    name: Jira Scanning for Secret Leaks
    runs-on: ubuntu-20.04
    steps:
      - name: Run n0s1 secret scanner on Jira
        uses: spark1security/n0s1-action@main
        env:
          JIRA_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
        with:
          scan-target: 'jira_scan'
          user-email: 'service_account@<YOUR_COMPANY>.atlassian.net'
          platform-url: 'https://<YOUR_COMPANY>.atlassian.net'
          report-file: 'jira_leaked_secrets.sarif'
          report-format: 'sarif'
      - name: Upload n0s1 secret scan results to GitHub Security Codescanning
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: jira_leaked_secrets.sarif
      - name: Upload n0s1 secret scan report
        uses: actions/upload-artifact@v3
        with:
          name: n0s1-artifact
          path: jira_leaked_secrets.sarif
          retention-days: 5

Scan Confluence using customized regular expressions:

You can further customize the regex configuration to target specific sensitive data that aligns with your requirements. For instance, if you wish to identify any occurrences of the string “password = “ or “password:”, you can achieve this by creating a local copy of the regex.toml file and appending the following regular expression to it:

[[rules]]
id = "plaintext_password"
description = "Plaintext Password"
regex = '''(?i)password ?[=:] ?.*'''
keywords = ["password"]

You can save your new regex configuration to a local file (e.g. /home/user/my_regex.toml) and use it with the argument “--regex-file”:

n0s1 confluence_scan --regex-file /home/user/my_regex.toml --email <YOUR_EMAIL> --api-key <YOUR_CONFLUENCE_API_TOKEN> --server https://<YOUR_CONFLUENCE>.atlassian.net

If you are using docker, you will need to mount a volume to pass the local file to the container:

docker run -v /home/user/my_regex.toml:/my_regex.toml spark1security/n0s1 confluence_scan --email <YOUR_EMAIL> --api-key <YOUR_CONFLUENCE_API_TOKEN> --server https://<YOUR_CONFLUENCE>.atlassian.net--regex-file /my_regex.toml

Scan Confluence and automatically warn users about secret leaks:

A particularly valuable feature, especially for organizations with extensive Jira/Confluence usage, is the ability to leave a comment on the specific ticket or page where the leak has been discovered. The posted message serves as a warning to the user regarding the potential secret exposure and offers guidance on how to remediate it effectively.

n0s1 confluence_scan --post-comment --server "https://<YOUR_SERVER>.atlassian.net" --api-key "<YOUR_API_TOKEN>"

This approach resonates with the concept that security is a collective responsibility within an organization, while also simplifying the scalability of secret monitoring. Although the security team will maintain a centralized report with all the findings, it also empowers the ticket owner to become informed about the issue and take steps to address the secret exposure on their own.

n0s1 scanner auto message posted to the page where a leak was found

There are various other applications for n0s1. In this article, my primary emphasis was on the blue team’s perspective regarding the secret scanner. Nevertheless, pentesters can also make effective use of it to illustrate scenarios, such as demonstrating the potential impact of CVE-2023–22515 exploitation, even when administrative access is not attainable. The capacity to discover valuable sensitive information might be all that the red team requires to execute privilege escalation and/or pivot within the system.

As n0s1 is an open-source project, you’re welcome to either fork the project or contribute to the original repository. A collaborative endeavor involving the open-source community could significantly enhance the scanner’s capabilities, extending its support to cover additional platforms beyond the current ones (Jira, Confluence, Linear.app). This collective effort can also result in the development of a comprehensive set of regular expressions that effectively identify a broad range of secrets that require protection worldwide.

Did you find this article intriguing? Please feel free to share your comments and feedback regarding the post. If you want to learn more about n0s1 security scanner or any other insightful content by Spark 1 Security, please visit spark1.us

Originally published at: https://medium.com/@marcelosacchetin/secret-scanner-for-jira-and-confluence-cve-2023-22515-defense-in-depth-ce30f10a7661