Permission Impossible: Hidden Dangers of Azure RBAC and API Vulnerabilities

Permission Impossible: Hidden Dangers of Azure RBAC and API Vulnerabilities

Speakers: Ariel Simon, Security Researcher, Token Security

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=u-fJ6EbfrYc

Overview

Ariel Simon, a security researcher at Token Security, presented a two-part discovery in Azure's permission model that chains overprivileged built-in roles with an API vulnerability to achieve a novel attack: escalating from a weak cloud user with read-only permissions to full on-premises network compromise. The first finding reveals that 10 Azure built-in roles — including seemingly innocuous roles like "Log Analytics Reader" and "Managed Applications Reader" — secretly grant */read permissions across all Azure control plane resources, far exceeding their documented scope. The second finding is an API vulnerability where a VPN gateway endpoint that returns a pre-shared key (PSK) was implemented using an HTTP GET method instead of POST, bypassing Azure's permission enforcement for secret access. Combined, these allow any user assigned one of the overprivileged roles to steal VPN credentials and establish a site-to-site VPN connection into internal networks. Microsoft confirmed the API vulnerability as important severity and patched it.

Background

▶ Watch: Discovering the Managed Applications Reader role secretly includes */read per... (3:30)

Azure Role-Based Access Control (RBAC) is the permissions model for Azure resources. Roles can be divided into built-in roles (predefined by Microsoft) and custom roles (created by customers). Built-in roles further divide into generic roles (like Contributor or Reader, which grant permissions across all resource types) and service-specific roles (like Virtual Machine Contributor, which scope permissions to a specific service). Best practice dictates using service-specific roles for least-privilege access.

Each role is defined by a JSON role definition that specifies permitted actions. The */read permission grants read access to the control plane metadata of every Azure resource type — a permission that belongs to the generic Reader role. Azure's documentation states that identities with read permissions "should not be allowed to read secrets," as secrets could be used for privilege escalation. To enforce this, Microsoft uses HTTP method-based permission checks: GET requests are permitted for read-scoped identities, while POST requests require write permissions. Secret-returning APIs (like storage account list keys) are implemented with POST despite having no request body and making no changes, specifically to prevent read-only identities from accessing them.

Key Findings

▶ Watch: Ten overprivileged built-in roles identified — Microsoft generous with permis... (8:00)

**Ten Azure built-in service-specific roles contain */read permissions.** Simon discovered that roles marketed as scoped to specific services actually include the wildcard /read permission, making them functionally equivalent to the Reader role for control plane access. The Managed Applications Reader role, described as "lets you read resources in a managed app and request just-in-time access," includes /read alongside its service-specific permissions. The App Compliance Automation Reader, described as "read downloaded reports objects and related other resource objects," has only /read as its permission — making it identical to the full Reader role. The Managed Application Operator role includes both /read and a service-specific read permission that is already a subset of */read, indicating a developer error during role creation.

**The */read permission enables 9,618 operations across Azure. Using the azadvertizer.net** resource (which indexes all Azure and Entra permissions), Simon enumerated every operation matching the */read wildcard and found a staggering 9,618 possible operations. These fall into three exploitation categories: sensitive data discovery (enumerating storage accounts, containers, databases, backup vaults, and resource locks that reveal where production data lives), attack planning (reading role assignments for privilege escalation paths, diagnostic settings for detection avoidance, network configurations, and firewall rules), and credential theft (reading deployment scripts, web application source code, and automation account runbook scripts that frequently contain embedded credentials).

The VPN gateway shared key API is implemented with GET instead of POST. Among those 9,618 read operations, Simon identified Microsoft.Network/connections/sharedkey/read — the API to retrieve the pre-shared key for Azure VPN Gateway site-to-site connections. This API returns a secret (the PSK needed to establish a VPN tunnel), but it was implemented with HTTP GET rather than POST, meaning Azure's HTTP-method-based permission check does not block read-only identities from accessing it. This is the specific API vulnerability that Microsoft confirmed and patched.

Technical Deep Dive

▶ Watch: Root cause: Azure uses HTTP method (GET vs POST) to enforce secret access per... (12:00)

The root cause of the API vulnerability lies in Azure's permission enforcement architecture. Rather than checking specific RBAC permissions per API endpoint, Azure uses HTTP method as a proxy: GET maps to read permissions, POST maps to write permissions. This works correctly for most APIs — listing VMs (GET, no body, read-only) and installing patches (POST, has body, changes state). For secret-returning APIs, the convention is to use POST even when the semantics would naturally call for GET (no body, no state change), specifically to prevent read-only access.

