Azure Function Apps: The Hidden Dangers of Overexposed HTTP Triggers

Introduction

Azure Function Apps are a cornerstone of serverless computing in Microsoft Azure. They allow developers to run lightweight, event-driven workloads without the complexity of managing infrastructure. One of the most powerful and widely used triggers in Function Apps is the HTTP trigger, enabling developers to create APIs, webhooks, and integrations quickly.

However, if not configured securely, HTTP-triggered Function Apps can expose your applications to exploitation, potentially leading to unauthorized data access, service abuse, or costly denial-of-service attacks. This blog explores the risks of overexposed HTTP triggers, how attackers exploit these vulnerabilities, and what you can do to secure them effectively.

What is an Azure Function App?

Azure Function App is a serverless compute platform for running small pieces of code in response to events. These events could range from database updates to HTTP requests. Function Apps enable developers to deploy event-driven solutions while focusing solely on the code logic, as Azure takes care of scaling and underlying infrastructure.

How HTTP Triggers Work in Azure Function Apps

HTTP triggers are one of the most popular ways to invoke Azure Functions. They allow a function to be accessed via a RESTful API endpoint, using standard HTTP methods like GET, POST, PUT, and DELETE.

Endpoint Example:
A function URL might look like:
https://<function-app-name>.azurewebsites.net/api/<function-name>?code=<function-key>

Authorization Levels:
HTTP-triggered functions use three levels of authorization to control access:

1. Anonymous: No authentication is required, making the endpoint publicly accessible.
2. Function: Requires a function-specific key to access.
3. Admin: Requires the master key, granting full access to all functions within the Function App.

While "Anonymous" is suitable for public APIs, functions containing sensitive logic or accessing critical resources should never be left exposed without protection.

Here's an example of creating a simple HTTP-triggered Function:

If misconfigured, such endpoints could be accessed by unauthorized users, leading to potential abuse.

Attacker Methodology

When Azure Function Apps with HTTP triggers are misconfigured, they can become an easy target for attackers. Below, we delve deeper into the attack lifecycle, including common techniques and tools used by attackers to exploit these vulnerabilities.

Common Misconfigurations Leading to Vulnerabilities

1. Exposing Endpoints with "Anonymous" Access: Attackers target endpoints configured with Anonymous Authentication levels since they don’t require authentication. Publicly accessible APIs without adequate safeguards are prime targets.
2.  Leaked Function Keys: Function keys (Function or Admin) may be accidentally exposed in:
   • Code repositories (e.g., GitHub).
   • Browser developer tools, when keys are passed as query parameters.
   • Logs or error messages.
   • These leaked keys can be reused by attackers to invoke functions and potentially escalate access.
3. Unrestricted Network Access: No IP restrictions or firewall rules allow unrestricted access to Function Apps from anywhere on the internet. This creates opportunities for attackers to perform reconnaissance or launch brute-force or DoS attacks.
4. Improper Input Validation: Functions that process HTTP requests without validating query parameters or request bodies are vulnerable to:
   • SQL Injection: Exploiting downstream databases.
   • Command Injection: Executing malicious commands on the system.
5. Lack of Monitoring and Alerting: Without proper logging or alerts, malicious activity can go undetected until significant damage is done.

How Attackers Exploit These Vulnerabilities

1. Discovery of Vulnerable Endpoints:
   • Automated Scanning: Attackers use tools like nmap or specialized scripts to scan Azure IP ranges for exposed HTTP-triggered Function Apps.
   • Shodan Searches: Shodan.io, a search engine for internet-connected devices, is often used to discover exposed endpoints and APIs.
   • Guessable Endpoints: Function URLs often follow predictable naming conventions (e.g., /api/<function-name>), making them easier to target.
2. Key Harvesting:
   • If Function or Admin keys are embedded in client-side code or accidentally exposed in repositories, attackers use these keys to authenticate and invoke sensitive functions.
3. Launching Exploits:
   • Denial-of-Service (DoS): Attackers flood the function endpoint with requests, exploiting the auto-scaling nature of Azure Functions to drive up costs or exhaust available resources. Example Command: ab -n 10000 -c 100 https://<function-app>.azurewebsites.net/api/ProcessData
   • Injection Attacks: Poorly validated functions are targeted with malicious payloads to exfiltrate data or compromise the system. Example Payload: curl -X POST -H "Content-Type: application/json" \ -d '{"data": "SELECT * FROM Users; DROP TABLE Users;"}' \ https://<function-app>.azurewebsites.net/api/ProcessData.
4. Lateral Movement:
   • Identifying an Azure Function App that has an attached Managed Identity. Querying the identity to determine its permissions.

Attack Tactics, Techniques, and Procedures (TTPs) and MITRE ATT&CK Mapping

The following table maps attacker behaviors to MITRE ATT&CK techniques for better understanding and categorization of threats.

• Initial Access (T1190): Exploiting Public-Facing Applications
  Attackers gain access by exploiting misconfigured HTTP-triggered Function Apps or accessing exposed endpoints.
• Discovery (T1018): Remote System Discovery
  Scanning for Azure Function Apps with Managed Identities and determining their permissions to identify potential targets for lateral movement.
