> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-aws-110.md). # IAM policies allow privilege escalation misconfiguration detected in code ## Rule Details | | | | ---------------------- | ----------------------------------------------------- | | Cortex AppSec Rule ID | APPSEC\_AWS\_110 | | Category - Subcategory | IAM - Overly Permissive | | Provider | AWS | | Severity | MEDIUM | | Framework | CloudFormation, Serverless, Terraform, Terraform Plan | ## Impact *IAM Permissions on Other Users* *CreateAccessKey* Creating a new user access key for a different user: An attacker with the iam:CreateAccessKey permission on other users can create an access key ID and secret access key belonging to another user in the AWS environment, if they don't already have two sets associated with them (which best practice says they shouldn't). *CreateLoginProfile* Creating a new login profile for an IAM user: An attacker with the iam:CreateLoginProfile permission on other users can create a password to use to login to the AWS console on any user that does not already have a login profile setup. *UpdateLoginProfile* Updating an existing login profile for an IAM user: An attacker with the iam:UpdateLoginProfile permission on other users can change the password used to login to the AWS console on any user that already has a login profile setup. *AddUserToGroup* Adding a user to an Admin group: An attacker with the iam:AddUserToGroup permission can use it to add themselves to an existing IAM Group in the AWS account. *Permissions on Policies* *CreateNewPolicyVersion* Creating a new policy version to define custom permissions: An attacker with the iam:CreatePolicyVersion permission can create a new version of an IAM policy that they have access to. This allows them to define their own custom permissions. *SetExistingDefaultPolicyVersion* Setting the default policy version to an existing version: An attacker with the iam:SetDefaultPolicyVersion permission may be able to escalate privileges through existing policy versions that are not currently in use. *AttachUserPolicy* Attaching a higher-privileged policy to a user that they have access to: An attacker with the iam:AttachUserPolicy permission can escalate privileges by attaching a policy to a user that they have access to, adding the permissions of that policy to the attacker. *AttachGroupPolicy* Attaching a higher-privileged policy to a group that they have access to: An attacker with the iam:AttachGroupPolicy permission can escalate privileges by attaching a policy to a group that they are a part of, adding the permissions of that policy to the attacker. *AttachRolePolicy* Attaching a higher-privileged policy to a role that they have access to: An attacker with the iam:AttachRolePolicy permission can escalate privileges by attaching a policy to a role that they have access to, adding the permissions of that policy to the attacker. *PutUserPolicy* Creating/updating an inline policy for a user: An attacker with the iam:PutUserPolicy permission can escalate privileges by creating or updating an inline policy for a user that they have access to, adding the permissions of that policy to the attacker. *PutGroupPolicy* Creating/updating an inline policy for a group: An attacker with the iam:PutGroupPolicy permission can escalate privileges by creating or updating an inline policy for a group that they are a part of, adding the permissions of that policy to the attacker. *PutRolePolicy* Creating/updating an inline policy for a role: An attacker with the iam:PutRolePolicy permission can escalate privileges by creating or updating an inline policy for a role that they have access to, adding the permissions of that policy to the attacker. *Updating an AssumeRole Policy* *UpdatingAssumeRolePolicy* Updating the AssumeRolePolicyDocument of a role: An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able to change the assume role policy document of any existing role to allow them to assume that role. *iam:PassRole* CreateEC2WithExistingIP Creating an EC2 instance with an existing instance profile: An attacker with the iam:PassRole and ec2:RunInstances permissions can create a new EC2 instance that they will have operating system access to and pass an existing EC2 instance profile/service role to it. *PassExistingRoleToNewLambdaThenInvoke* Passing a new role to a Lambda function, then invoking it: A user with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. *PassExistingRoleToNewLambdaThenTriggerWithNewDynamo* Passing a role to a new Lambda function, then triggering it with DynamoDB: A user with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping (and possibly dynamodb:PutItem and dynamodb:CreateTable) permissions, but without the lambda:InvokeFunction permission, can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. *PassExistingRoleToNewLambdaThenTriggerWithExistingDynamo* Passing a role to a new Lambda function, then triggering it with DynamoDB: A user with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping (and possibly dynamodb:PutItem and dynamodb:CreateTable) permissions, but without the lambda:InvokeFunction permission, can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. *EditExistingLambdaFunctionWithRole* Updating the code of an existing privileged Lambda function: An attacker with the lambda:UpdateFunctionCode permission could update the code in an existing Lambda function with an IAM role attached so that it would import the relevant AWS library in that programming language and use it to perform actions on behalf of that role. *PassExistingRoleToNewGlueDevEndpoint* Passing a role to a Glue Development Endpoint: An attacker with the iam:PassRole and glue:CreateDevEndpoint permissions could create a new AWS Glue development endpoint and pass an existing service role to it. *PassExistingRoleToCloudFormation* Passing a role to CloudFormation: An attacker with the iam:PassRole and cloudformation:CreateStack permissions would be able to escalate privileges by creating a CloudFormation template that will perform actions and create resources using the permissions of the role that was passed when creating a CloudFormation stack. *PassExistingRoleToNewDataPipeline* Passing a role to Data Pipeline: An attacker with the iam:PassRole, datapipeline:CreatePipeline, and datapipeline:PutPipelineDefinition permissions would be able to escalate privileges by creating a pipeline and updating it to run an arbitrary AWS CLI command or create other resources, either once or on an interval with the permissions of the role that was passed in. *Privilege Escalation using AWS Services* *UpdateExistingGlueDevEndpoint* Updating an existing Glue Dev Endpoint: An attacker with the glue:UpdateDevEndpoint permission would be able to update the associated SSH public key of an existing Glue development endpoint, to then SSH into it and have access to the permissions the attached role has access to. For more info, visit documentation.] --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-aws-110.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.