Exposing Secrets Via SDLC Tools: The Artifactory Case

Development secrets are any data sensitive to an organization or person and should not be exposed publicly. It can be a password, an access key, an API token, a credit card number, and more. You can read more about the dangers of secrets getting exposed via your source code management (SCM) systems here. But hard-coded secrets in the code are not the only services from which secrets can get leaked. Essentially, any service you’re using as part of your software development lifecycle (SDLC) in which data or code is stored may be the source of secrets exposure. Legit Security’s Research Team investigated how sensitive information can get exposed via SDLC tools that you may use as part of your development pipeline, and in this blog post, we will demonstrate the Artifactory study case.

When your secured artifact storage leaks your secrets

Jfrog Artifactory is a binary repository manager used for versioning and storing artifacts, such as Java jar files, Docker images, iso, npm packages, etc. It helps manage the development pipeline by providing centralized storage for all artifacts, improving traceability and security. Artifactory is a bridge between developers and DevOps teams, providing a unified platform for managing binary artifacts throughout the software development lifecycle. It supports multiple repository formats such as Docker, Maven, Gradle,  npm, etc., making it a one-stop solution for all binary management needs. Artifactory also offers integration with popular CI/CD tools like Jenkins, Bamboo, and TeamCity, making automating the artifact deployment process easier.

Even though it is a security tool, things can derail, and when misconfigured, it can lead to a software supply chain attack. Publicly exposed Artifactory instances that don’t restrict anonymous access are insecure because they allow anyone with an internet connection to access sensitive data, and proprietary software artifacts can be easily downloaded, manipulated, or misused. This could potentially lead to several security risks, such as data breaches, code theft, and, most notably - leaked secrets in artifacts, eventually leading to a supply chain attack on the organization.

Additionally, anonymous access can result in unauthorized modifications to the repository, potentially leading to security vulnerabilities. Moreover, with anonymous access, it becomes challenging to track and monitor who is accessing the repository and for what purpose. This can make it difficult to troubleshoot problems or detect potential security breaches.

It’s important to note that we think Jfrog Artifactory is a great tool. We have no problem with Artifactory itself. The problem is with the way it is being set up, and our goal is to help its users understand the risk of doing it wrong.

Scanning public Artifactory instances

The Legit Security Research Team recently looked at public Artifactory instances using tools that allow users to find specific types of internet-connected devices and systems.

Firstly we extract a list of IPs of Artifactory instances. Given this list, we request Artifactory API to retrieve the version and verify that these are actual Artifactory instances. On these servers, we used the repositories API to identify whether binary repositories exist within them from which data can be extracted. This could potentially allow an attacker to extract sensitive information, such as private code and other confidential data, from the organization. Given an old version of Artifactory, it might be vulnerable, and exposing it publicly makes it exponentially riskier, e.g.   NVD - CVE-2022-0668- a critical vulnerability exploitable for external users, allowing authentication bypass, that was discovered earlier this year. 

Our investigation revealed that out of over 1500 public Artifactory instances in the wild, 457 allowed anonymous access to their artifacts, and ~50 out of them exposed no data (possibly not storing any artifact, or providing limited access for anonymous users). ~70 out of the 457 allowed write access to anonymous users - meaning anonymous users could potentially deploy malicious artifacts to their organization’s production.

Since the get version API is limited to servers that allow anonymous access, we could track the version only from them. 320 of the 457 (70%) Artifactory servers had an old version, exposing them to the aforementioned authentication bypass vulnerability. We believe that since such a high percentage of servers are outdated, there will be a significant amount of outdated servers that are well-configured and prevent anonymous access. Based on these numbers, we estimate there are around 1000 publicly exposed servers with an old version allowing a potential attack to gather their private information as well.

For each Artifactory server, we scanned their artifacts for secrets. Using a secret scanner on the raw binaries won’t give much since most artifacts are packed in a non-textual format. So we unpacked every compressed/archived format recursively (e.g., extracting all zip files in a tar file found in a docker container) and then scanned the extracted files for secrets using Legit’s secret scanner. The graphs below represent all the high-level data of the Artifactory servers:

The graph below shows the distribution of the secrets we defined on Artifactory servers:

