Serverless computing is a cloud computing architecture in which the cloud provider maintains the server and dynamically handles the distribution of machine resources.
With serverless computing, application developers can deploy code as functions instead of managing servers, and servers will be assigned based on demand. It uses the Function-as-a-Service (FaaS) model of cloud computing, making it simple for developers to package and deploy their code without worrying about the complicated server infrastructure.
One of the primary reasons for the rise in popularity of serverless technology is its ability to speed up the software development process. In addition, it enables developers to outsource server infrastructure administration to a Cloud Service Provider (CSP), which handles application functions. Servers are abstracted from application development in serverless, and the cloud provider is responsible for provisioning, maintaining, and growing the server infrastructure in response to deployed code events. However, the fundamental issue with serverless is that the CSP is only in charge of the security of the cloud, not the security within the cloud. This means that, in addition to traditional apps' risks and vulnerabilities, the serverless application has security concerns specific to the serverless architecture.
Adapting serverless technology, we also transmit security risks to the infrastructure provider, such as AWS, Azure, or Google Cloud. In addition to the many benefits of developing serverless applications, like affordability and scalability, some security concerns are outsourced to our service provider, who is typically regarded as reliable.
AWS Lambda, Azure Functions, Google Cloud Functions, and IBM Cloud Functions are examples of serverless services that run code without managing or provisioning servers. However, they still execute code even if these programs do not operate on a managed server. If this code is not implemented securely, the application may be vulnerable to common application attacks such as Cross-Site Scripting (XSS), Command/SQL Injection, Denial of Service (DoS), broken authentication and authorization, and many others.
Challenges in Serverless Environment Security
- Protocols, Vectors, and Attack Points have multiplied to every function, with the protocol equaling a potential attack vector. This requires specific security measures for Google Functions, Azure Functions, and AWS Lambda.
- More resources are equivalent to more management permissions. There are difficulties in deciding permissions for all of these interactions because more resources are comparable to more permissions.
- Serverless apps utilize several cloud providers' services across multiple versions and locations. It would help if you had a thorough perspective of your entire serverless ecosystem to evaluate your attack surface and potential threats. This security-focused vision might become increasingly difficult to establish and maintain as your app expands
Understanding Common Vulnerability in Serverless Architecture
1. Function Event-Data Injection
In traditional applications, injection vectors are typically defined as any location where the attacker can control or manipulate the application's input. However, the attack surface extends in serverless apps.
Most serverless architectures include many event sources that you can use to trigger the execution of a serverless function. This multitude of event sources increases the potential attack surface and introduces a complex nature when attempting to protect serverless functions from event-data injections. This is made worse because serverless architectures are not nearly as well-understood as web environments, where developers are aware of which message components should not be trusted (such as GET/POST parameters, HTTP headers, and so on). These are some of the most typical types of injection issues in serverless architectures:
- Function runtime code injection (e.g. Node.js/JavaScript, Python, Java,C#,Golang)
- OS Command Injection
- Pub/Sub Message Data Tampering (e.g. MQTT data injection)
- NoSQL Injection
2. Broken Authentication
Serverless functions, as opposed to traditional architectures, run in stateless compute containers. As a result, hundreds of different parts run independently instead of a single large flow managed by a server.
Without continuous flow, serverless architectures can get multiple entry points, services, events, and triggers. Each has a distinct purpose, triggered by a particular event, without awareness of the other moving parts. Identities and access controls are poorly designed, leading to Broken Authentication.
Attackers will try to find a resource overlooked, such as open APIs or public cloud storage. External-facing resources should be one of many concerns. For example, the execution of internal functionality without authentication is possible if a function is triggered by administrative emails.
3. Sensitive Data Exposure
The exposure of sensitive data is a concern in serverless architecture, just like in any other architecture. Serverless applications are still vulnerable to many of the same attacks as traditional architectures, including key theft, man-in-the-middle (MitM) attacks, and theft of sensitive data while it is at rest or in transit. The information sources, however, might differ.
Leaked keys may result in unauthorized and unauthenticated actions in the account. There are tools like KeyNuker, Truffle Hog, and git-secrets by AWS Labs that scan GitHub for keys that have been compromised. Everything outside the tmp directory is read-only in the environment where functions are running. Therefore, attackers can use this folder as a target to search for past executions.
4. XML External Entities (XXE)
Serverless application exploits that are successful frequently result in the extraction of private information, execution of a remote server request, system scanning, Denial of Service (DoS), and other events. When using serverless, if a function runs on an internal virtual private network, it might not be possible to execute remote requests (OOB) (VPC). In addition, since the function is running in a designated container that will only affect the current execution, scanning will be less likely to impact in the short time it has. Dos attacks are less of a concern.
Any XML processing could expose the program to XXE attacks. Many older XML processors permit the specification of an external entity by default, which takes the form of a URI that is dereferenced and assessed during XML processing. In a serverless application, a successful XXE attack could primarily result in function code leaks and other sensitive files present in the environment (such as environment variables and files in the /tmp directory).
5. Broken Access Control
Several microservices may exist in a serverless application. They coordinate various activities, resources, services, and events, resulting in a comprehensive system logic. Because serverless architecture is stateless, each resource must have its access control settings carefully configured, which can be time-consuming. Instead of taking over the environment, attackers will target overly privileged functions to gain unauthorized access to resources within the account. Due to the lack of automated detection and testing by application developers, access control flaws are frequently present. Organizations that attempt any single permission model are likely to fail. All functions should follow the "least privilege" principle to avoid access control problems.
The compromised resource determines the impact. Simple situations may result in database or cloud storage data leakage. More significant financial losses or complete control over the resources or the account could result from more complex scenarios where a compromised function can create other resources.
6. Security Misconfiguration
The relatively new serverless architecture offers various customization and configuration settings for any particular need, task, and environment. Critical configuration settings can be misconfigured with a high likelihood, potentially resulting in sensitive data loss.
Due to insecure configurations in the settings and features provided by the cloud service provider, serverless applications are vulnerable to attacks. For instance, Denial-of-Service (DoS) attacks frequently happen in serverless applications due to improperly configured timeout settings between the functions and the host. The application is attacked using low concurrent limits.
7. Cross-Site Scripting (XSS)
Since browsers are the primary target of cross-site scripting (XSS) attacks, the attack vectors are identical. The source of the stored attack may be where the variation in serverless comes from. Traditional XSS attacks typically originate from databases or reflective inputs. In contrast, serverless allows them to come from various sources, including emails, cloud storage, logs, IoT, and others. The same effect occurs when code is run on the user's browser.
However, serverless is stateless by design, so there is less chance that we will have typical session cookies, which could result in user impersonation. However, this does not rule out the possibility of sensitive data being stored in the client, such as API keys in the browser's local/session storage.
8. Insecure Deserialization
Deserialization attacks may become more prevalent in serverless applications due to the widespread use of dynamic languages like Python and NodeJS and the serialized data type JSON. In addition, most functions use 3rd-party libraries to handle the (de) serialization of the data, which could introduce a weakness to our serverless application and the potential attack vector. Deserialization flaws are reasonably typical in JavaScript and Python (such as pickle and node-serialize). However, you can also find it in .NET and Java.
Like always, the application and the data it handles determine the business impact. Insecure deserialization frequently results in executing arbitrary code, which may ultimately cause data loss and, in extreme circumstances, even resource and account control.
9. Using Components with Known Vulnerabilities
Micro-services use serverless, typically small and simple functions. They rely on third-party libraries and dependencies to accomplish the desired tasks. One of the most frequent risks is supply chain vulnerability. In "Poisoning the Well", attackers use an upstream attack to gain long-term persistence in the application.
Cloud-native applications frequently include many modules and libraries with code from numerous external sources. Attackers attempt to insert malicious code into widely used projects. The malicious code in your cloud apps can call home, get instructions, and cause havoc after poisoning the well.
10. Insufficient Logging and Monitoring
Applications that lack an appropriate auditing mechanism and rely solely on their service provider are likely to have insufficient security monitoring and auditing functionalities. Attackers rely on a lack of monitoring and quick action to accomplish their objectives undetected; this is a known factor. It only makes it simpler for the attackers that serverless auditing is now even more challenging than in traditional applications, where we use our logging system rather than the one provided by the infrastructure.
It is impossible to evaluate the consequences of not having a good auditing system in place on its own. However, the results of discovering security incidents too late can be severe. It is possible that the application already has an attacker who has infected the code.
Remediations
- Configure an auditing and monitoring system to look for data that the infrastructure provider needs to report so you can spot security incidents fully.
- Keep track of the system's dependencies and versions continuously.
- Before processing any serialized objects originating from untrusted data (such as cloud storage, databases, emails, notifications, or APIs), validate them by applying strict type constraints.
- Look carefully at each function and stick to the "least privilege".
- Utilize secure techniques, such as Federated Identity (e.g. SAML, OAuth2, Security Tokens), for service authentication between internal resources, and pay attention to security best practices.
References and Further Reads
Kubernetes Security: Serverless Security: Risks and Best Practices from Sysdig
