Az - Function Apps
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Functions is a serverless solution that allows you to write less code, maintain less infrastructure, and save on costs. Instead of worrying about deploying and maintaining servers, the cloud infrastructure provides all the up-to-date resources needed to keep your applications running.
In the Azure portal, integration between Azure Functions and Azure API Management is facilitated, allowing HTTP trigger function endpoints to be exposed as REST APIs. The APIs exposed in this manner are described using an OpenAPI definition, providing a standard, language-agnostic interface to RESTful APIs.
The Flex Consumption plan offers dynamic, event-driven scaling with flexible compute options. It automatically adds or removes function instances based on demand, ensuring efficient resource use and cost-effectiveness through a pay-as-you-go model. This plan supports virtual networking for enhanced security and allows you to reduce cold starts by pre-provisioning instances. It is ideal for applications that experience variable workloads and require rapid scaling without the need for container support.
The traditional Consumption plan for Azure Functions is the default serverless hosting option, where you pay only for the compute resources when your functions are running. It automatically scales out based on the number of incoming events, making it highly cost-effective for applications with intermittent or unpredictable workloads. While it does not support container deployments, it includes optimizations to reduce cold start times and is suitable for a wide range of serverless applications that require automatic scaling without the overhead of managing infrastructure.
The Premium plan for Azure Functions is designed for applications that need consistent performance and advanced features. It automatically scales based on demand using prewarmed workers, eliminating cold starts and ensuring functions run promptly even after periods of inactivity. This plan offers more powerful instances, extended execution times, and supports virtual network connectivity. Additionally, it allows the use of custom Linux images, making it suitable for mission-critical applications that require high performance and greater control over resources.
The Dedicated plan, also known as the App Service plan, runs your functions on dedicated virtual machines within an App Service environment. This plan provides predictable billing and allows manual or automatic scaling of instances, making it ideal for long-running scenarios where Durable Functions are not suitable. It supports running multiple web and function apps on the same plan, offers larger compute sizes, and ensures full compute isolation and secure network access through App Service Environments (ASE). This option is best for applications that need consistent resource allocation and extensive customization.
Container Apps enable you to deploy containerized function apps within a fully managed environment hosted by Azure Container Apps. This option is perfect for building event-driven, serverless applications that run alongside other microservices, APIs, and workflows. It supports packaging custom libraries with your function code, migrating legacy applications to cloud-native microservices, and leveraging high-end processing power with GPU resources. Container Apps simplify deployment by eliminating the need to manage Kubernetes clusters, making them ideal for developers seeking flexibility and scalability in a containerized environment.
When creating a new Function App not containerised (but giving the code to run), the code and other Function related data will be stored in a Storage account. By default the web console will create a new one per function to store the code.
Moreover, whenever a new instance of the app needs to run, the code of the app will be gathered from here and executed.
This is very interesting from an attackers perspective as write access over this bucket will allow an attacker to compromise the code and escalate privileges to the managed identities inside the Function App.
It's possible to give access to a function to all Internet without requiring any authentication or give access IAM based
It's also possible to give or restrict access to the Function App from the Internet give access to an internal network (VPC) to the Function App
This is very interesting from an attackers perspective as it might be possible to pivot to internal networks from a vulnerable Lambda function exposed to the Internet.
it's possible to configure environment variables inside an app. Moreover, by default the env variables AzureWebJobsStorage and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING (among others) are created. These are specially interesting because they contain the account key to control with FULL permissions the storage account containing the data of the application.
Inside the sandbox the source code is located in /home/site/wwwroot in the file function_app.py (if python is used) the user running the code is app (without sudo permissions).
Moreover Function App might have certain endpoints that require a certain level of authentication, such as "admin" or "anonymous". An attacker could try to access the anonymous allowed endpoints to bypass the restrictions and gain access to sensitive data or functionality.
Note that there aren't RBAC permissions to give access to users to invoke the functions. The function invocation depends on the trigger selected when it was created and if a HTTP Trigger was selected, it might be needed to use an access key.
When creating an endpoint inside a function using a HTTP trigger it's possible to indicate the access key authorization level needed to trigger the function. Three options are available:
ANONYMOUS: Everyone can access the function by the URL.
FUNCTION: Endpoint is only accessible to users using a function, host or master key.
ADMIN: Endpoint is only accessible to users a master key.
Type of keys:
Function Keys: Function keys can be either default or user-defined and are designed to grant access exclusively to specific function endpoints within a Function App. This allows for fine-grained security control, ensuring that only authorized users or services can invoke particular functions without exposing the entire application.
Host Keys: Host keys, which can also be default or user-defined, provide access to all function endpoints within a Function App. This is useful when multiple functions need to be accessed using a single key, simplifying management and reducing the number of keys that need to be distributed or stored securely.
Master Key: The master key (_master) serves as an administrative key that offers elevated permissions, including access to the runtime REST APIs of a Function App. This key cannot be revoked and should be handled with utmost care. It is crucial not to share the master key with third parties or include it in native client applications to prevent unauthorized administrative access.
When setting the authentication of a function to ADMIN (and not ANONYMOUS or FUNCTION), it's needed to use this key.
System Keys: System keys are managed by specific extensions and are required for accessing webhook endpoints used by internal components. Examples include the Event Grid trigger and Durable Functions, which utilize system keys to securely interact with their respective APIs. System keys can be regenerated through the Azure Portal or key APIs to maintain security.
Example to access a function API endpoint using a key:
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
