AWS Lambda Layer Shared Externally
This brief identifies the critical risk of an AWS Lambda layer's permission policy being modified, typically via the `AddLayerVersionPermission` API, to grant external AWS accounts, AWS Organizations, or the public access, potentially leading to the leakage of proprietary code or secrets and creating a supply-chain vector for attacker-influenced code execution in downstream functions.
This threat focuses on the malicious or accidental configuration change of an AWS Lambda layer's permission policy, detected when an entity modifies permissions to grant access to external AWS accounts, entire AWS Organizations, or even the public. The primary mechanism for this action is the AddLayerVersionPermission API call. This configuration allows other entities to utilize the code and dependencies packaged within the Lambda layer. Such external sharing, especially with the public, presents a significant risk of exposing proprietary code, sensitive data, or embedded secrets. Furthermore, it creates a potential supply-chain attack vector, where compromised or malicious layers could inject attacker-influenced code into functions that reference them, impacting their runtime integrity and leading to further compromise. While legitimate cross-account sharing can occur, public or broad external sharing warrants immediate and thorough investigation due to its severe security implications.
Attack Chain
[Omitted - The source describes a specific configuration change and its potential implications, not a multi-stage attack chain.]
Impact
Successful external sharing of an AWS Lambda layer can result in the direct exposure and leakage of an organization's proprietary code and sensitive data, including API keys, database credentials, or other secrets embedded within the layer. If exploited as a supply-chain vector, an attacker could introduce malicious code into functions referencing the compromised layer, leading to various impacts such as unauthorized data exfiltration, remote code execution (RCE) within the function's execution environment, denial of service, or further lateral movement within the cloud environment. The broadness of access granted (e.g., to the public or an entire organization) directly correlates with the potential number of impacted entities and the scope of information exposure.
Recommendation
- Deploy the provided Sigma rule to detect
AddLayerVersionPermissioncalls in your AWS CloudTrail logs, particularly those granting public or external account access. - Investigate all instances of
AddLayerVersionPermissionwhere theprincipalinaws.cloudtrail.request_parametersis*(public) or an external AWS account ID. - Validate the
layerNameand the grantedprincipalagainst approved sharing practices for your organization, as noted in thefalse_positivessection. - If unauthorized sharing is detected, immediately remove the layer permission using the
RemoveLayerVersionPermissionAPI call and rotate any secrets that may have been exposed within the layer. - Restrict the
lambda:AddLayerVersionPermissionIAM permission to a limited set of trusted roles and principals to reduce the attack surface.
Detection coverage 1
AWS Lambda Layer Shared Externally
mediumDetects the modification of an AWS Lambda layer permission policy to grant external AWS accounts, AWS Organizations, or the public the ability to use a layer version, indicating potential data leakage or supply-chain risk.
Detection queries are available on the platform. Get full rules →