Researchers have found thousands of publicly exposed and misconfigured container registries and artifact repositories belonging to businesses that could give attackers access to access tokens, encryption keys, and other sensitive information about internal systems. This information can allow attackers to plan and execute attacks against production and development systems, and in some cases even inject malicious code into repositories.
“In many cases artifact management systems and container registries are connected to the internet deliberately and by design allowing anonymous users to connect to various areas in the registry or even to the entire registry,” researchers from cloud security firm Aqua Security said in a report. “This design allows global teams, customers, and other stakeholders access to open-source software that is shared across the company or with outside users. In some cases, however, restricted environments are accidentally shared with anonymous users; in other cases teams accidentally publish sensitive information to public areas.”
The Aqua research team set out to investigate this attack surface by scanning the internet for registries left accessible from the internet by companies of all sizes and then investigated each one for misconfigurations, vulnerabilities, and sensitive data exposure. The registries they found held over 250 million artifacts and over 65,000 container images.
A registry is a central server for hosting software packages. These can be container images that include pre-packaged and pre-configured applications or artifacts — binary files that are used during application building or deployment. Both container images and artifacts can contain sensitive information inside their configuration files and code, including access tokens, authentication keys, database passwords, internal IP addresses, and filesystem paths to additional servers and assets such as databases.
The Aqua team found more than 10,000 privately owned container registries and over 7,000 artifact repositories accessible from the internet. This included registries set up with Quay.io, a container building and deployment tool, and artifact repositories set up with Sonatype Nexus and JFrog. Over 2,800 of the publicly accessible registries and around 4,000 artifact repositories were configured for anonymous access.
This isn’t necessarily a security issue if that access is intended and limited to non-sensitive assets, but that wasn’t the case for a significant number of them. The researchers were able to identify exposed credentials in over 4,000 of them, and 156 hosts included sensitive information about storage systems — Redis, MongoDB, PostgreSQL, MySQL, etc. — that could allow attackers to plan lateral movement activities in the environment.
Around 2,100 artifact repositories were configured with upload permissions for anonymous access, which could allow attackers to upload artifacts with malicious code that could then be consumed by development processes. A further 57 registries had default admin passwords.
“We found small, medium, and large organizations from all over the world, including ten companies from the Fortune 500 list,” the researchers said. “Only the registries of five Fortune 500 companies contained highly sensitive information and in some cases wasn’t supposed to be exposed or allow anonymous access. Additionally, we found two leading cybersecurity companies had exposed secrets in their registries, and a significant number of smaller companies had similar issues that put them at risk.”
Shadow IT is a common reason for registry exposure
Since Aqua found such exposures at large enterprises that have big security teams and even at security companies, it’s fair to assume that smaller organizations without nearly the same level of security expertise in house are even more likely to misconfigure their registries. In many cases the exposure is the result of shadow IT — developers or infrastructure engineers making configuration decisions and changes to make their job easier without fully understanding the risks.
For example, Aqua found two misconfigured container image registries operated by the development and engineering teams of a Fortune 100 tech giant. One of the container images found inside had a manifest file used for the building process that included a command to download artifacts from an artifact registry, along with an API key to access the artifact registry.
It turned out the API key had “can deploy” privileges, which could have allowed an attacker to poison artifacts. The artifact repository contained over 240 million artifacts used in the production environment, as well as internal software libraries.
“The tech giant’s security team was very professional and eager to learn about our findings,” the Aqua researchers said. “They promptly investigated the items in our report and took immediate measures to mitigate the risks. We later learned that this was a case of shadow IT, where a developer with a side project opened an environment against policy and regulations without proper controls.”
Three separate mistakes were made in this case. All chained together for an exposure that could have enabled a software supply-chain attack leaving the registry open to anonymous access, including an API key in a manifest file and giving the API key more privileges than needed — failure to apply the least privilege principle.
In another case, a tech startup had its artifact registry accessible to an anonymous user with privileges that allowed the user to view the build section and read environment variables. The environment variables contained sensitive credentials used by the build process, such as admin credentials for the artifact registry itself, as well as AWS credentials to access the production environment, the company’s source code management system and CI environment. When alerted, the startup’s CTO confirmed to Aqua that the powerful AWS credentials giving access into so many sensitive systems were the result of shadow IT.
A public container image registry belonging to a healthcare organization was found to contain a lot of keys and secrets that provided complete access to websites, databases, staging environments, its Stripe payment gateway account, and source code. This level of exposure would have given attackers almost complete control over the company’s cloud infrastructure and potentially exposed personal healthcare information of users.
At the other end of the spectrum, sometimes configurations are intentional, but organizations don’t account for all the risks. In a case involving a different tech giant, an artifact repository that the company intended to be publicly accessible contained a package that exposed an access token. After an internal discussion, the company’s security team assessed the token was not sensitive and was meant to be public, but stricter access controls and policies were put in place to ensure the periodic rotation of tokens.
However, the risks that stem from a public artifact repository are not limited to direct exposure of access tokens and keys. Mere knowledge of internal npm or Python package names can give attackers enough information to launch dependency confusion attacks in the absence of additional security measures.
How to mitigate internet-exposed registries
Organizations should immediately check if their registries are exposed to the internet unintentionally and limit access to them. If public access is intentional, they must ensure that the registry software is running a version that doesn’t have any publicly known vulnerabilities, that the default admin password is disabled or charged, and that all accounts have strong passwords. If the anonymous account is enabled intentionally then organizations must ensure that no container images or artifacts in the repository contain any access tokens or other sensitive information. If any secrets have been exposed, they need to be changed immediately.
The Aqua researchers make the following recommendations:
- Secure the repositories with network controls such as a VPN or firewall. This can help to protect the repositories from external threats and reduce the risk of unauthorized access.
- Implement strong authentication and authorization measures. This includes using strong passwords, two-factor authentication, SSO and replacing default passwords.
- Regularly rotate keys, credentials, and secrets. This includes periodically changing passwords, access keys, and other forms of authentication and authorization to prevent unauthorized access.
- Implement least privilege access controls and scoping, assigning the appropriate level of access to different roles especially for anonymous access and restricting access to specific repositories and artifacts as needed.
- Regularly scan for sensitive data. This includes scanning artifact and container registries for known vulnerabilities and secrets and conducting regular security assessments in the repositories. It’s important to promptly address and mitigate any vulnerabilities and rotate any exposed secrets to prevent exploitation by attackers.
Copyright © 2023 IDG Communications, Inc.
