Sometimes What Sounds Benign Can Bite You: An Unexpected Implication of Lambda Privileges

Ermetic [now Tenable Cloud Security] researchers recently discovered a specific combination of AWS service usage and permissions that may result in unexpected behavior. The newly unveiled combination could present underlying risk to organizations that have not been meticulous in implementing AWS's Well-Architected Framework. Organizations not in compliance with SEC01-BP01 (separate workloads using accounts) are at increased risk due to this newly discovered combination.

TL;DR

AWS Lambda is the Swiss Army knife of the AWS platform. It is used for everything from building serverless workloads to implementing event driven tasks, to customizing the default behavior of AWS services. In light of this, granting a user the unconstrained permission to update Lambda function code in an AWS account can have unexpected, possibly severe, consequences under certain conditions that might not be obvious on first pass, particularly to those with less AWS experience. Moreover, it is sometimes not entirely obvious where Lambda might be in use. For example, AWS Amplify uses Lambda under the hood to customize the authentication process of an embedded Amazon Cognito user pool that Amplify employs for user access. In a scenario such as this, granting the permission to update Lambda function code is a very powerful privilege that must be understood. 

The purpose of this blog is to educate AWS customers regarding these scenarios and how to use the combination of workload isolation and proper least privilege to avoid unknowingly introducing underlying risk into their environments.

To demonstrate the possible underlying risk, we will demonstrate abusing this granted permission to modify a provisioned Amplify environment. We chose Amplify specifically as it operates with documented Administrator-equivalent privileges due to its comprehensive nature as a client app development framework and platform.

Since our demonstration requires certain prerequisites to execute – relatively high privileges, a lack of account segregation and for the Amplify service to already be deployed – one may be inclined to think this combination poses only marginal risk. In reality, based on our observations, we have found that this particular combination did exist with some frequency within our customer base, which is why we are trying to help educate our customers and the community in general. After educating themselves, organizations should use this knowledge to help implement strict access controls and continuously monitor expected configurations. 

What is AWS Amplify?

AWS Amplify is a development platform that offers web hosting services and helps developers build and deploy full-stack applications in a cloud environment quickly and easily.

One of AWS Amplify’s main features is Amplify Studio, which behaves as the heart of the service. It is a web-based development environment that provides a visual interface for managing data, UI, storage and many functionalities in the user’s web applications on AWS.

Technical Analysis

Upon inspecting Amplify Studio settings, we infer that we are able to invite external users to our studio and manage team access.

We appear to have no users in our access control settings. Let’s go straight to trying to launch the studio from the AWS console. We access the “Storage” section which, behind the scenes, sends a request to list all our S3 buckets.

Rewinding back to the authentication mechanism

It turns out that behind the scenes, for authentication purposes, Amplify Studio has created Cognito user and identity pools, added the Amplify admin user to a “Full Access” group and attached an IAM Role “region-userpoolid-Full access” to it.

After a quick check, we see this role has a managed policy attached called “AdministratorAccess-Amplify”.

The AdministratorAccess-Amplify managed policy has many permissions, ranging from PassRole: * to sts:AssumeRole: *. In fact, AWS documentation states: “This [Amplify’s managed policy] allows permissions escalation and this policy should be considered as powerful as the AdministratorAccess policy.”

Unexpected implications of lambda:UpdateFunctionCode === Administrator

AWS Cognito has several authentication mechanisms a user can implement. One such mechanism is “Custom Authentication,” which we found AWS Amplify uses when orchestrating Cognito within the account. Using custom Lambda triggers, Amplify has configured Cognito to authenticate the user based on a one-time code challenge.

If we follow the underlying configuration a bit further, we find a sequence of Lambda functions that implement the authentication flow. 

By diving into the code, we see that token generation by the Lambda function “login-define-auth” is decided by several requirements satisfied by an internal Lambda event. The function then sets a boolean to issue access tokens for the user. In other words, this Lambda function logic controls the authentication flow to the system.

This brings us back to the original point. If another authorized user within this AWS account has excessive permissions, specifically, the ability to update the code of this Lambda function, they can alter or even nullify the authentication logic in any way they please. To demonstrate this point, simply changing the logic from “false” to “true” disables the intended OTP challenge. Should a user perform this alteration, subsequent invocations of the Amplify Studio login process will execute this new code, which could result in unauthorized access to the Amplify Studio environment for the user with lambda:UpdateFunctionCode permissions.

Conclusion

There are two key takeaways from this post. First, while it might sound benign, the variety of ways in which AWS Lambda can be used often makes the AWS permission lambda:UpdateFunctionCode a highly privileged operation. This permission should be properly restricted according to the principle of least privilege. As this is often a necessary permission for developers, pay particular attention to the resource element of your IAM policies when granting this permission and avoid overly broad scoping, such as resource: * , which would give developers both the ability to update the function code of their own functions, and any other functions that might exist within the same AWS account. Second, use AWS account boundaries to isolate teams and workloads within your overall AWS environment. For Amplify in particular, we recommend that you don’t co-mingle Amplify and non-Amplify projects within a single AWS account because the Lambda functions provisioned by Amplify govern access to documented full administrative privileges. 

In discussing our research with us, AWS agreed with this conclusion and has made account isolation for Amplify an explicit best practice.

How Tenable Cloud Security Can Help

The Tenable Cloud Security offers holistic protection for AWS, Azure and Google Cloud and helps organizations keep their cloud environment secure and compliant. The solution provides deep visibility, risk insight and remediation for complex, multicloud deployments. It enables effective management of all cloud identities to ensure identities have only the necessary permissions, including justified temporary elevated access, and recommends right-sized permissions to ensure a least-privileged environment.  Among other capabilities, the platform detects underlying risks in your environment due to excessive permissions, including those you might not fully appreciate. 

By using Tenable Cloud Security you can remove these risks before they manifest themselves – securing your environment and improving your cloud security posture overall.