提交 #866021: 3CORESec Trapdoor 1.2.2 Improper Access Controls

Title:
Overly permissive IAM role in Trapdoor allows privilege escalation in AWS accounts

Affected component:
DefaultFunction Lambda function execution role

Source code:
https://github.com/3CORESec/Trapdoor

AWS Serverless Application Repository application:
https://us-east-1.console.aws.amazon.com/lambda/home?region=us-east-1#/create/app?applicationId=arn:aws:serverlessrepo:eu-central-1:756157594214:applications/Trapdoor

Summary:
The AWS Serverless Application Repository application "Trapdoor" version 1.2.2 creates an overly permissive Lambda execution role for the DefaultFunction function.

The execution role grants iam:PassRole on Resource "*" and broad Lambda permissions on Resource "*". These permissions include sensitive Lambda management actions such as creating functions, updating function code, updating function configuration, invoking functions, and managing Lambda layer permissions.

If an attacker obtains code execution in the affected Lambda function, for example through a separate application-level vulnerability, dependency compromise, exposed secret, misconfiguration, or another runtime compromise, the excessive IAM permissions can be abused to escalate privileges or move laterally inside the victim AWS account.

Technical details:
The affected Lambda execution role violates the principle of least privilege. In particular, the role allows broad use of Lambda management APIs and allows iam:PassRole against arbitrary resources.

Affected function:
- DefaultFunction

The dangerous permission pattern includes:
- iam:PassRole with Resource "*"
- Broad lambda permissions with Resource "*"
- Permissions equivalent to lambda:CreateFunction
- Permissions equivalent to lambda:UpdateFunctionCode
- Permissions equivalent to lambda:UpdateFunctionConfiguration
- Permissions equivalent to lambda:InvokeFunction
- Permissions equivalent to lambda:AddLayerVersionPermission

This permission model allows a compromised DefaultFunction runtime to perform actions that should not normally be available to an application Lambda execution role.

Example attack paths:
1. Privilege escalation through function creation and role passing:
An attacker with code execution in DefaultFunction can use lambda:CreateFunction together with iam:PassRole to create a new Lambda function and attach a more privileged IAM role available in the account. The attacker can then invoke the new function and operate under the higher-privileged role.

2. Lateral movement through function code modification:
An attacker can use lambda:UpdateFunctionCode to modify other Lambda functions in the same account. By invoking the modified functions, the attacker may obtain access to other execution environments, environment variables, and temporary role credentials.

3. Configuration abuse through Lambda layers:
An attacker can use lambda:UpdateFunctionConfiguration to attach a malicious or attacker-controlled Lambda layer to other functions. This may allow credential exposure, environment variable disclosure, or further lateral movement when those functions are invoked.

Impact:
Successful exploitation can allow privilege escalation from the affected Lambda execution role to more privileged IAM roles in the AWS account, depending on the roles and resources available in the victim environment.

Potential impact includes:
- Creation of attacker-controlled Lambda functions
- Passing sensitive or high-privilege IAM roles to new functions
- Modification of existing Lambda function code
- Modification of Lambda function configuration
- Invocation of other Lambda functions
- Exposure of environment variables and temporary AWS credentials
- Lateral movement between serverless workloads
- Possible full AWS account compromise if a high-privilege role can be passed or reached

The issue significantly increases the blast radius of any code execution vulnerability or runtime compromise affecting DefaultFunction.

Steps to reproduce:
1. Deploy Trapdoor version 1.2.2 from AWS Serverless Application Repository into a test AWS account.
2. Open the AWS Lambda console.
3. Locate the DefaultFunction Lambda function.
4. Open the IAM execution role associated with DefaultFunction.
5. Review the policies attached to the execution role.
6. Confirm that the role grants iam:PassRole with Resource "*".
7. Confirm that the role grants broad Lambda permissions with Resource "*".
8. In a controlled test account, confirm that code running under the DefaultFunction execution role can use Lambda management APIs and pass roles because of these permissions.
9. Confirm that this allows privilege escalation or lateral movement if the DefaultFunction runtime is compromised.

Recommended remediation:
- Remove iam:PassRole on Resource "*".
- Restrict iam:PassRole to only the exact IAM role ARNs required by the application.
- Remove broad lambda permissions on Resource "*".
- Scope Lambda permissions to the minimum required actions and resources.
- Avoid granting application Lambda execution roles permissions to create, update, or modify arbitrary functions unless strictly required.
- Add IAM conditions such as iam:PassedToService where applicable.
- Follow AWS least privilege guidance for Lambda execution roles.
- Review existing deployments and update affected IAM roles.

Disclosure and vendor coordination:
This issue was originally reported to AWS through HackerOne AWS VDP as part of report #3481158. The affected third-party application publisher was also contacted separately, but no direct response was received from the publisher at the time of submission.

Timeline:
2025-12-29:
The issue was submitted to AWS VDP. The report described overly permissive IAM roles in AWS Serverless Application Repository applications, including Trapdoor version 1.2.2.

2025-12-30:
HackerOne triage validated the report and changed the severity from Critical to High. The triage note stated that the issue had practical security impact, while noting that users could review IAM permissions during SAR deployment.

2025-12-30:
AWS initially closed the report as Informative, stating that the issue was considered part of the customer side of the AWS Shared Responsibility Model rather than a vulnerability in AWS products or services.

2025-12-31:
The reporter responded to AWS and explained that, although customers are responsible for IAM policies in their own accounts, the risky roles were created by applications distributed through AWS Serverless Application Repository. The reporter also noted that customers may reasonably trust templates surfaced through an AWS-managed channel, and that SAR applications granting iam:PassRole on "*" and broad lambda permissions on "*" should trigger stronger warnings, guardrails, or review.

2026-01-20:
AWS reopened the report.

2026-02-17:
AWS changed the report status to Triaged. AWS stated that the report had been validated and that AWS was addressing the concern.

2026-03-27:
AWS released updates that block publication of AWS Serverless Application Repository applications containing overly broad IAM permission patterns.

2026-04-15:
AWS closed the report as Resolved and awarded positive reputation points.

AWS public statement:
AWS provided the following statement for publication:

"AWS investigated and resolved all reported concerns.
On March 27, 2026, AWS released updates that block publication of AWS Serverless Application Repository applications containing overly broad IAM permission patterns. AWS also notified affected application publishers and customers who deployed these applications with remediation guidance. No customer action is required for new deployments. Updated guidance is available in the AWS Serverless Application Repository documentation [1][2].

[1] https://docs.aws.amazon.com/serverlessrepo/latest/devguide/using-aws-sam.html
[2] https://docs.aws.amazon.com/serverlessrepo/latest/devguide/acknowledging-application-capabilities.html

We appreciate the security research community for reporting this issue and collaborating with AWS."

Notes:
This entry concerns the 3CORESec SAR application Trapdoor version 1.2.2. The same overly broad IAM permission pattern was also observed in other AWS Serverless Application Repository applications and was handled by AWS as a broader SAR publication-control issue.

• 来源: ⚠️ https://github.com/3CORESec/Trapdoor
• 用户: changli (UID 99220)
• 提交: 2026-06-23 08時01分 (2 月前)
• 管理: 2026-08-08 20時51分 (2 months later)
• 状态: 已接受
• VulDB条目: 387212 [3CORESec Trapdoor 直到 1.2.2 DefaultFunction 权限提升]
• 积分: 20