The failure occurs when an Azure developer implements a new secret-returning API with GET — the method that makes semantic sense but bypasses the permission check. The VPN gateway connections/sharedkey API is exactly this case: it returns a secret (the pre-shared key for a site-to-site VPN), has no request body, and changes no state, so the implementing developer naturally used GET. But this means any identity with */read can call it.

The Azure VPN Gateway service implements VPN connectivity for two common enterprise scenarios: connecting two on-premises networks and connecting an on-premises network to an Azure VPC. A site-to-site VPN connection requires only the pre-shared key to establish. With the leaked PSK, an attacker can configure any VPN client to establish a tunnel, gaining network-level access to resources in the connected VPCs and on-premises networks — including Active Directory servers, internal file shares, databases accessible only from within the VPC, and employee workstations.

The full attack chain proceeds: an attacker with any of the 10 overprivileged roles (or the generic Reader role) calls the VPN gateway shared key API via GET, retrieves the pre-shared key, configures a VPN client with the stolen key, establishes a site-to-site connection, and gains network access to all resources reachable through the VPN tunnel — potentially including on-premises infrastructure.

Demo / Proof of Concept

▶ Watch: VPN pre-shared key returned via GET — the API vulnerability that breaks the m... (14:30)

Simon demonstrated the full attack chain in a live video. Starting with an identity that had no roles assigned (resulting in an authorization failure when attempting to fetch the VPN key), he assigned the Log Analytics Reader role — a role with no relation to VPN or networking services. The curl request to the VPN shared key API then succeeded, returning the pre-shared key. He pasted the key into a VPN client configuration on an attacker VM, restarted the VPN service, and confirmed the connection was established — demonstrating network-level access to the internal environment from a role that should only allow reading log analytics data.

Defensive Implications

▶ Watch: Microsoft's response: fixed the docs instead of the overprivileged roles (18:00)

Microsoft's response was split. For the overprivileged roles, Microsoft stated it is "not a security issue" because the /read permission is documented (though only after significant documentation updates prompted by Simon's report). The description of the Managed Applications Reader was updated to explicitly state "This role includes the /read action for the control plane." The VPN PSK leak was initially also rejected, but upon appeal, Microsoft reassessed it as an important severity vulnerability, awarded a bounty, and patched it by adding a new specific permission requirement for the API endpoint.

Defenders should take the following actions:

• Audit all role assignments for the 10 overprivileged built-in roles and replace them with custom roles that grant only the specific permissions needed. The affected roles include Managed Applications Reader, Managed Application Operator, Log Analytics Reader, and App Compliance Automation Reader, among others.
• Use custom roles with narrow scopes rather than relying on built-in service-specific roles, which may contain unexpected wildcard permissions.
• Rotate VPN pre-shared keys if any of the overprivileged roles were previously assigned in scopes that include VPN gateway resources. While the API vulnerability is patched, historical key exposure may have occurred.
• Monitor for unexpected VPN connections by auditing VPN gateway connection logs for new tunnels from unrecognized endpoints.
• Apply the principle of least privilege rigorously — assign roles at the narrowest possible scope (resource group or individual resource) rather than subscription or management group level.

Key Takeaways

• Ten Azure built-in service-specific roles secretly grant */read across all control plane resources, far exceeding their intended scope.
• The */read permission enables 9,618 operations including sensitive data discovery, attack planning, and credential theft from deployment scripts and automation runbooks.
• Azure enforces secret access via HTTP method (POST for secrets) rather than explicit permission checks, creating vulnerabilities when developers implement secret-returning APIs with GET.
• The VPN gateway pre-shared key leak enabled escalation from read-only cloud user to on-premises network compromise — a novel cross-boundary attack chain.
• Microsoft fixed the API vulnerability but did not fix the overprivileged roles, shifting responsibility to customers to use custom roles.
• Always audit built-in role definitions rather than trusting descriptions — documentation may not accurately reflect actual permissions.

About the Speaker(s)

Ariel Simon is a security researcher at Token Security, a Tel Aviv-based startup focused on managing and securing non-human identities. He has eight years of experience in security research, with a focus on cloud security and vulnerability research. This research was conducted over several months and resulted in a confirmed important-severity vulnerability from Microsoft's Security Response Center, along with a bounty award.