| Descrição | Over-privileged Lambda execution role in nxp-s32k3-plus-goldvip-telemetry allows privilege escalation and potential AWS account takeover
Affected component:SitewiseCustomFunction Lambda function execution role
Class:Improper Access Controls
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-west-1:864453966925:applications/nxp-s32k3-plus-goldvip-telemetry
Source code:https://github.com/nxp-auto-goldvip/gvip/tree/goldvip-1.4.0
Summary:
AWS Serverless Application Repository application "nxp-s32k3-plus-goldvip-telemetry" version 1.0.0 provisions a Lambda function named SitewiseCustomFunction with a highly over-privileged execution role.
The execution role grants broad permissions on Resource "*", including iam:*, lambda:*, iot:*, s3:*, iotsitewise:*, events:*, greengrass:* and sso:*. The role also grants logs:* over CloudWatch Logs resources.
If an attacker obtains code execution inside SitewiseCustomFunction, for example through a separate application-level vulnerability, dependency compromise, malicious input, exposed secret, misconfiguration, or another runtime compromise, the excessive IAM permissions can be abused to escalate privileges, move laterally, modify other serverless workloads, and potentially take over the AWS account.
Technical details:
The affected Lambda execution role violates the principle of least privilege. The inline policy attached to the role grants broad administrative-style permissions to the Lambda runtime.
The observed permission pattern includes:
- logs:* on arn:aws:logs:*:*:*
- iot:* on Resource "*"
- s3:* on Resource "*"
- iotsitewise:* on Resource "*"
- events:* on Resource "*"
- lambda:* on Resource "*"
- greengrass:* on Resource "*"
- iam:* on Resource "*"
- sso:* on Resource "*"
The affected role name may be similar to:
serverlessrepo-nxp-s32k3-p-LambdaBasicExecutionRole-<random>
The inline policy may be named similarly to:
CustomLambdaDescribePolicy
Because SitewiseCustomFunction receives iam:* and lambda:* on all resources, code running inside the function can directly alter IAM configuration, attach or create powerful policies, create or modify Lambda functions, pass roles, invoke functions, and pivot into other execution roles. This makes the function runtime a high-impact privilege escalation point.
Example attack paths:
1. Privilege escalation by modifying the existing execution role:
An attacker with code execution in SitewiseCustomFunction can use iam:AttachRolePolicy or iam:PutRolePolicy to attach a high-privilege managed or inline policy to the existing Lambda execution role. Because the role has iam:* on Resource "*", the attacker may be able to turn the current execution role into an administrator-level role. The attacker can then use the Lambda execution role credentials to perform privileged actions in the account.
2. Privilege escalation through new Lambda function creation:
An attacker can use lambda:CreateFunction together with iam:PassRole to create a new Lambda function and attach a higher-privileged IAM role available in the account. The attacker can then invoke the new function and operate under the privileges of that role.
3. Lateral movement through existing Lambda functions:
An attacker can use lambda:UpdateFunctionCode or lambda:UpdateFunctionConfiguration to modify other Lambda functions in the account. If any target function has a more privileged role, the attacker may gain access to that role's runtime environment and temporary credentials when the function is invoked.
4. Abuse of Lambda configuration and layers:
An attacker can use lambda:UpdateFunctionConfiguration to attach attacker-controlled or cross-account Lambda layers to other functions. This can be abused for lateral movement, environment variable exposure, or credential compromise when the modified functions execute.
5. Broader cloud service abuse:
Because the execution role also grants broad iot:*, s3:*, iotsitewise:*, events:*, greengrass:* and sso:* permissions on Resource "*", a compromised SitewiseCustomFunction may be able to manipulate IoT resources, S3 data, AWS IoT SiteWise assets, EventBridge rules, Greengrass resources, and IAM Identity Center related resources, depending on the account configuration.
Impact:
Successful exploitation can allow privilege escalation from SitewiseCustomFunction to administrator-level access or other high-privilege roles in the AWS account.
Potential impact includes:
- Attaching AdministratorAccess or equivalent permissions to the existing Lambda execution role
- Creating new Lambda functions with high-privilege execution roles
- Passing sensitive IAM roles to attacker-controlled functions
- Modifying existing Lambda function code
- Modifying Lambda function configuration
- Invoking other Lambda functions
- Accessing or altering IAM users, roles, policies, and trust relationships
- Accessing or modifying S3 resources
- Manipulating AWS IoT, AWS IoT SiteWise, EventBridge, Greengrass, and SSO-related resources
- Moving laterally between serverless workloads
- Exposing environment variables and temporary AWS credentials
- Disabling, weakening, or bypassing security controls
- Potential full AWS account takeover if administrator-level permissions are attached or reached
The issue significantly increases the blast radius of any current or future code execution vulnerability affecting SitewiseCustomFunction. Even if the application code itself has no known direct vulnerability, the default IAM policy makes any runtime compromise far more severe than necessary.
Steps to reproduce:
1. Deploy nxp-s32k3-plus-goldvip-telemetry version 1.0.0 from AWS Serverless Application Repository into a controlled AWS test account.
2. Open the AWS Lambda console.
3. Locate the SitewiseCustomFunction Lambda function.
4. Open the IAM execution role associated with SitewiseCustomFunction.
5. Review the inline policy attached to the execution role.
6. Confirm that the role grants iam:* with Resource "*".
7. Confirm that the role grants lambda:* with Resource "*".
8. Confirm that the role also grants broad permissions such as iot:*, s3:*, iotsitewise:*, events:*, greengrass:* and sso:* with Resource "*".
9. In a controlled test account, confirm that code running under the SitewiseCustomFunction execution role can call IAM and Lambda management APIs because of these permissions.
10. Confirm that this enables privilege escalation or lateral movement if the SitewiseCustomFunction runtime is compromised.
Recommended remediation:
- Remove iam:* on Resource "*".
- Remove lambda:* on Resource "*".
- Remove broad service wildcards such as iot:*, s3:*, iotsitewise:*, events:*, greengrass:* and sso:* unless strictly required.
- Replace wildcard permissions with tightly scoped least-privilege actions.
- Restrict IAM permissions to exact required operations and resources.
- Restrict iam:PassRole to specific role ARNs only if role passing is required.
- Add IAM conditions such as iam:PassedToService where applicable.
- Avoid granting Lambda execution roles permission to modify arbitrary IAM roles, policies, or Lambda functions.
- Review existing deployed roles created by this SAR application and update them manually if needed.
- Notify customers who deployed affected versions so they can remediate existing roles.
- Follow AWS least privilege guidance for Lambda execution roles and SAR applications.
Disclosure and vendor coordination:
This issue was reported to AWS through HackerOne AWS VDP as report #3482097. AWS handled this as part of a broader class of AWS Serverless Application Repository applications containing overly broad IAM permission patterns.
Timeline:
2025-12-30: Reported to AWS VDP as HackerOne report #3482097.
2025-12-31: HackerOne triage validated the report and changed severity from Critical to Medium.
2026-02-17: AWS marked the report as Triaged and confirmed that the concern was being addressed.
2026-03-27: AWS released SAR-side updates to block publication of applications with overly broad IAM permission patterns.
2026-04-15: AWS closed the report as Resolved.
AWS statement:
AWS stated that it investigated and resolved the 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.
References:
https://docs.aws.amazon.com/serverlessrepo/latest/devguide/using-aws-sam.html
https://docs.aws.amazon.com/serverlessrepo/latest/devguide/acknowledging-application-capabilities.html |
|---|