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

Az - Function Apps

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

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.

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.

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.

{% 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. {% 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.

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

{% 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. {% 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.

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).

Managed Identities

Just like 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.

{% hint style="info" %} Just like in 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 %}

Access Keys

{% hint style="info" %} 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. {% endhint %}

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.

{% hint style="success" %} Example to access a function API endpoint using a key:

https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key> {% endhint %}

Github Based Deployments

When a function is generated from a Github repo Azure web console allows to automatically create a Github Workflow in a specific repository so whenever this repository is updated the code of the function is updated. Actually the Github Action yaml for a python function looks like this:

Github Action Yaml

# Docs for the Azure Web Apps Deploy action: https://github.com/azure/functions-action
# More GitHub Actions for Azure: https://github.com/Azure/actions
# More info on Python, GitHub Actions, and Azure Functions: https://aka.ms/python-webapps-actions

name: Build and deploy Python project to Azure Function App - funcGithub

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  AZURE_FUNCTIONAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root
  PYTHON_VERSION: '3.11' # set this to the python version to use (supports 3.6, 3.7, 3.8)

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Python version
        uses: actions/setup-python@v5
        with:
          python-version: ${{ env.PYTHON_VERSION }}

      - name: Create and start virtual environment
        run: |
          python -m venv venv
          source venv/bin/activate

      - name: Install dependencies
        run: pip install -r requirements.txt

      # Optional: Add step to run tests here

      - name: Zip artifact for deployment
        run: zip release.zip ./* -r

      - name: Upload artifact for deployment job
        uses: actions/upload-artifact@v4
        with:
          name: python-app
          path: |
            release.zip
            !venv/

  deploy:
    runs-on: ubuntu-latest
    needs: build
    
    permissions:
      id-token: write #This is required for requesting the JWT

    steps:
      - name: Download artifact from build job
        uses: actions/download-artifact@v4
        with:
          name: python-app

      - name: Unzip artifact for deployment
        run: unzip release.zip     
        
      - name: Login to Azure
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZUREAPPSERVICE_CLIENTID_6C3396368D954957BC58E4C788D37FD1 }}
          tenant-id: ${{ secrets.AZUREAPPSERVICE_TENANTID_7E50AEF6222E4C3DA9272D27FB169CCD }}
          subscription-id: ${{ secrets.AZUREAPPSERVICE_SUBSCRIPTIONID_905358F484A74277BDC20978459F26F4 }}

      - name: 'Deploy to Azure Functions'
        uses: Azure/functions-action@v1
        id: deploy-to-function
        with:
          app-name: 'funcGithub'
          slot-name: 'Production'
          package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
          

Moreover, a Managed Identity is also created so the Github Action from the repository will be able to login into Azure with it. This is done by generating a Federated credential over the Managed Identity allowing the Issuer https://token.actions.githubusercontent.com and the Subject Identifier repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>.

{% hint style="danger" %} Therefore, anyone compromising that repo will be able to compromise the function and the Managed Identities attached to it. {% endhint %}

Enumeration

{% code overflow="wrap" %}

# List all the functions
az functionapp list

# Get info of 1 funciton (although in the list you already get this info)
az functionapp show --name <app-name> --resource-group <res-group>

# Get details about the source of the function code
az functionapp deployment source show \
  --name <app-name> \
  --resource-group <res-group>
  
# Get settings (and privesc to the sorage account)
az functionapp config appsettings list --name <app-name> --resource-group <res-group>

# Check if a domain was assigned to a function app
az functionapp config hostname list --webapp-name <app-name> --resource-group <res-group>

# Get SSL certificates
az functionapp config ssl list --resource-group <res-group>

# Get network restrictions
az functionapp config access-restriction show --name <app-name> --resource-group <res-group>

# Get more info about a function (invoke_url_template is the URL to invoke and script_href allows to see the code)
az rest --method GET \
  --url "https://management.azure.com/subscriptions/<subscription>/resourceGroups/<res-group>/providers/Microsoft.Web/sites/<app-name>/functions?api-version=2024-04-01"

# Get source code with Master Key of the function
curl "<script_href>?code=<master-key>"
## Python example
curl "https://newfuncttest123.azurewebsites.net/admin/vfs/home/site/wwwroot/function_app.py?code=<master-key>" -v
  
# Get source code
az rest --url "https://management.azure.com/<subscription>/resourceGroups/<res-group>/providers/Microsoft.Web/sites/<app-name>/hostruntime/admin/vfs/function_app.py?relativePath=1&api-version=2022-03-01"

{% endcode %}

Privilege Escalation

{% content-ref url="../az-privilege-escalation/az-functions-app-privesc.md" %} az-functions-app-privesc.md {% endcontent-ref %}

References

• https://learn.microsoft.com/en-us/azure/azure-functions/functions-openapi-definition

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}