BAC%20copy%203%403x.png)
The Oxeye research team recently found several high severity insecure direct object reference (IDOR) vulnerabilities in Harbor – a CNCF-graduated, open source artifact registry. This blog post presents how we found these vulnerabilities despite Harbor having implemented RBAC on all [.strike-word]most[.strike-word] HTTP endpoints.
The following CVE numbers are associated with the vulnerabilities mentioned above:
Managing access to operations and resources can be a challenging goal. Enter role-based access control (RBAC). It enables you to assign permissions to entities based on their role without having to manage each one individually. Permissions are assigned to roles, and roles are assigned to entities.
Using an RBAC-based approach to a project has several benefits. It simplifies creating repeatable assignments of permissions to entities and makes auditing user privileges easier with respect to tracking potential issues.
Access control enforces a policy that users cannot act outside their intended permissions. Failures typically lead to unauthorized information disclosure, modification, destruction of all data, or performing a business function outside a user's limits.
IDOR is an access control vulnerability that occurs when an application uses user-supplied input to access objects directly. With the recent change in the OWASP top 10 list, it is now considered to be the most serious web application security risk.
Implementing an RBAC-based solution to your application can highly increase security; it’s considered a good practice against IDOR vulnerabilities. The main reason is that developers have to precisely define what an endpoint can and cannot access.
Consider an HTTP endpoint responsible for retrieving user details from a database. Without RBAC, the route would need to check a current user's permissions for each action it is responsible for. This is prone to errors. A threat actor targeting that route could potentially trigger other actions targeting the user, such as altering or deleting their information.
But if the application uses RBAC, the route responsible for this action would need to declare the role with permission to retrieve user information. This renders the route unable to make any other actions regarding the user (e.g., updating or deleting), which in theory protects it from IDOR attacks.
It sounds like RBAC is an air-tight solution for IDOR vulnerabilities. But how can an attacker still find IDOR vulnerabilities in an RBAC-based application?
In our research, we sought to overcome the challenges that RBAC posed to us in finding IDOR vulnerabilities. Our primary question was, ’What factors affect the possibility of finding such vulnerabilities?’
The first reason is that large, modern code bases are prone to frequent code changes, which increases the risk of introducing a bug to the code. Take, for example, the Kubernetes GitHub repository; in the following image, you can see the sheer amount of code changes introduced in a single week:
Moreover, large applications usually have multiple maintainers who are simultaneously developing similar code areas. Enforcing the same coding style and best practices among several developers is not an easy task and are the basis for this kind of mistake. Let’s take another look at the Kubernetes GitHub repo to see the many contributors:
Testing every endpoint in the application is complicated. Modern cloud-native applications have numerous routes. Developers must test each before production to decrease the likelihood of an IDOR vulnerability. Most applications will not achieve 100% test coverage – even if they do, the possibility of every test covering all possible actions is low. For example, the Harbor project has approximately 180 route options to protect (a combination of path and HTTP method).
The Oxeye research team has found several IDOR vulnerabilities in Harbor (by VMWare). All mentioned in this blog post have been communicated to VMWare and are fixed in the latest version.
Before diving into the vulnerabilities we found, it’s essential to understand what Harbor is. From its website: “Harbor is an open source registry that secures artifacts with policies and role-based access control… Harbor, a CNCF-graduated project, delivers compliance, performance, and interoperability to help you consistently and securely manage artifacts across cloud-native compute platforms like Kubernetes and Docker.”
In other words, Harbor lets you manage your application artifacts. One of its many features is that you can centralize multiple image registries under one roof.
Harbor allows users to configure webhook policies to receive notifications about certain events in the repository, e.g., when a new artifact is pushed or when an existing one is deleted. Once a webhook policy is added, Harbor allows a user to view details of the created webhook policies.
The request structure for fetching existing webhook policy information is:
The structure contains two parameter placeholders: one for the target project ID to which the webhook policy relates and the other for the webhook policy ID. For example, the following attempts to fetch webhook ID 1415 that relates to project ID 40:
In this case, the vulnerability occurred because Harbor only attempted to validate that the requesting user has access to the project ID specified in the request. But it failed to validate that the requested webhook ID belongs to the specified project ID.
The following screenshot illustrates a low-privileged user reading the webhook policy of a project they don’t have access to, which also discloses authentication information:
P2P (peer-to-peer) preheating allows Harbor users to integrate with P2P engines such as Dragonfly or Kraken to distribute Docker images at scale.
Harbor allows users to view P2P preheat job execution logs by sending the following request:
The request structure contains four parameter placeholders: the project name, preheat policy name, execution ID, and the task ID. For example, the following request attempts to access task ID 119 of execution ID 1 in the “tst” preheat policy of the “user_project” project:
Similar to the previous IDOR, Harbor attempted to validate that the requesting user has access to the specified project. Yet it failed to validate that the job execution ID belongs to the specified project.
This next screenshot shows a low-privileged user reading the garbage collection job log:
Here the garbage collection log discloses the Docker image layer hashes. By combining this IDOR vulnerability with the “ParseThru” vulnerability discussed in our previous blog post, an attacker could read Docker image layers to which they don’t have access.
The following diagram describes the flow of chaining the IDOR vulnerability that discloses Docker layer hashes and “ParseThru:”
A handful of guideline tutorials have been written about correctly incorporating RBAC in your application. However, most lack context about how to harness the power of RBAC to prevent IDOR vulnerabilities. So what takeaways should you take from reading this post?
Every new API endpoint that your application exposes should use the strictest role available – that is, limit the role to only the required permissions without excessive ones that might be abused.
Implementing new API endpoints should be followed by a comprehensive test that simulates how a threat actor would break the suggested permission model. For example, if the application exposes an endpoint that resets a user’s password, simulate what would happen if a user would call this API endpoint from the context of a different user.
Some IDORs we discovered relied on specific request properties existing in two locations, e.g., as both query and body parameters. Access control checks were applied only on one of the parameters, while the action was based upon the other. As a result, the location of the check differed from the use location; therefore, we recommend avoiding property duplication and keeping only one parameter as the source of truth.
Role-based access control is undoubtedly a critical and important security approach when it comes to increasing your application security posture. It introduces a handful of advantages from which teams across your organization can benefit. However, implementing RBAC is not a silver bullet; following security best practices is crucial to keeping your applications safe from IDOR vulnerabilities.
Oxeye’s application security solution was built for the modern era of application development, and ensures that CVEs such as these don’t escape detection. Our solution provides contextual vulnerability reports and more accurate assessments based on runtime analysis and infrastructure configuration data. Stop guessing what vulnerabilities really matter, and focus your resources only on the ones that do. Contact us to learn more.
We would like to express our gratitude to the VM VMware Security Response and Harbor Engineering teams, specifically Wang, Stone Zhang, Chenyu Zhang, and Yang Jiao.
“The quality of the open source software we and our community develop and the commercial distributions we and our partners distribute is vital to us and to the organizations that use it. We are grateful to Oxeye and its researchers for their diligence in finding vulnerabilities and their excellent collaboration in helping us address them.” – Roger Klorese, Product Line Manager, Project Harbor, VMware.
Oxeye provides a cloud-native application security solution designed specifically for modern architectures. We enable you to quickly identify and resolve all application-layer risks as an integral part of the software development lifecycle (SDLC). Our seamless, comprehensive, and effective solution ensures touchless assessment, focuses on exploitable risks, and provides actionable remediation guidance. Built for DevOps and AppSec teams, Oxeye helps shift security left while accelerating development cycles, reducing friction, and eliminating risks. Visit www.oxeye.io to learn more.
