Blog

Understanding Your AWS Lambda Security: Privilege Escalation Risk

Table of Contents

Understanding Your AWS Lambda Privilege Escalation Risk

AWS Lambda is an extremely useful and powerful service that allows you to run code in your AWS environment without having to worry about the underlying infrastructure as well as the operational overhead. All you need to do is upload your code, or create it in the native console, set the trigger, and away you go. While this helps greatly with automation, response to specific events, and using custom logic, it can present a significant infosec risk if not managed properly. In this privilege escalation blog, we will explore this side of AWS Lambda security and how, with only a few, and often common, Identity and Access management misconfigurations, the power of Lambda can be used against you to facilitate privilege escalation turning a relatively low privileged user into a full-blown Administrator.

As we talk about in many of our blogs here at Sonrai Security, public clouds are changing the way businesses do … well everything. A large part of this paradigm shift is around how we secure public cloud environments; it is widely accepted that the perimeter has changed from the network edge to the identities. All of the leading public cloud providers (AWS, Microsoft Azure, and Google Cloud) offer powerful and highly configurable IAM solutions to enable organizations to provide a level of configurability that was previously very difficult to achieve. However, with this power comes a level of complexity that, if not managed properly, can open your business up to significant risks. All we have to do is read the headlines to see the impact of how some unchecked privileges can negatively impact a company’s bottom line and even possibly their entire existence. But enough background, let’s get into the meat of it.

While the primary use case of AWS Lambda is to be used as an automated response to a trigger, they can also be invoked by a user. In fact, all it takes is for a user to have only a single permission to do this; lambda:InvokeFunction. Furthermore, with only two more permissions (iam:PassRole, lambda:CreateFunction) the user can create their own Lambda functions. So with only three permissions a user can create a Lambda in your environment and then invoke it. Depending on the AWS Role attached, the Lambda can be extremely powerful and far-reaching. For your DevOps teams, what an awesome possibility; they can create a wide range of functions to make their lives easier, improve your solutions, and achieve previously unattainable things. However, with only a few IAM misconfigurations, the ability for a malicious actor to escalate their privileges becomes a very real possibility. Thus, the importance of ensuring that the IAM Governance model is correct is paramount to preventing privilege escalations.

So how can AWS Lambda security privilege escalation risk actually happen?

Well, it’s pretty easy given some loose practices and common misconfigurations. In many organizations, the DevOps teams have the ability to create and invoke AWS Lambda functions as part of their job role and are configured with the necessary permissions to do so. On top of that, many AWS Roles are often created within an AWS environment for many purposes. One of the common misconfigurations is creating roles that are far too permissive, which often occurs due to the complexity of IAM. Quite often, there is great pressure “to make it work,” and thus, a Role with too many permissions gets created to keep things moving along. Couple this with the notion of “we’ll go back and fix it later” … which rarely happens … we get to a toxic state. What we end up with is a highly permissive Role that quickly gets forgotten about and sits around waiting for someone to take advantage of it. With all these pieces in place, the following is an example of how it can happen:

Mary is a well respected DevOps user who has access to her company’s AWS environment via her Access Key. Her company has done a good job of locking down her IAM privileges so that she can only do what she needs to for her role, which includes building Lambdas to support the environment (IAM:PassRole, lambda: CreateFunction & lambda:InvokeFunction). However, her AWS access is not protected by two-factor authentication, and the Access/Secret key pair is stored by default in plain text on her laptop. On top of that, there are no restrictions in place as to where Mary can connect from. Unfortunately, Mary is very susceptible to phishing attacks and one day clicks on the wrong link, which leads to the compromise of her laptop. Her key pair is now in the hands of a malicious actor.

The company’s DevOps team, like most, is stretched thin and is trying to navigate the complexities of AWS IAM … which isn’t an easy task. During a recent outage, it was discovered that a locked down AWS Role (SuperSpecialRole), which is only to be used with very select Lambda functions (but not scoped to that), was the culprit. So, to “get things going” again, the permissions were loosened up to provide Full Admin access. This solved the problem, and life went on … with a huge, unknown risk being introduced. To add insult to injury, the DevOps team didn’t catch any of this using their security tools as they just haven’t had the time to understand, configure and/or tune them … which is another very commonplace these teams find themselves in.

With the access key pair in hand, the malicious actor connects to the company’s cloud environment, as Mary, and starts to do some reconnaissance. At first, things look pretty bleak as Mary doesn’t seem to have much access … until it is discovered that she has the privileges to create and invoke Lambda functions. So what does the malicious actor do? They create a new Lambda Function that, when invoked makes use of the iam.attach_user_policy() function to attach the arn:aws:iam::aws:policy/AdministratorAccess policy to themselves. The last thing they must do is find a Role with the right privileges to run this successfully. After watching the environment for a while, it becomes evident that the SuperSpecialRole exactly that is needed. With all this in hand the attack commences.

First they create the function with Mary’s existing permissions and overly-permissive Role and pass in their code (NotBadLambdaCode.zip):

$> aws lambda create-function/
      --function-name NotABadLambda/
      --runtime <runtime variable>/
      --role arnForSuperSpecialRole/
      --handler NotABadLambda.lambda_handler
      --zip-file fileb://(~)/NotBadLambdaCode.zip
      --profile DevOpsMary

Now the malicious actor has the Lambda at their disposal, and they invoke it:

$> aws lambda invoke --function-name NotABadLambda output.txt

Once invoked successfully, the user Mary has gone from a relatively locked down DevOps user to a Full Admin across her company’s AWS Environment. From there, the malicious actor can do whatever they like … with the benefit of impersonating Mary.

As we can see, it doesn’t take much; a few common IAM misconfigurations and privileges can be escalated in your AWS Lambda and AWS environment. Given that Identities form the new perimeter of your environments, this escalation highlights the importance of ensuring that your IAM Governance model is correct is paramount. You need to have full visibility to the Identities in your cloud and understand their true end-to-end permissions. You also need continuous monitoring to ensure those permissions stay as intended and alert if they change. That said, this is much harder than it sounds, so you also need the right processes and tooling to achieve this state of security.

Sonrai Security can help with AWS Lambda Security

Sonrai Security delivers an enterprise security platform focused on identity and data protection inside public clouds. We show you how data has been accessed and can be accessed in the future. Our platform delivers a complete risk model of all these identity and data relationships, including activity and movement across cloud accounts, cloud providers, and third-party data stores.

We help organizations understand and monitor IAM configurations, helping to eliminate weak or accidental configurations that, if left unchecked, will inevitably lead to a disaster. Core to the platform is the collection and analysis of a broad range of API and log data, which now includes findings from the IAM Access Analyzer that quickly finds potential risks to critical data stored in a public cloud.

To learn more about the common mistakes you can make when working in AWS, you may want to read out blog series. Or if you prefer to learn more about privilege escalation attacks in AWS our on-demand webinar will show you how these attacks work and how to be diligent about monitoring to make sure such attacks never succeed.