Securing your Serverless Lambda functions

“The global serverless computing market is expected to witness a further growth in the forecast period of 2022-2027, growing at a CAGR of 22.2%, according to the industry analyst firm Expert Market Research group.  Such growth is driven by the need for cost effective computing services, low maintenance and strong demand for web and mobile applications to address the rising consumer demands.

However, rise in serverless adoption has also seen rise in security related incidents. Despite the security features offered by cloud providers, typical characteristics of serverless such as short runtime durations, volume of executions, and the dynamic and fluid nature of the server functions can make it difficult to detect, investigate and respond to a potential compromise. 

For example, the Denonia Malware, first ever known malware to attack AWS Serverless service – Lambda functions – created ripples in the serverless world. This malware written in Go Lang used a DNS over HTTPS (DoH). DoH encrypts DNS queries and sends the requests out as regular HTTPS traffic to DoH resolvers.

The primary reason for this gap is lapse in customer commitment to uphold the shared-responsibility agreement.  While AWS is full responsible for global infrastructure that runs all of AWS Cloud, under the shared-responsibility model the user maintains control over his or her content that is hosted on the Amazon infrastructure, including  Serverless functions such as AWS Lambda.  When customers fail to keep up their end of the promise, it leads to security lapses such as the Denonia malware.

Evolution in Serverless

The Denonia malware incident exposed a vulnerability that led AWS to introduce  “additional- security mechanism” to protect the Lambda functions – the Lambda function URLs –  a new feature allowing cloud builders to set up simple, dedicated application endpoints for Lambda functions.

A function URL is a dedicated HTTP(S) endpoint for your Lambda function. You can create and configure a function URL through the Lambda console or the Lambda API.

When you create a function URL, Lambda automatically generates a unique URL endpoint for you. Function URL endpoints have the following format:

https://.lambda-url..on.aws

Although Lambda functions could already be externally exposed via API gateways and load balancers, Lambda URLs let AWS users fast-track this process with minimal overhead, for straightforward use-cases such as webhook handlers.

Additionally, Lambda URLs can be used during the development and testing of Serverless applications, allowing developers to focus on core functionality and postpone dealing with validation and authorization requirements to later stages of development.

Use case for Lambda function URLs 

Description: Lambda call using function URL

Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching.

For example, when you are implementing webhook handlers, form validators, mobile payment processing, advertisement placement, machine learning inference etc.

The risks of “insecure” use of AWS Lambda function URLs

Lambda function URLs may be simple, but like any other externally exposed resource in your cloud environment, it is important that they be properly secured as well. While functions residing behind an API gateway or load balancer rely on the secure configuration of these frontend services, function URLs must be independently secured, and misconfigured instances could pose an attractive target for malicious actors hoping to cause damage or gain access to sensitive data.

Below is a classic example of A function URL could be at risk of an attack under the following circumstances:

1. 1. An attacker discovers the function URL in your environment (
2. 2. It has been misconfigured to accept HTTP requests without requiring authentication.
3. 3. The function’s resource policy authorizes invocation by unauthenticated principals. This is the default setting if no authentication was configured.
4. 4. The attacker figures out how to use the function, or in other words, what arguments it accepts.

The above elaborated risk could give rise to multiple impacts to the targeted cloud environment:

1. 1. Data retrieval or manipulation– An attacker could abuse the function to query business critical data, erase it, overwrite it, or manipulate it
2. 2. Initial access or privilege escalation – If the targeted function is capable of administration purposes, such as creating new users or roles, adding users to existing groups, changing permissions, modifying policies, resetting passwords, etc., then an attacker could misuse privilege management
3. 3. Distributed Denial of service (DDoS)– By filling the customer’s regional quota for concurrent instances, an attacker could lead to Denial of Service, bringing down the customer environment.
4. 4. Denial of wallet (DoW) – By continuously invoking the function, an attacker could incur increased costs to the AWS customer.

This might interest you: AWS Glue for Serverless Data Integration Services for Analytics and Machine Learning

Being proactive rather than reactive with Lambda Functions

1. IAM authentication and authorization

In general, it is advised to always require both authentication and authorization for invocation of a Lambda function, and to host it in a private subnet within a VPC. If your function needs public internet access, for example, to query an external non-AWS API, then you should expose it through a NAT gateway in a public subnet within the same VPC.

2. CORS

If cross-origin resource sharing (CORS) configuration is enabled, by default the function URL will accept HTTP requests from any origin (domain), which is not recommended. Therefore, you should configure additional CORS constraints, such as only allowing HTTP requests from specific origins, or requests containing specific headers and HTTP methods (GET, POST, etc.)

3. Reserved concurrency

By reserving concurrency  for every function with a URL and limiting it to a maximum value, you can ensure that even if a function URL is somehow invoked repeatedly by a malicious actor attempting to cause disruption, any business impact will be limited to the specific compromised function, while unrelated operations in the same region will remain unaffected.

About Indium Software

Indium is a digital engineering leader and full spectrum integrator that helps customers embrace and navigate the cloud-native world with certainty. Regardless of where you are in your digital journey, Indium helps you to migrate/modernize your applications and data on the cloud, make sense of the data and leverage automation to scale and innovate in a secured and compliant fashion.

With deep expertise across Applications, Data & Analytics, AI, DevOps, Security and QA Indium makes technology work and accelerate business value, while adding scale and velocity to customer’s digital journey on AWS.