The graph reveals multiple types of secrets, e.g., API tokens, keys, AWS tokens, and sensitive information belonging to customers/employees. We have conducted a responsible disclosure process with the organizations that were found to be exposing sensitive information - mostly without their awareness.

The distribution of secrets shows the vast majority are generic API keys (allowing access to services such as internal assets used in the development process or production environment). Given an artifact, an attacker can understand the usage of these API keys, allowing them to extract more data or even manipulate it. It’s worth noting that there were also a high number of keys - PKCS, PGP, RSA, and SSH - all can connect to remote servers and possibly allow further exploitation and lateral movement.

As a strategy, we were also looking for git repositories hiding inside artifacts. When initialized git repositories (containing .git directory, which includes the entire git history) pertaining to an organization’s private code mistakenly end up in an artifact, it can easily get leaked. Scanning the exposed artifacts, we found 37 git repositories. When encountering git repositories, it is important to understand that git history tracks everything. If a secret was pushed and there was no direct history removal, the secret will appear in the repository's history, making it accessible even when the secret is currently not in the code due to a push deleting it.

A substantial amount of AWS access tokens was also found, which, in most occurrences, allow access to an organization’s cloud assets (e.g. S3 bucket) and extraction of more confidential information. Many Slack tokens were also found, which can be extremely dangerous - accessing private slack channels can leak additional private data. Other secrets detected include Alibaba access key id, Google API key, Stripe, GCP service account, Ionic API token, and more.

Risks and How To Mitigate Them

Risks

There were multiple risks we addressed in this article:

1. Having the Artifactory server publicly accessible. It allows malicious actors to find a lead for attacking your organization, and when misconfigured - it can be extremely easy to attack your organization. Public access to Artifactory may cause public access to the private artifacts, using social engineering for credentials theft, enumerating popular passwords, and even attacking the server if it’s not updated/using a 0-day attack.

2. Having anonymous access to your artifacts given a network connection by: 

   1. Configuring anonymous access to Artifactory, which includes the organization's artifacts.

   2. Using an old version of Artifactory, vulnerable to critical CVE, allowing an anonymous user to retrieve/deploy artifacts.

   3. Anonymous access may enable attackers to hide their identity and activity, making it more difficult for organizations to detect and respond to attacks.

3. Artifacts data security - your artifacts can expose sensitive information:

   1. Code theft - in case you accidentally deployed private code to that public server

   2. Secrets in artifacts - artifacts can contain a variety of files, which can contain organizational secrets

   3. In 70 cases, there were write permissions for an anonymous user, making it possible to deploy as an anonymous user - which allows a CodeCov-like attack.

Given 1+2+3, an attack is extremely easy, accessing the private artifacts and using lateral movement for a complete supply chain attack.

Risks

To mitigate these risks, it is recommended:

1. Restrict access to the Artifactory instance - Artifactory servers having private artifacts should generally not be public. Generally speaking, public and private components should be separated, so when using private artifacts, every instance having access to it should most likely be on a private network.

2. Use appropriate authentication and authorization mechanisms. Anonymous access to private organization artifacts is highly discouraged. It is important for organizations to carefully consider the security implications of anonymous access to these types of tools and to put appropriate safeguards in place to protect against potential attacks. This may include implementing strong authentication and access controls, monitoring suspicious activity, and regularly updating and patching systems to fix vulnerabilities.

3. Scan artifacts for secrets. When a secret is found, understand which part of the build process got it there and modify it so that it won’t appear as plain text in the artifact. Store secrets on encrypted storage with specified authorization.

Conclusion

To sum up, misconfigurations in an SDLC service, such as an exposed Artifactory server allowing anonymous public access, make your organization vulnerable to multiple threats, including artifacts theft, which eventually can result in secrets getting leaked. Secret theft can cause severe implications, including access to customers’ private data, access to critical production services, and supply chain attacks. It’s essential to keep your SDLC assets safe and your artifacts free from hardcoded secrets.

The Legit Security Platform provides advanced secret detection capabilities that will help you prevent exposing sensitive information in your entire software supply chain, in addition to a wide range of additional security capabilities and benefits, such as alerting you about risky misconfigurations of SDLC systems and infrastructure across your pre-production development environment. To learn more, feel free to contact us!