Bitbucket Holes: Why Your CI/CD Pipeline Leaks Secrets
Mandiant discovered a situation in which client-specific secrets had been exposed from Atlassian’s code repository tool, Bitbucket, and used by threat actors to obtain unauthorised access to AWS when looking into recent disclosures of AWS secrets. This blog post explains how you could be vulnerable to security breaches if Bitbucket Secured Variables leak in your pipeline.
It is an Atlassian code hosting platform that comes with Bitbucket Pipelines, an integrated continuous integration and delivery/deployment (CI/CD) service. AWS resource deployment and maintenance are examples of CI/CD use cases that may be carried out with Bitbucket Pipelines. It comes with an administrative feature called “Secured Variables” that lets administrators keep CI/CD secrets like AWS keys in Bitbucket itself for convenient code library access.
CI/CD pipelines: The foundation of CI/CD pipelines’ permission and authentication processes are CI/CD Secrets. They supply the login credentials needed for pipelines to communicate with AWS and other platforms, guaranteeing that pipelines have the right permissions for the jobs at hand. Because they offer a potential for direct, unrestricted access to an environment, secrets are frequently incredibly powerful and are coveted by attackers. Keeping secrets private while allowing developers to use them with ease is a never-ending battle when it comes to CI/CD pipeline security.
Bitbucket Secured Variable: It gives programmers a mechanism to save variables for easy access when developing code. Furthermore, it provides the ability to designate a variable as a “secured variable” for any sensitive data. A secured variable is created such that it cannot be viewed in plain text once an administrator sets its value. With this structure, developers may quickly access secret variables without disclosing their values to other Bitbucket users.
Exporting Bitbucket Secrets in Plain Text
CI/CD pipelines are constructed similarly to your home’s plumbing. Together, pipes, valves, and regulators give you dependable, flowing water. CI/CD pipelines are a complex series of actions orchestrated to complete a certain goal. These pipelines are extremely skilled at packaging and deploying massive amounts of data entirely on their own in order to do this.
This opens up a world of possibilities for automating labour for developers, but it can also give security professionals discomfort and heartburn. Maybe there’s a secret hardcoded into a piece of code that’s making its way into production. Perhaps a developer unintentionally saved secrets locally on their computer. Alternatively, as evidenced by recent studies, it might be a Bitbucket artefact object that has secrets for an AWS environment that is being made public to places like S3 Buckets or business websites.
Though it secured variables are a handy way for developers to store secrets locally in Bitbucket for easy access, they have one unsettling feature: through artefact objects, secrets can be revealed in plain text. The value of a Bitbucket variable, whether secured or not, will be shown in plain text in a.txt file created when the variable is copied to an artefact object using the artefacts: command.
Mandiant has observed situations where development teams employed Bitbucket artefacts in web application source code for debugging, but those teams were unaware that the artefacts included private key values in plain text. As a result, secret keys were discovered and made available to the public internet, where attackers were able to use them to obtain unauthorised access.
The pipeline determines where the secret flows and how long it takes an attacker to locate it once a secured variable, like an AWS Key, is copied to a plaintext.txt file.
Replicate of the Confidential Disclosure
The procedures to replicate the secret breach in a Bitbucket environment are as follows. A crucial note: there are other ways to export secured variables to Bitbucket artefacts; the commands covered in this tutorial only show one of them. Any references to artefact objects in their bitbucket-pipelines.yml file, or in any other file in the repository, should be carefully examined by administrators and developers.
Create Bitbucket Secured Variables
As long as the workspace and repository are configured as “secured variables,” this can be done at either level.
To create an environment artefact, update the bitbucket-pipelines.yml file
The code that follows copies all environment variables from Bitbucket to a text file named environment_variables.txt by using the printenv command. As developers must examine a large number of variables for valid development reasons, this is a standard procedure in development while troubleshooting. The code creates the.txt file and then gives it to a Bitbucket artefact object so that, if needed, it may be used by pipeline stages later on.
Go to the History of Pipeline Execution and download the artefact
Image credit to Google cloud
Explore the Artefact to Find Secured Variables
All of the variables in the Bitbucket environment can have their secrets read in plain text after the.txt file has been exported. One thing to keep in mind about this step is that you might need to do an extra step when you extract the components of a.tar file. In this case, use your preferred data extraction tool to extract the.tar file.
Secrets Proliferate The location of the pipeline
The secrets are released from it through the pipeline and become public once they are posted to the environment_variables.txt file. Any confluence of development errors, malevolent intent, or unintentional disclosure might result in a threat actor’s covert exposure and exploitation.
An excellent platform for code storage, collaboration, and deployment is Bitbucket Pipelines. Nevertheless, Bitbucket is not a specialised secrets manager, and storing secrets there increases the risk of secrets being disclosed.
Safeguard your secrets with Bitbucket Pipelines by doing the following:
Putting secrets into a special secrets manager and using those variables as references in your Bitbucket repository’s code.
Examining Bitbucket artefact objects closely to make sure secrets aren’t being exposed as plain text files.
Implementing code scanning for the duration of your pipeline’s lifecycle to find secrets encoded in code before releasing it into production.
Bitbucket has a basic pricing structure with tiers appropriate for single users, small groups, and bigger enterprises:
Cost-free:Â Perfect for lone workers and small groups (up to 5 users). It comes with 50 build minutes for Pipelines (their CI/CD tool), 1GB of storage for Large File Storage (LFS), and limitless public and private repositories.
Standard:Â $3 per user each month is the price. With extra storage and build minutes, this plan offers all the benefits of the free plan and is appropriate for companies that are expanding.
Premium:Â This package, which costs $6 per user each month, is designed for larger teams that require more comprehensive security. In addition to the capabilities of the Standard plan, it provides features like IP allowlisting, deployment permissions, enforced merge checks, and mandatory two-step authentication.
This does not constitute a criticism of Bitbucket. Rather, it’s a case study on how seemingly harmless activities can turn into major issues. There’s a precise reason why we use the word “leak”. All it takes for a gradual, seemingly untraceable drip of secrets to run through your pipeline and out into the world is one keyboard, one line of code, or one misconfiguration.
Read more on Govindhtech.com
