T05 · Unauthorized Access and Privilege Escalation
- Location
references/iam-policies.md:281- Finding
Overly Broad Wildcard Permissions for ELB and CES Resources
- Content
View full analysis
Vulnerability Details
File Location:
references/iam-policies.md, lines 281–296
Vulnerability Type: Excessive cloud permissions
Risk Level: MediumVulnerable Snippet
json ### Scenario 2: Full Monitoring with Alarm Management { "Version": "1.1", "Statement": [ { "Effect": "Allow", "Action": [ "elb:*", "ces:*" ], "Resource": ["*"] } ] }Technical Analysis
The policy recommended for “Full Monitoring with Alarm Management” grants all ELB and CES actions against all resources. This is substantially broader than the Skill’s stated monitoring purpose and the explicit read operations listed elsewhere in the project.
The wildcard actions can include resource-modifying or destructive operations unrelated to reading metrics or managing a narrowly defined set of alarms. The
"Resource": ["*"]scope further removes resource-level or project-specific restrictions.The attacker-controlled point is the Skill author’s policy guidance. The dangerous operation occurs when a user or administrator follows this guidance and attaches the policy to the identity used by the Skill. This crosses the least-privilege boundary between read-oriented ELB monitoring and unrestricted ELB/CES administration.
No evidence establishes that the author intends to abuse these privileges, so this is an excessive-permission vulnerability rather than proof of a backdoor.
Attack Path
- A user requests full monitoring or alarm-management capabilities.
- The Agent refers the user to the policy in
references/iam-policies.md. - The user or cloud administrator creates and attaches the documented policy.
- The Skill’s identity receives every ELB and CES action over every applicable resource.
- A compromised CLI, malicious follow-up instruction, or unintended command can then use those privileges to modify resources beyond the monitoring task’s authorization scope.
Impact Assessment
The affected iden ...[truncated 430 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace
elb:*andces:*with an explicit allowlist of operations required by the workflow. - Preserve the existing read-only ELB and CES permissions for monitoring.
- If alarm creation is supported, add only the exact create, update, or delete actions that the user explicitly requests.
- Separate read-only monitoring and alarm-management policies so users do not need write permissions for ordinary metric queries.
- Restrict resources by project, account, alarm, or ELB identifiers wherever Huawei Cloud IAM supports resource-level scoping.
- Document a confirmation step before any alarm or resource mutation.
- Remove the wildcard policy example to prevent it from being copied into production.
- Replace