CVE-2023-22463
KubePi's Hardcoded Jwtsigkeys allows malicious actor to login with a forged JWT token
In short
KubePi uses the same hardcoded secret key to sign login tokens (JWT) in all installations, allowing anyone to forge admin login tokens and take over Kubernetes clusters. This is critical because attackers can impersonate administrators without knowing any passwords.
Technical detail
CWE-798: Hardcoded JwtSigKey in session.go enables arbitrary JWT token forgery. An unauthenticated attacker can craft valid authentication tokens for any project, bypassing authentication entirely and gaining admin privileges to compromise the underlying Kubernetes cluster.
Summary generated and translated by AI from the official description.
KubePi is a k8s panel. The jwt authentication function of KubePi through version 1.6.2 uses hard-coded Jwtsigkeys, resulting in the same Jwtsigkeys for all online projects. This means that an attacker can forge any jwt token to take over the administrator account of any online project. Furthermore, they may use the administrator to take over the k8s cluster of the target enterprise. `session.go`, the use of hard-coded JwtSigKey, allows an attacker to use this value to forge jwt tokens arbitrarily. The JwtSigKey is confidential and should not be hard-coded in the code. The vulnerability has been fixed in 1.6.3. In the patch, JWT key is specified in app.yml. If the user leaves it blank, a random key will be used. There are no workarounds aside from upgrading.
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected products
KubeOperator · KubePiWant to know if your infrastructure is exposed to this?
Talk to TrueHacking →References
https://github.com/KubeOperator/KubePi/blob/da784f5532ea2495b92708cacb32703bff3a45a3/internal/api/v1/session/session.go#L35https://github.com/KubeOperator/KubePi/commit/3be58b8df5bc05d2343c30371dd5fcf6a9fbbf8bhttps://github.com/KubeOperator/KubePi/releases/tag/v1.6.3https://github.com/KubeOperator/KubePi/security/advisories/GHSA-vjhf-8vqx-vqpq