AWS recently launched Lambda function URLs, a new feature allowing cloud builders to set up simple, dedicated application endpoints for Lambda functions. Other cloud service providers also support similar features, such as GCP HTTP cloud functions and Azure functions HTTP triggers.
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.
With the rise of Serverless adoption among cloud customers in recent years, Serverless seems to be drawing the attention of malicious actors as well, who naturally see value in taking advantage of its popularity. A recently discovered case is that of “Denonia”, malware targeting Serverless environments for the purpose of installing cryptominers (albeit for only a few seconds or minutes at a time, depending on the function’s timeout limit).
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. 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.
A function URL could be at risk of an attack under the following circumstances:
An attacker discovers the function URL in your environment (we will expand on this in the next section).
It has been misconfigured to accept HTTP requests without requiring authentication.
The function’s resource policy authorizes invocation by unauthenticated principals. This is the default setting if no authentication was configured.
The attacker figures out how to use the function, or in other words, what arguments it accepts.
The last requirement could be tricky and depends on the complexity of the function’s API:
A function that accepts no arguments would be trivial to invoke, whereas a function with multiple parameters would be more difficult to crack.
Any prior knowledge the attacker might have about the function would allow them to make a more educated guess as to how it works.
If the function “leaks” information, such as returning informative error messages, this would allow an attacker to infer valid arguments through trial and error.
In the abovementioned scenario, depending on what the targeted function does, an attacker could pose multiple risks to the targeted cloud environment:
Data retrieval or manipulation– If the targeted function has read or write access to sensitive or business-critical data, under the right circumstances, an attacker could abuse the function to query that data, erase it, overwrite it, or append false information to it, impacting its confidentiality and integrity.
Initial access or privilege escalation – In the unlikely case that the targeted function is intended for 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 abuse the function to gain access to the environment or escalate existing privileges.
Vulnerability exploitation – If the targeted function runs an affected version of software vulnerable to remote code execution, or if the function’s code itself happens to contain such a vulnerability, then an attacker might discover this and exploit it to run malware such as a cryptominer until the function is configured to timeout, which could be up to 15 minutes.
Additionally, even without completely understanding the function’s purpose, an attacker seeking to disrupt the operations of a target organization (for whatever reason) could simply automate repeated invocation of the function, leading to the following unwanted results:
Denial of service (DoS)– By filling the customer’s regional quota for concurrent instances (also known as the unreserved concurrency pool), an attacker could block legitimate invocation attempts of this function and any of the customer’s other functions in the same region, thus overloading the environment and interrupting routine processes.
Denial of wallet (DoW) – By continuously invoking the function, an attacker could incur increased costs to the AWS customer. In most cases, this should be a relatively minor concern, as pricing for Lambda functions is typically low. However, depending on the amount of memory and storage allocated to each instance of the targeted function and what it can do , the indirect costs could be significant.
But how might an attacker discover the misconfigured function URL in the first place? Theoretically, they could enumerate all function URLs by querying passive DNS data for subdomains that match the regular expression *.lambda-url.*.on.aws. Incidentally, querying TLS certificate transparency logs would not work, as Lambda apparently only uses a single wildcard certificate for each region, such as *.lambda-url.us-west-2.on.aws for us-west-2, rather than issuing a separate certificate for each unique subdomain. The attacker could then attempt to access each of these URLs in turn, marking those that allow unauthenticated access for further research.
Another potential source for function URLs is development artifacts. An attacker could scour source code for function URLs originally used for testing purposes, that may have been accidentally left in production code and were never disabled. In these cases, the source code might also reveal clues in the form of examples or comments as to how the function operates, and what arguments it accepts. If the attacker is lucky, the code may even include credentials for functions that do require authentication.
Additionally, a sophisticated attacker might possess some knowledge of the inner workings of the target environment, allowing them to make educated guesses about which function URLs are available and how to properly invoke them. For example, an attacker with prior partial access to the target might be able to list function URLs via API queries, or if they happen to have gained access to another related network, such as that of a partner or customer, they might be able to glean information about the company’s function URLs.
Nevertheless, the lack of public information about the existence of a function URL, or even how to invoke it, is not a sufficient security barrier, whereas much like in many other aspects of the cloud, secure configuration is vital.
There are several ways to secure Lambda function URLs and protect your environment from the abovementioned scenarios. Generally speaking, best practice is 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.
With IAM authentication enabled (auth type set to AWS_IAM, which is the default setting), the function URL itself will only accept HTTP requests if they are signed by an AWS access key, and only if that key belongs to a principal with effective lambda:InvokeFunctionUrl permissions. Meaning that for same-account access they must be granted this permission by their identity policy, and for cross-account access it must also be granted by the function’s resource policy, otherwise the request will be denied. Effectively, this ensures that only authenticated AWS users can invoke the function via its URL.
In contrast, if IAM authentication for the function URL is disabled via the AWS console (auth type set to NONE), which is not recommended, AWS will automatically attach a resource policy granting public access (i.e., * set as principal for the lambda:InvokeFunctionUrl action). If you do decide to allow unauthenticated invocation of the function via its URL, make sure that the function has minimal permissions in your environment, so as to minimize the risk. You could also implement a custom authentication scheme within the function itself as an alternative to IAM authentication, but this is not considered best practice.
In addition to IAM authentication, by configuring an IAM resource policy that determines who is authorized to invoke a function, under what conditions, and whether directly (lambda:InvokeFunction) or via its URL (lambda:InvokeFunctionUrl), you can explicitly limit invocation to specific principals, thus reducing the risk of public exposure. However, you should avoid using overly permissive resource policies, such as setting a wildcard (*) as principal for invocation, either directly or via a URL, as this would authorize any authenticated AWS user to invoke the function, and basically anyone can create an AWS account.
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.). However, CORS is not a strong security barrier on its own, as origins can be spoofed, and an attacker could theoretically discover the specifics of how to invoke the function (as mentioned above), including which headers and methods are accepted.
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. When choosing a maximum value, you should adjust it depending on the function’s specific usage. Setting it too low could ease denial-of-service attacks, whereas setting it too high might allow denial-of-wallet attacks.
Wiz provides defenders with coverage across compute and exposure options, so you don’t have to model each risk separately – we do it for you and abstract it on the Security Graph. As far as Wiz is concerned, Lambda function URLs are just another exposure path. Wiz helps cloud builders make sure they are using Lambda function URLs securely, by providing pre-built Controls and Configuration Rules that alert you to toxic combinations of network design, resource configuration, identity, and more.
For example, you can use Wiz to check for Lambda functions with the following combination:
Exposed to the internet via a URL, load balancer, or API gateway.
Doesn’t require proper authentication or authorization, whether the issue stems from disabled IAM authentication or an overly permissive resource policy.
With high privileges in the environment.
Similar checks are available for any other type of publicly exposed Serverless, including GCP and Azure analogues. Additionally, Wiz alerts you to Serverless instances running vulnerable software or infected with malware.
To monitor the security state of all Serverless resources in your environment and view a summary of issues related to the various scenarios described here, you can use the Wiz Serverless dashboard.
This blog post was written by the Wiz Research Team, as part of our ongoing mission to analyze threats to the cloud, build mechanisms that prevent and detect them, and fortify cloud security strategies.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。