Vulnerabilities

Identifying a BOLA Vulnerability in Harbor, a Cloud-Native Container Registry

6 min read

Executive Summary

In a recent audit of open-source web applications, threat researchers from Unit 42 have identified a broken object-level authorization (BOLA) vulnerability that impacts Harbor versions prior to 2.9.5. Harbor is a widely used cloud-native container registry that plays a role in cloud environments by hosting container images and providing features such as role-based access control (RBAC), vulnerability scanning and image signing. It is an open-source CNCF Graduated project with over 22,600 stars and 1.8 million downloads. The vulnerability we identified is tracked as CVE-2024-22278, with a CVSS score of 6.4.

We found the vulnerability as part of our development of an automated BOLA detection tool leveraging generative AI, part of a larger effort to explore how AI can enhance security capabilities.

Exploiting this vulnerability allows someone using a Maintainer role to create, update and delete a project's metadata. These are privileged actions that are forbidden in the Harbor UI and prohibited according to the official documentation. Unauthorized alterations to metadata pose significant risks, including data exposure, compromise of content integrity and circumvention of vulnerability scanning mechanisms.

To mitigate these risks, organizations should update Harbor to version v2.9.5, v2.10.3 or v2.11.0 immediately. This update addresses the identified vulnerability and helps secure the application against potential attacks. Harbor has published more information in their advisory on the issue.

Customers are also better protected through our Next-Generation Firewall with Cloud-Delivered Security Services, including Advanced URL Filtering.

Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all publicly exposed Harbor instances through a targeted attack surface rule.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics	API Attacks, BOLA

BOLA Vulnerabilities

BOLA, also known as insecure direct object references (IDOR), are a prevalent type of vulnerability in modern APIs and web applications. BOLA vulnerabilities are ranked as the number one risk in the OWASP API top 10 and the fourth most reported vulnerability type in the HackerOne Global Top 10.

As explained in our previous research on BOLA, BOLA occurs when an application fails to properly check if a user has the necessary permissions to access, modify or delete an object. The "object" in the BOLA acronym refers to various types of data within a system. These objects include messages, photos, trips, user profiles and invoices.

Attackers can exploit BOLA vulnerabilities in API endpoints by altering object identifiers within authentication requests. Such manipulations can lead to unauthorized access of user data, resulting in data leaks, data manipulation or even complete account takeovers.

As discussed in another article disclosing BOLA vulnerabilities, testing for BOLA is typically done manually. In our research using AI to automate detection, we’ve found and responsibly disclosed BOLA vulnerabilities in several open-source projects.

Overview of Harbor

Harbor is a popular container registry that uses policies and role-based access control (RBAC) to manage and secure container images. User actions are determined by assigned roles, and only an administrative role can perform critical actions such as project configurations and vulnerability scanning.

A project in Harbor contains a collection of repositories, where each repository can hold multiple versions of container images. To enforce access control, Harbor applies RBAC to its projects, so that only users with the appropriate roles can perform certain operations.

When considering project access, we must first understand the two types of projects as defined by Harbor:

Public: In this type of project, any user can pull images to share repositories with other users.
Private: In this type of project, only users who are members of the project can pull images.

For individual projects, Harbor defines five project-level roles with distinct permissions. Each role is tailored to facilitate specific aspects of the project.

Limited Guest: This role can pull images but not push, it cannot see logs or other project members.
Guest: This role is read-only access, it can pull and retag images but not push.
Developer: This role is read and write access within a project.
Maintainer: This role has elevated permissions, including the ability to scan images, view replication jobs, and delete images and helm charts.
ProjectAdmin: This role has full read-write and management privileges, such as adding or removing members and initiating vulnerability scans.

Explanation of Harbor Vulnerability, CVE-2024-22278

This BOLA in Harbor is based on a project's metadata.

In Harbor's source code, this metadata refers to specific information and settings associated with a project. These settings control crucial configurations of a project, such as making a project private or public, allowing only verified images to be deployed and enforcing vulnerability scanning on pushed images.

According to Harbor's documentation, only the ProjectAdmin role is permitted to modify these configuration settings.

We tested this in Harbor to confirm, but upon assessing the Harbor APIs, we observed inconsistent behavior between the Harbor web UI and APIs.

We first confirmed that a user with a Maintainer role cannot create, update or delete a project's configuration metadata through the web UI. Figure 1 shows the Harbor UI console from a Maintenance login. Note the five checkable boxes in Figure 1 are all gray. Even if a user checks or unchecks these boxes, these settings will not change.

