Freely subscribe to our NEWSLETTER

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 identified previously by the Oxeye research team, an attacker may have the ability to read Docker image layers to which they lack access credentials.

The following IDOR CVE numbers link back to GitHub and are associated with the vulnerabilities mentioned above.
• CVE-2022-31671
• CVE-2022-31666
• CVE-2022-31670
• CVE-2022-31669
• CVE-2022-31667

“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 and Co-founder, 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. For additional information on the IDOR vulnerability in Harbor, please visit the Oxeye security blog at https://www.oxeye.io/blog/guess-whos-rbac.

“The quality of the open source software and 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