AWS Lambda Function URL

Update: Thanks to Jonathan Rau for pointing this out. The overall risk of this in the grand scheme of AWS is likely not high. I don’t expect we will see a huge increase in public facing lambdas exposing sensitive data. I do however, think that over time they will accumulate and where they will get us the most is in applications where they were stood up as a POC or a v.1 and never had their AuthZ added which will turn into business logic and info disclosure risks down the road.

AWS recently announced the release of this new feature. AWS Lambda Function URLs: built-in HTTPS endpoints for your Lambda functions (amazon.com)

It is a very helpful feature. I know, I’ve had projects where we had to use ALBs or API Gateways to publish an API hosted in Lambda. It would have saved a ton of time and complexity. But as a security practitioner I can’t help but think an announcement like this was short sited and did damage to the message that the cloud can merge security and innovation. This is what happens when innovation out paces or ignores security.

I’m not going to explain in detail what this feature is or how to use that, there are plenty of those posts out now. Here is a good one: AWS Lambda Function URLs — Another way to create HTTP endpoint for a Lambda function | by Jaewoo Ahn | Apr, 2022 | Medium

So What’s the Main Issue?

It literally took me 4 clicks from Create Function to Create Function buttons to create a lambda with this feature. https://qvlrnsc6maomd7wbjgcjssitfu0fskqk.lambda-url.us-east-1.on.aws/

I chose No Auth. The idea is that you aren’t using IAM auth there, but building in authorization into your API. But what that also means is that if I don’t have auth ready right then, I just published a public API with no auth. This was at least a little harder to do with an ALB or API Gateway and took a little more consideration and thought.

The risks are this could be an active API that returns patient records, customer records, internal data, etc. It could allow the modification of an internal system. Or it could allow remote code execution to an internal system.

What Security Is Available Now?

Basically there are only two options, and none of them are great. Especially if you have 100s of accounts with developers in many of them.

IAM Policy

You can create or modify an IAM policy that allows/denies the usage of this. The downside to this is:

You have to deploy a policy update across your org
You have to apply this via SCP and again, test and deploy it across your org
It will not provide a friendly fail to your developers if they try.

Reference: CreateFunctionUrlConfig - AWS Lambda (amazon.com)

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": "lambda:CreateFunctionUrlConfig",

"Resource": "*"

}

]

}

IAM Access Analyzer

For those of you who use this, you know it was a great addition to IAM, but it can be noisy and, as with many of AWS’ security features it is yet another screen you have to use outside of Security Hub. It will detect a public setting for a Lambda that uses this:

Where’s the Rub?

A large portion of the organizations using AWS have not yet adopted an allow only approach to IAM. It’s hard to manage and it can be a pain for innovation, but it can help prevent things like this. AWS releases a new API/IAM Policy option, it doesn’t get enabled by default. But for most orgs, this is not the case. They have Lambda:* or at best Lambda:Create* allowed.

That means last week, their risk of public exposure just increased and their options for detection, and false positive detection are far a few between.

They would either have to be regularly reiew in Access Analyzer OR using Event Bridge to ingest it into a SIEM that was prepared to recognize the new threat. The rub comes if someone used the feature, but actually built in authorization. Then you have a false positive. So we now have a high signal to noise ratio on a very risky feature.

What Do We Do?

My suggestion for now is prevent it via SCP. Yes, you’ll likely have to test and roll out an org wide change to SCP, but I don’t see how we can justify the risk over the benefit. Developers can still deploy this via ALB or API Gateway and its better anyway. For a large org, just prevent it. And be sure you are alerting on it when it’s detected. You should immediately be ingesting the Access Analyzer alerts into your SIEM and reporting on them. I would want to always see a metric # of FunctionURLs = 0 on this one.