The main advantage of utilizing serverless architecture, such as Amazon Web Services (AWS), is that it is a great way to build applications without having to manage the infrastructure. The provider will provision, scale, and maintain the servers to run applications, databases, and storage systems. Naturally, this offloads the risk of server-side insecurities to the provider. However, the applications themselves still execute code, and if this code is insecure, it is still vulnerable to traditional application-level attacks. Generally speaking, serverless applications can be exploited using traditional application attacks, attacks modified for serverless architecture, or by exploiting vulnerabilities unique to serverless architecture. 

This blog post uses levels to discuss a variety of attacks. These include traditional application attacks executed in serverless applications, traditional application attacks modified for use in serverless application exploitation, and considerations of new vulnerabilities introduced with the rise of serverless application architecture.

Level One: Traditional Application Attacks in Serverless Applications

The Same Old^TM Attack

Several traditional attacks are still valid and highly effective on serverless applications. One of the most critical forms of attack method is a traditional SQL/NoSQL injection technique. Authentication flaws typically have a larger attack surface of potential entry points, services, events, and triggers. It may be 2020, but there has not been much improvement in terms of data storage, plaintext sensitive data, and weak cryptography. Cross-site scripting (XSS) is still present in serverless applications with the traditional sources stored (database) and reflected. The likelihood of deserialization attacks increases due to serverless architectures utilizing languages such as Python and NodeJS alongside JSON. There has been an increase in vulnerabilities introduced by the supply chain due to microservices using many dependencies and third-party libraries with vulnerabilities.

Same Attack, Different Target

A smaller number of traditional application attacks occur in the same serverless architecture but utilize a different target. OS command injection is still relevant, but instead of an attacker targeting files such as /etc/passwd, the attacker aims for source code and other sensitive files stored in the container. Additionally, traditional methods such as stealing keys, performing MitM attacks, and stealing readable data at rest and in transit are still relevant, but the data is in the cloud storage or database tables instead. 

Less Relevant Attacks

Traditionally, brute-forcing weak and default passwords is less common as an attack method, due to the infrastructure's authentication services. Denial of Service (DoS) attacks are far less of a concern, as they only tend to affect the designated container and current execution. As the provider handles the infrastructure, the need to regularly update and patch the environment is in their hands. 

Level Two: Modifying Traditional Application Attacks for use in Serverless Applications 

Extension of Attack Surface

Some attacks are still valid via different methods or sources, shifting the attack surface and increasing the likelihood of exploitation. Event-driven sources extend the attack surface beyond merely direct user input. The stateless nature of serverless architecture leads to hundreds of microservices with functionalities, resources, and events. Each component requires access control configuration and opening up the attack surface. Attackers target functions with excessive privileges to gain unauthorized access to resources instead of gaining control over the server environment. In serverless architecture, the threat is often higher for security misconfiguration as opposed to unused pages or unprotected files, which become unlinked triggers and public buckets. Functionalities may now contain unprotected secret keys or tokens, which, when compromised, allow an attacker to execute further functionality. Serverless architecture means XSS payloads could execute from different sources such as email, cloud storage, and logs.

APIs as a Critical Attack Vector

The use of application programming interfaces (APIs) in serverless architecture leads to many more critical attack vectors. Code injection allows the attacker to utilize other API functionality to interact with other services on the application. While leaked API keys become a critical attack vector, attackers perform unauthenticated and unauthorized functionality across the application.

Security Implications of Containers

There are several security implications to consider with regard to traditional vulnerabilities in containerized applications

Operating under the expectation that containers die after the execution of functionality and storing data to /tmp, thus leaving sensitive data attackers in containers that are still accessible by attackers. Traditional files attackers would seek now belong to the infrastructure and are less of a concern (logs, passwords, hosts). The attacker targets the source code as well as the environmental variables. Using XML External Entity (XXE) injection to execute remote requests (out of band) is less likely, as the functions tend to run inside the internal virtual private network. Utilizing XXE vulnerabilities to scan is a lower impact attack, as this will only run for the duration of the functionality itself. Attackers identify misconfigured functionalities with a long timeout or low concurrency limits in attempts to cause a DoS. Denial of Wallet attacks occur due to functions with a high concurrency limit, this is a financial attack that abuses the auto-scaling nature of serverless architecture. Relying solely on the infrastructure provider for logging and monitoring is insufficient and writing a logging system is complicated in a serverless architecture with many microservices, resulting in less attack detection. 

Level Three: Unique Vulnerability Considerations in Serverless Applications

As expected, serverless architecture also has several vulnerabilities that are unique to its design. As traditional DoS attacks are not as relevant, we must consider DoS attacks in a containerized environment. The main factors here are function concurrency limit (triggering a function until the limit is hit), environment disk capacity (filling the /tmp folder), and account writing/reading capacity (triggering max allowed database table scans). Denial of Wallet attacks leverage the inherent automated scalability and availability features of serverless architectures to consume large quantities of resources, resulting in financial harm to the organization. Cryptography keys, API tokens, storage credentials, and other sensitive settings are shared more easily between functions and code in serverless architecture, leading to sensitive data leakage. In serverless environments, if the container is not destroyed, any written application data that did not manually delete after use could be accessed by an attacker. Due to microservices' stateless nature, it is harder to verify that a function should be invoked, leading to access control issues, bypassing the execution flow, and providing access to unauthorized data. 

TL;DR Summary

Sensitive application data stored in different locations still requires the same level of protection as traditional applications. Environmental data is less relevant, but cloud storage requires careful access control, as one poorly configured function could result in a massive data leak. Standardized authentication and authorization models in serverless architecture allows developers and DevOps to focus on securing the microservices and utilize a system that follows the least privilege principle. Injection attacks are more prevalent than ever, but cause less damage due to being executed inside the container. Serverless designated attacks, such as Denial of Wallet, target the organization's finances rather than the application's availability. Developers must change their way of thinking as attackers create new approaches using different attack vectors, some of which cannot be mitigated utilizing the methods from traditional server-based applications.