Download The State of Serverless Security on Microsoft Azure
By David Fiser and Alfredo Oliveira
Serverless computing has an ideal operational model, one that allows organizations to run services without provisioning and managing underlying infrastructure. With serverless technology, cloud service providers (CSPs) are in charge of all things related to infrastructure.
However, this doesn’t mean that serverless services are free from security flaws. Users can, after all, upload code into multitenant environments. And when the code they upload is untrusted — or worse, malicious — it can pose several security challenges to organizations.
In our new report, we performed exploitation simulations of user-provided code vulnerabilities among serverless services provided by the major CSPs in the market. We have chosen to zero in on Microsoft Azure, where we found the most number of sensitive environmental variables based on our investigation. Leaked environmental variables can lead to the full compromise of the entire serverless environment. We discuss our full findings and our security recommendations in our research paper, “The State of Serverless Security on Microsoft Azure.”
A closer look at Microsoft Azure
In our investigation, we simulated a user code vulnerability exploitation to attempt remote code execution (RCE) on the infected environment using a remote shell that connects to our own server. After a successful connection was established, we ran commands that aimed to mimic what an attacker would do and looked for security gaps that can be abused.
Figure 1. Attack simulation of a serverless function
We focused on gathering environmental information, such as internal architecture hints, timeouts that apply to serverless environments, execution rights and capabilities, networks, and disk access, some of which we discuss in this article. Meanwhile, our discussion of secrets management tools and methods, including storage and transfer of information, can be found in our research paper.
Azure App Service
The Azure App Service provides ready-to-use infrastructure for applications. Essentially, from a technical perspective, it is a Docker container with prepared images and language interpreters for listed runtime stacks, such as Python, Node.js, Java, .NET, and Ruby.
The presence of the “.dockerenv” file inside the file system root and the “docker run” command found inside the App Service log stream confirms that a Docker container engine is used for running the service.
Figure 2. Azure log that confirms the use of a Docker container engine
Meanwhile, there are different timeouts set for web requests and spawned processes.
Timeout for web request | Timeout for spawned process |
240 seconds | Up to 10 minutes |
Users can also bind App Service with continuous integration and continuous delivery (CI/CD) pipelines, such as GitHub repositories and commit triggers.
Figure 3. App Service with CI/CD integration
Source: Trend Micro Security News
Because the App Service is intended to be a publicly accessible web service, there is no default access limitation set. It is the user’s full responsibility to limit access, if needed.
- 01
Application and
Read more
user permissions - 02
Network
Read more - 03
Disk Access
Read more
We discuss other exposed sensitive environmental variables inside the Microsoft Azure environment and how organizations can better secure their serverless environments in our research paper.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.
Cellular IoT Vulnerabilities: Another Door to Cellular Networks
Today’s Cloud and Container Misconfigurations Are Tomorrow’s Critical Vulnerabilities
Ransomware Spotlight: INC
The Realities of Quantum Machine Learning