GITBOOK-740: No subject

pentesting-cloud/azure-security/az-privilege-escalation/az-functions-app-privesc.md

@@ -29,7 +29,7 @@ With permissions to read the containers inside the Storage Account that stores t
 
 Once you find where the code of the function is located if you have write permissions over it you can make the function execute any code and escalate privileges to the managed identities attached to the function.
 
-* **`File Share (`**`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` and `WEBSITE_CONTENTSHARE`)
+* **`File Share`** (`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` and `WEBSITE_CONTENTSHARE)`
 
 The code of the function is usually stored inside a file share. With enough access it's possible to modify the code file and **make the function load arbitrary code** allowing to escalate privileges to the managed identities attached to the Function.
 
@@ -65,9 +65,9 @@ open "smb://<STORAGE-ACCOUNT>.file.core.windows.net/<FILE-SHARE-NAME>"
 ```
 {% endcode %}
 
-* **`function-releases`**`(WEBSITE_RUN_FROM_PACKAGE`)
+* **`function-releases`** (`WEBSITE_RUN_FROM_PACKAGE)`
 
-It's also common to find the **zip releases** inside the folder function-releases of the Storage Account container that the function app is using in a container **usually called `function-releases`**.
+It's also common to find the **zip releases** inside the folder `function-releases` of the Storage Account container that the function app is using in a container **usually called `function-releases`**.
 
 Usually this deployment method will set the `WEBSITE_RUN_FROM_PACKAGE` config in:
 
@@ -83,6 +83,10 @@ This config will usually contain a **SAS URL to download** the code from the Sto
 With enough permission to connect to the blob container that **contains the code in zip** it's possible to execute arbitrary code in the Function and escalate privileges.
 {% endhint %}
 
+* **`github-actions-deploy`** (`WEBSITE_RUN_FROM_PACKAGE)`
+
+Just like in the previous case, if the deployment is done via Github Actions it's possible to find the folder **`github-actions-deploy`** in the Storage Account containing a zip of the code and a SAS URL to the zip in the setting `WEBSITE_RUN_FROM_PACKAGE`.
+
 * **`scm-releases`**`(WEBSITE_CONTENTAZUREFILECONNECTIONSTRING` and `WEBSITE_CONTENTSHARE`)
 
 With permissions to read the containers inside the Storage Account that stores the function data it's possible to find the container **`scm-releases`**. In there it's possible to find the latest release in **Squashfs filesystem file format** and therefore it's possible to read the code of the function:

pentesting-cloud/azure-security/az-services/az-function-apps.md

@@ -17,57 +17,71 @@ Learn & practice GCP Hacking: <img src="../../../.gitbook/assets/image (2) (1).p
 
 ## Basic Information
 
-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.
+**Azure Function Apps** are a **serverless compute service** that allow you to run small pieces of code, called **functions**, without managing the underlying infrastructure. They are designed to execute code in response to various triggers, such as **HTTP requests, timers, or events from other Azure services** like Blob Storage or Event Hubs. Function Apps support multiple programming languages, including C#, Python, JavaScript, and Java, making them versatile for building **event-driven applications**, automating workflows, or integrating services. They are cost-effective, as you usually only pay for the compute time used when your code runs.
 
 ### Different Plans
 
-* 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.
+* **Flex Consumption Plan**: Offers **dynamic, event-driven scaling** with pay-as-you-go pricing, adding or removing function instances based on demand. It supports **virtual networking** and **pre-provisioned instances** to reduce cold starts, making it suitable for **variable workloads** that don’t require container support.
+* **Traditional Consumption Plan**: The default serverless option, where you **pay only for compute resources when functions run**. It automatically scales based on incoming events and includes **cold start optimizations**, but does not support container deployments. Ideal for **intermittent workloads** requiring automatic scaling.
+* **Premium Plan**: Designed for **consistent performance**, with **prewarmed workers** to eliminate cold starts. It offers **extended execution times, virtual networking**, and supports **custom Linux images**, making it perfect for **mission-critical applications** needing high performance and advanced features.
+* **Dedicated Plan**: Runs on dedicated virtual machines with **predictable billing** and supports manual or automatic scaling. It allows running multiple apps on the same plan, provides **compute isolation**, and ensures **secure network access** via App Service Environments, making it ideal for **long-running applications** needing consistent resource allocation.
+* **Container Apps**: Enables deploying **containerized function apps** in a managed environment, alongside microservices and APIs. It supports custom libraries, legacy app migration, and **GPU processing**, eliminating Kubernetes cluster management. Ideal for **event-driven, scalable containerized applications**.
 
 ### **Storage Buckets**
 
 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**.
+Moreover, modifying the code inside the bucket (in the different formats it could be stored), the **code of the app will be modified to the new one and executed** next time the Function is called.
 
 {% hint style="danger" %}
 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.
+
+More on this in the **privilege escalation section**.
 {% endhint %}
 
 It's also possible to find the **master and functions keys** stored in the storage account in the container **`azure-webjobs-secrets`** inside the folder **`<app-name>`** in the JSON files you can find inside.
 
+Note that Functions also allow to store the code in a remote location just indicating the URL to it.
+
 ### Networking
 
-* 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
+Using a HTTP trigger:
+
+* It's possible to give **access to a function to from all Internet** without requiring any authentication or give access IAM based. Although it’s also possible to restrict this access.
+* It's also possible to **give or restrict access** to a Function App from **an internal network (VPC)**.
 
 {% hint style="danger" %}
-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.
+This is very interesting from an attackers perspective as it might be possible to **pivot to internal networks** from a vulnerable Function exposed to the Internet.
 {% endhint %}
 
 ### **Function App Settings & Environment Variables**
 
-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**.
+It's possible to configure environment variables inside an app, which could contain sensitive information. 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**. These settings are also needed to execute the code from the Storage Account.
+
+These env variables or configuration parameters also controls how the Function execute the code, for example if **`WEBSITE_RUN_FROM_PACKAGE`** exists, it'll indicate the URL where the code of the application is located.
 
 ### **Function Sandbox**
 
-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).
+Inside the linux 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).
 
-### **Managed Identities**
+In a **Windows** function using NodeJS the code was located in **`C:\home\site\wwwroot\HttpTrigger1\index.js`**, the username was **`mawsFnPlaceholder8_f_v4_node_20_x86`** and was part of the **groups**: `Mandatory Label\High Mandatory Level Label`, `Everyone`, `BUILTIN\Users`, `NT AUTHORITY\INTERACTIVE`, `CONSOLE LOGON`, `NT AUTHORITY\Authenticated Users`, `NT AUTHORITY\This Organization`, `BUILTIN\IIS_IUSRS`, `LOCAL`, `10-30-4-99\Dwas Site Users`.
+
+### **Managed Identities & Metadata**
 
 Just like [**VMs**](vms/), Functions can have **Managed Identities** of 2 types: System assigned and User assigned.
 
-The **system assigned** on will be a managed identity that **only the function** that has it assigned will be able to use, while the **user assigned** managed identities are managed identities that **any other Azure service will be able to use**.
+The **system assigned** one will be a managed identity that **only the function** that has it assigned would be able to use, while the **user assigned** managed identities are managed identities that **any other Azure service will be able to use**.
 
 {% hint style="info" %}
 Just like in [**VMs**](vms/), Functions can have **1 system assigned** managed identity and **several user assigned** ones, so it's always important to try to find all of them if you compromise the function because you might be able to escalate privileges to several managed identities from just one Function.
 {% endhint %}
 
+It's possible to use the [**PEASS scripts**](https://github.com/peass-ng/PEASS-ng) to get tokens from the default managed identity from the metadata endpoint. Or you could get them manually as explained in:
+
+{% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#azure-vm" %}
+
+Note that you need to find out a way to **check all the Managed Identities a function has attached** as if you don't indicate it, the metadata endpoint will **only use the default one** (check the previous link for more info).
+
 ## Access Keys
 
 {% hint style="info" %}
@@ -82,11 +96,10 @@ When creating an endpoint inside a function using a **HTTP trigger** it's possib
 
 **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.
+* **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 allowing a more fine-grained access over the endpoints.
+* **Host Keys:** Host keys, which can also be default or user-defined, provide access to **all function endpoints within a Function App with FUNCTION access level**.
+* **Master Key:** The master key (`_master`) serves as an administrative key that offers elevated permissions, including access to all function endpoints (ADMIN access lelvel included). This **key cannot be revoked.**
+* **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.
 
 {% hint style="success" %}
 Example to access a function API endpoint using a key: