Impact Sean Wright from Secureworks has discovered an enumeration vulnerability. An attacker can make use of the Harbor API to make unauthenticated calls to the Harbor instance. Based on the HTTP status code in the response, an attacker is then able to work out which resources exist, and which do not. This would likely be accomplished by either providing a wordlist or enumerating through a sequence an unauthenticated attacker is able to enumerate resources on the system. This provides them with information such as existing projects, repositories, etc.
The vulnerability was immediately fixed by the Harbor team.
Issue The following API resources where found to be vulnerable to enumeration attacks: /api/chartrepo/{repo}/prov (POST) /api/chartrepo/{repo}/charts (GET, POST) /api/chartrepo/{repo}/charts/{name} (GET, DELETE) /api/chartrepo/{repo}/charts/{name}/{version} (GET, DELETE) /api/labels?name={name}&scope=p (GET) /api/repositories?projectid={id} (GET) /api/repositories/{reponame}/ (GET, PUT, DELETE) /api/repositories/{reponame}/tags (GET) /api/repositories/{reponame}/tags/{tag}/manifest?version={version} (GET) /api/repositories/{reponame/{tag}/labels (GET) /api/projects?projectname={name} (HEAD) /api/projects/{projectid}/summary (GET) /api/projects/{projectid}/logs (GET) /api/projects/{projectid} (GET, PUT, DELETE) /api/projects/{projectid}/metadatas (GET, POST) /api/projects/{projectid}/metadatas/{metadataname} (GET, PUT)
Known Attack Vectors Successful exploitation of this issue will lead to bad actors identifying which resources exist in Harbor without requiring authentication for the Harbor API.
Patches If your product uses the affected releases of Harbor, update to version 1.10.3 or 2.0.1 to patch this issue immediately.
https://github.com/goharbor/harbor/releases/tag/v1.10.3 https://github.com/goharbor/harbor/releases/tag/v2.0.1
Workarounds There is no known workaround
For more information If you have any questions or comments about this advisory, contact cncf-harbor-security@lists.cncf.io View our security policy at https://github.com/goharbor/harbor/security/policy
Impact Harbor fails to validate the user permissions to view Webhook policies including relevant credentials configured in different projects the user doesn’t have access to, resulting in malicious users being able to read Webhook policies of other users/projects. API call is
GET /projects/{projectnameorid}/webhook/policies/{webhookpolicyid}
By sending the below request and specifying different Webhook policy ids in the last part of the URL, the malicious user may disclose Webhook policies related to other repositories/projects.: none;">
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Harbor fails to validate the user permissions when updating p2p preheat policies. By sending a request to update a p2p preheat policy with an id that belongs to a project that the currently authenticated user doesn't have access to, the attacker could modify p2p preheat policies configured in other projects.
Impact Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call
GET /projects/{projectname}/preheat/policies/{preheatpolicyname}/executions/{executionid}/tasks/{taskid}/logs
By sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Impact Harbor fails to validate the user permissions when updating a robot account that belongs to a project that the authenticated user doesn’t have access to. API call:
PUT /robots/{robotid}
By sending a request that attempts to update a robot account, and specifying a robot account id and robot account name that belongs to a different project that the user doesn’t have access to, it was possible to revoke the robot account permissions.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Impact Harbor fails to validate the user permissions when updating tag immutability policies - API call:
PUT /projects/{projectnameorid}/immutabletagrules/{immutableruleid}
By sending a request to update a tag immutability policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag immutability policies configured in other projects.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.
Impact Harbor fails to validate the user permissions when updating tag retention policies. API call:
PUT /retentions/{id}
By sending a request to update a tag retention policy with an id that belongs to a project that the currently authenticated user doesn’t have access to, the attacker could modify tag retention policies configured in other projects.
Patches This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.
Workarounds There are no workarounds available.
For more information If you have any questions or comments about this advisory: Open an issue in the Harbor GitHub repository
Credits Thanks to Gal Goldstein and Daniel Abeles from Oxeye Security for reporting this issue.