T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- README.md:56
- Finding
- Overly Broad Account-Wide AWS Permissions## Vulnerability Details **File Location**: `README.md`, lines 56-72 **Vulnerability Type**: Excessive cloud permissions and violation of least privilege **Risk Level**: High **Vulnerable Code Snippet**: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "s3:*", "lambda:*", "cloudwatch:*", "logs:*" ], "Resource": "*" } ] } ``` ### Technical Analysis The documented IAM policy grants every available action for EC2, S3, Lambda, CloudWatch, and CloudWatch Logs against all applicable resources. It does not limit access by action, resource ARN, region, account, resource tag, network origin, or other IAM conditions. These permissions exceed the needs of many advertised operations. For example, listing resources does not require deletion privileges, while routine monitoring does not require unrestricted control over log groups and alarms. The policy also combines read-only and destructive capabilities in one role. If users adopt this policy, any process operating with their AWS credentials could terminate instances, delete S3 objects or buckets where AWS permits it, replace Lambda code, modify monitoring, or delete forensic logs. The repository contains no implementation that would enforce confirmations, resource allowlists, or other safeguards around these operations. ### Attack Path 1. A user follows the README and attaches the documented policy to an IAM identity or role. 2. The user exposes those credentials to the advertised toolkit, an unintended package, a compromised dependency, or another process in the same environment. 3. The compromised process uses the wildcard permissions to enumerate account resources. 4. It performs destructive or unauthorized operations such as terminating EC2 instances, replacing Lambda function code, deleting S3 data, disabling alarms, or deleting l ...[truncated 734 chars]
- Remediation
- ## Remediation Suggestions - Replace wildcard service actions with an explicit list of operations required by each feature. - Publish separate read-only, deployment, and destructive-operation policies. - Restrict permissions to designated resource ARNs wherever AWS supports resource-level authorization. - Add IAM conditions for approved regions, accounts, resource tags, and request contexts. - Use short-lived credentials obtained through IAM roles or AWS IAM Identity Center instead of long-lived access keys. - Apply permission boundaries and organization-level service control policies as defense in depth. - Require explicit user confirmation and clear resource identification before termination, deletion, or code replacement. - Prevent operational roles from deleting or weakening audit logs unless that capability is strictly necessary. - Document the minimum permissions required by each individual command.