• Privilege Escalation (T1068): Exploitation for Privilege Escalation
  Using the Managed Identity’s roles (e.g., Key Vault Secrets User) to gain unauthorized access to resources like Azure Key Vault.
• Credential Access (T1552.001): Credentials in Files
  Retrieving sensitive credentials, secrets, or tokens stored in Azure Key Vault using over-permissioned Managed Identities.
• Lateral Movement (T1210): Exploitation of Remote Services
  Accessing other Azure resources such as Storage Accounts, Key Vaults, or VMs by leveraging the Managed Identity’s permissions.
• Defense Evasion (T1078): Valid Accounts
  Using legitimate Managed Identity tokens to perform malicious operations, blending in with normal operations and avoiding detection.
• Impact (T1499): Endpoint Denial-of-Service
  Flooding Function App endpoints or leveraging their Managed Identities to execute costly or disruptive operations on Azure resources.

Attack Walkthrough

Scenario A:

Step 1: Discover the Vulnerable Function

The attacker scans Azure IP ranges for HTTP endpoints with tools like nmap: nmap -p 443 --script=http-title <Azure-Subnet-IP-Range>

Step 2: Invoke the Function Using Default or Exposed Settings

The attacker sends a crafted HTTP request to a publicly accessible function: curl -X POST https://<function-app>.azurewebsites.net/api/ProcessData \ -H "Content-Type: application/json" \ -d '{"username": "admin", "password": "password"}'

Step 3: Exploit for Sensitive Data

If the function interacts with a database or Key Vault, the attacker exploits this connection: curl -X POST https://<function-app>.azurewebsites.net/api/GetSecret \ -H "Authorization: Bearer <leaked-key>" \ -d '{"vaultName": "critical-vault"}'

Step 4: Persist Access or Cause Impact

The attacker continues invoking the function for lateral movement, privilege escalation, or denial-of-service.

Scenario B:

Step 1: Identify the Azure Function App 

The attacker identifies a vulnerable Function App with an attached Managed Identity, either through reconnaissance or after compromising an environment. For example, the attacker could use Azure CLI to enumerate Function Apps if they have access to the subscription: az functionapp list --query "[].{Name:name, Identity:identity}" -o table

This command reveals which Function Apps are using Managed Identities.

Step 2: Use the Function App’s Managed Identity 

The attacker compromises the Function App (e.g., via a leaked key or public access) and uses the Managed Identity assigned to it to acquire a token for Azure Resource Manager (ARM).

Obtain a Token: The attacker calls the Managed Identity endpoint to retrieve a token: curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2019-08-01&resource=https://management.azure.com" | jq

This returns an access_token tied to the Managed Identity.

List the Managed Identity's Permissions: The attacker uses the token to enumerate the identity's permissions: curl -H "Authorization: Bearer <access_token>" \ -H "Content-Type: application/json" \   https://management.azure.com/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleAssignments?api-version=2021-04-01

This reveals the roles assigned to the Managed Identity, such as Reader, Contributor, or custom roles.

Step 3: Access Other Azure Resources 

If the Managed Identity has permission to other resources, the attacker can now interact with them.

Access Key Vault Secrets: If the identity has the Key Vault Secrets User or Key Vault Secrets Officer role, the attacker can list and retrieve secrets:
# List Key Vault secrets

az keyvault secret list --vault-name <key-vault-name> --subscription <subscription-id>

# Retrieve a specific secret

az keyvault secret show --name <secret-name> --vault-name <key-vault-name>

Access Storage Accounts: If the identity has access to a storage account, the attacker can list or download blobs: az storage blob list --container-name <container-name> --account-name <storage-account-name> --auth-mode login --subscription <subscription-id>

Execute Privileged Operations: With roles like Contributor or Owner, the attacker can perform destructive or privilege-escalating operations such as modifying infrastructure, creating new resources, or adding additional permissions.

Investigating and Uncovering Threats

1. Monitor Function Activity:
   • Use Application Insights to track failed requests, high-frequency invocations, or unauthorized access attempts.
2. Audit Function Keys:
   • Check for leaked function keys in logs, codebases, or other publicly accessible repositories.
3. Analyze IP Traffic:
   • Use Azure Monitor and Network Watcher to identify unusual patterns in traffic or geographic anomalies.

Challenges in Investigation

1. Volume of Logs:
   • High traffic on public-facing endpoints can generate overwhelming log data, complicating investigations.
2. Skill Gaps:
   • Investigating serverless systems requires expertise in Azure security and monitoring tools.

How to Mitigate the Issue

1. Set Secure Authorization Levels:
   • Use Function or Admin authorization levels for sensitive functions.
   • Avoid Anonymous unless absolutely necessary for public APIs.
2. Implement Azure AD Authentication:
   • Secure your function with Azure AD-based OAuth2 authentication for robust identity control.
3. Restrict Network Access:
   • Use Access Restrictions to allow traffic only from trusted IP ranges or VNets.
4. Enable Rate Limiting:
   • Implement API throttling with Azure API Management or custom logic to prevent DoS attacks.
5. Encrypt Secrets:
   • Store keys and connection strings in Azure Key Vault instead of hardcoding them.
6. Validate Inputs:
   • Sanitize all inputs to prevent injection attacks or unexpected payloads.