High severity vulnerabilities found in Harbor open-source artifact registry

Oxeye security researchers have uncovered several new high severity variants of the IDOR (Insecure Director Object Reference) vulnerabilities (CVE-2022-31671, CVE-2022-31666, CVE-2022-31670, CVE-2022-31669, CVE-2022-31667) in CNCF-graduated project Harbor, the popular open-source artifact registry by VMware.

Harbor is an open-source cloud native registry project that stores, signs, and scans content. It can integrate with various Docker registries to provide security features such as user management, access control, and activity auditing.

Classified as an access control vulnerability, IDOR occurs when an application uses user-supplied input to access objects directly. IDOR is a high severity threat and is considered to be the most serious web application security risk on the most current OWASP top 10 list.

Access control systems are designed to enforce policies that prevent users from acting outside of intended permissions. Access control failures typically lead to unauthorized information disclosure, modification, data deletion, or the performance of business functions outside of a user’s limits. In this research, IDOR was discovered in VMware’s Harbor, which allows users to better manage their application artifacts. Role-based access control (RBAC) in place is usually a best practice against IDOR vulnerabilities, but this research tested that theory with surprising results.

The IDOR vulnerability in Harbor leads to the disclosure of webhook policies without authorization. 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, a Harbor user may view details of the created webhook policies. In this example, the vulnerability occurred because Harbor only attempted to validate that the requesting user had access to the project ID specified in the request. But it failed to validate that the requested webhook ID belonged to the specified project ID.

Another IDOR variant leads to the disclosure of job execution logs. P2P (peer-to-peer) preheating allows Harbor users to integrate with P2P engines such as Dragonfly or Kraken to distribute Docker images at scale. By combining this IDOR vulnerability with the “ParseThru” vulnerability, an attacker may have the ability to read Docker image layers to which they lack access credentials.

“While role-based access control (RBAC) is important for maintaining a strong security position, it is not the end-all for absolute system defense against IDOR vulnerabilities,” said Ron Vider, CTO at Oxeye. “As revealed by Oxeye security researchers Gal Goldshtein and Daniel Abeles, implementing more robust practices that include setting strict roles for API endpoints, simulating threat actors to test those roles in an attempt to break permission models, and avoiding property duplication to maintain a single source of truth can ensure resiliency.”

All IDOR variants mentioned in this announcement have been communicated to the VMware Security Response and Harbor Engineering teams, who promptly collaborated towards a quick and effective resolution. All have been addressed (fixed) in the latest version of Harbor.