The image shows a section of a software interface labeled "Project registry" with several settings. These settings are contained within checkboxes and dropdown menus. The settings include options to make a project registry public, configure deployment security, prevent vulnerable images from running, and automatically scan images on push. Additional details include dropdown menus indicating the severity of vulnerabilities that can prevent deployment (with "Low" visible). All text and settings are presented in a clean, digital format typical of software configuration interfaces. — Figure 1. For a Maintenance login, configuration checkboxes in the Harbor UI console are all gray.

Figure 2 shows the same configuration settings in the Harbor UI console with a ProjectAdmin role login. In this case, the checkable boxes are not gray, which provides a visual indication that these settings can be changed.

The image shows a user interface for a project registry configuration page with various settings options. It includes toggles and checkboxes with labels such as "Project registry," "Deployment security," and "Vulnerability scanning." The "Project registry" is set to "Public," "Deployment security" has "Only signed images" selected, and "Vulnerability scanning" is set to "Automatically scan images on push." The background is a standard GUI with a blue header, white main area, and black text. There are no images or animations, just plain text and interactive elements. — Figure 2. For a ProjectAdmin login, configuration checkboxes in the Harbor UI console are not gray, so these settings can be changed.

However, when checking the Maintainer role using Harbor's API, we noticed that our Maintainer role could alter a project's metadata using valid {meta_name} values as specified in the source code. These requests were:

PUT /projects/{project_name_or_id}/metadatas/{meta_name}
POST /projects/{project_name_or_id}/metadatas/{meta_name}
DELETE /projects/{project_name_or_id}/metadatas/{meta_name}

We confirmed the above requests using a Maintainer role though the API could indeed alter a project's metadata. These are functions that should only be done in a ProjectAdmin role.

This vulnerability allows a user with a Maintainer role to perform the tasks that only a ProjectAdmin should be able to do.

Vulnerability Impact

Although a Maintainer role has high privileges and can potentially harm the project in various ways if acting maliciously, this BOLA vulnerability extends those Maintainer role privileges even further. This allows the Maintainer to make a project public, deploy unverified images and bypass mandatory vulnerability scanning protocols.

If an attacker gains access to a Harbor system through a Maintainer role, this BOLA allows the attacker to make ProjectAdmin changes. These changes could include deploying vulnerable or malicious images, exposing sensitive project data and further compromising the project's integrity and security posture.

Figure 3 shows us using Postman for an API call to change a private project to public. We did this from an account with Maintenance-level access. We confirmed this API call from a maintenance account did in fact change a project's permissions from private to public.

A screenshot of an API request in a software interface, showing a PUT request to "http://localhost/api/v2.0/projects/5/metadata/public" with JSON body content set to {"public":"true"}. The screen displays various tabs such as Params, Auth, Headers, Body, and Pre-req, with the Body tab active and displaying the JSON data. — Figure 3. Making a project public by modifying its metadata using an API through Postman from a Maintenance account.

This issue qualifies as a BOLA vulnerability because it permits unauthorized manipulation of specific objects, such as project metadata configurations, due to inadequate enforcement of object-level authorization checks in the application.

Fixes and Mitigations

Harbor has released a fix to CVE-2024-22278 and suggested users upgrade to version v2.9.5, v2.10.3 or v2.11.0 to mitigate the BOLA risk.

Disclosure Process

April 24, 2024: We reported the vulnerability to Harbor’s maintainers through email
May 6, 2024: Harbor’s maintainer confirmed the vulnerability
July 02, 2024: CVE-2024-22278 has been reserved
July 31, 2024: Harbor released versions v2.9.5, v2.10.3 and v2.11.0 that all patched the vulnerability

Conclusion

This post details a BOLA vulnerability Unit 42 researchers discovered in Harbor using a new automatic methodology that leverages AI. As API use increases exponentially, so does the prevalence of API vulnerabilities and BOLA vulnerabilities in particular. Due to the ease of exploitation and potential impacts of this vulnerability, we encourage affected organizations to update to the patched version as soon as possible.

Researchers at Palo Alto Networks are actively developing new technology that leverages AI to automate the detection of BOLA vulnerabilities. Although this initiative is still in its early stages, we’re making significant progress toward creating more scalable, efficient and effective detection solutions.

To mitigate the risks related to this vulnerability, organizations should update Harbor to version v2.9.5, v2.10.3 or v2.11.0 immediately. This update addresses the identified vulnerability and helps secure the application against potential attacks.

Customers are also better protected through our Next-Generation Firewall with Cloud-Delivered Security Services. For example, Advanced URL Filtering can categorize requests to probe for this vulnerability as scanning activity.

Cortex Xpanse and Cortex XSIAM customers with the ASM module are able to detect all publicly exposed Harbor instances through a targeted attack surface rule.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.