Serverless (in)security

TL;DR

• Most of vulnerabilities existing in traditional applications can also appear in serverless applications. The most common ones are described in OWASP Serverless Top 10.
• There are also threats which are specific to serverless, like event injection or overwriting the code stored in S3 bucket.
• It’s quite common, that Lambda’s execution role has more permissions than it’s required.
• The malicious code can be also smuggled to your serverless application via used dependencies.

What is AWS Lambda?

FaaS (Function as a Service) model allows to build applications and services without the need to manage physical or virtual servers. It is the provider who is responsible for the security of networks, servers, operating systems, their configuration, and update. On the other hand, the developer’s responsibility is to keep the code, logic and application configuration secure. The division of responsibility is defined by the shared responsibility model.

To understand attack vectors in an application built in a serverless architecture, we must first realize that Lambda is actually a runtime environment for our code, operating in a container built on Amazon Linux image and run on microVM (Firecracker).

In theory this environment is run separately for each call, just for the time of handling our code and then it is removed. In practice, launching a new Lambda instance takes a relatively long time (so called cold start). To speed up the performance of subsequent Lambda calls, “old” instances are not immediately closed and are used to handle other incoming calls, while new instances are still being launched. Taking into account that the calls are not completely separated from each other, and the Lambda instance file system is not completely in a read-only mode (the folder /tmp has write permissions) then under favourable circumstances it is possible for an attacker to “take over” Lambda instances and execute malicious code in the context of a new call