TL;DR

Token Security researchers have discovered several Azure built-in roles that are misconfigured to be over-privileged - they grant more permissions than intended by Azure.
In addition, we discovered another vulnerability in the Azure API that allows attackers to leak VPN keys.

Combined, these two issues create a new attack chain that lets a weak user gain access to both internal cloud assets and on-premises networks.

In this report, we detail the research process that led to the discoveries, their implications, and what organizations can do to stay safe against these threats and other identity-driven attacks.

What is Azure RBAC?

Before jumping in, let’s discuss some basics.
Azure’s permissions model, Azure RBAC (Role-Based Access Control), is, as the name states, based on roles.
Roles are basically groups of permissions that can be assigned to principals (users, service principals, groups, etc). When granting a role to a principal, you create a role assignment.
‍Every role assignment contains three main components:

1. Security Principal - Who is given the permissions?
2. Role Definition - Which role is assigned? What permissions does it grant? This section states the name of the role and the Actions and Not Actions (allow or deny) that this role is granting.
3. Scope - What resources is the principal given access to? The scope can be vast, such as an entire management group or subscription, or more specific, like a resource group or a single resource (e.g., a specific VM or storage account).

Azure roles

In Azure, there are more than 400 built-in roles, which can be divided into 2 categories:

1. Generic - Roles that grant permissions that apply across all resources and all Azure services in the given scope (e.g., Contributor, Owner, Reader, etc.)
2. Service-specific - Roles that grant permissions for a specific service or function in the given scope (e.g., Storage Blob Data Reader or Virtual Machine Contributor).

If you assign the Contributor role over a subscription scope, it will grant permissions to perform actions over all of the resources in this subscription, regardless if they’re storage accounts, virtual machines, or any other resource. But if you assign the Virtual Machine Contributor, it will grant these permissions only to perform actions over virtual machines in the subscription.
So we can see the tradeoff here: using service-specific roles is the more secure approach, since you are granting fewer permissions, but the generic roles are easier to use since you need to manage fewer roles assignments.

The Problem

Let’s take a look at few roles and their permissions. See if you can tell where things go wrong.

The Reader role

One of Azure’s built-in roles, called Reader, is a generic role. As you’d expect, it gives read-only permissions over the resources in the chosen scope. Let’s examine its role definition:

{
  "assignableScopes": [
    "/"
  ],
  "description": "View all resources, but does not allow you to make any changes.",
  "id": "/providers/Microsoft.Authorization/roleDefinitions/acdd72a7-3385-48ef-bd42-f606fba81ae7",
  "name": "acdd72a7-3385-48ef-bd42-f606fba81ae7",
  "permissions": [
    {
      "actions": [
        "*/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Reader",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

As we can see in the actions property, the permission given is */read, which means it lets you perform any read action in the given scope.

*Note that this does not include data actions (reading data objects like files in storage accounts, key vault secrets, etc). Those require different, service-specific sensitive permissions.

Okay, so a generic role giving generic read permissions, that makes sense.
What about the permissions of service-specific roles?

Workbook Reader

{
  "assignableScopes": [
    "/"
  ],
  "description": "Can read workbooks.",
  "id": "/providers/Microsoft.Authorization/roleDefinitions/b279062a-9be3-42a0-92ae-8b3cf002ec4d",
  "name": "b279062a-9be3-42a0-92ae-8b3cf002ec4d",
  "permissions": [
    {
      "actions": [
        "microsoft.insights/workbooks/read",
        "microsoft.insights/workbooks/revisions/read",
        "microsoft.insights/workbooktemplates/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Workbook Reader",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

If we analyze the actions property, we can see that as the description states, it grants read permissions to a few workbook-related objects. So a service-specific role that grants access to a specific service! So far so good.

Managed Applications Reader

Now, let’s check the Managed Applications Reader role, which its description is “Lets you read resources in a managed app and request JIT access.”

{
  "assignableScopes": [
    "/"
  ],
  "description": "Lets you read resources in a managed app and request JIT access.",
  "id": "/providers/Microsoft.Authorization/roleDefinitions/b9331d33-8a36-4f8c-b097-4f54124fdb44",
  "name": "b9331d33-8a36-4f8c-b097-4f54124fdb44",
  "permissions": [
    {
      "actions": [
        "Microsoft.Resources/deployments/*",
        "Microsoft.Solutions/jitRequests/*",
        "*/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  "roleName": "Managed Applications Reader",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

We can see it has access to deployments, jitRequests, and… read everything???
‍So this role, which is supposed to grant access to read managed apps and JIT access, actually also allows the user to read every Azure resource?
This is clearly not what the description says, and certainly not what someone assigning the Managed Applications Reader role would expect.

Essentially, the role’s name and description are misleading the user into thinking the role grants specific permissions, when in fact it grants generic permissions to every resource.

How bad is it?

I saw this and thought to myself, okay, this is just a read permission... how bad can it be?
Well, I was seriously wrong.

Let’s dive into what we can actually do with this permission and how can it be useful for an attacker.

Since there are so many actions possible here, I divided them into three categories and gave some examples for each.