通过滥用服务主体进行 Azure 权限提升

简介和前期工作

本地Active Directory 将继续存在，Azure Active Directory 也是如此。虽然这些产品的名称相似，但实际上它们的工作方式截然不同。Azure 中存在原始 AD 的自主访问控制模型的痕迹，但 Azure 中的权限主要通过授予角色来控制。无论这些差异如何，基于配置的攻击原语在 Azure 中仍然活跃且有效，研究人员一直在 Azure 中发现新的攻击原语。

在这篇博文中，我将解释基于 Azure 的 RBAC 系统，Azure 中如何出现一种特殊的攻击路径 — — 我们在访问过的绝大多数 Azure 租户中都看到了这种攻击路径。我将向您展示攻击原语的工作原理、如何保护自己免受攻击，并就这给 Microsoft 带来的机会提供我自己的评论。

这项工作并不新鲜——事实上，微软自己的文档描述了这些攻击路径。此外，一些优秀的研究人员已经详细讨论了这种攻击原语：

Dirk-jan Mollema撰写了关于滥用应用程序管理员角色为服务主体添加新机密并提升权限的文章，网址：https: //dirkjanm.io/azure-ad-privilege-escalation-application-admin/

Karl Fosaaen在此次演讲中谈到了 Azure 权限提升技术：https://www.netspi.com/webinars/lunch-learn-webinar-series/adventures-in-azure-privilege-escalation/

Emilian Cebuc和Christian Philipov在本次演讲中描述了如何滥用服务主体在 Azure 租户中升级：https://www.youtube.com/watch?v =QwVApszlIdY

Azure 的内置特权预防系统

在讨论基于服务主体的特权升级之前，我想先介绍一下 Azure 内置的攻击路径预防系统。Azure Active Directory 有一个内置系统，可以防止攻击路径的出现，尤其是围绕密码重置特权的攻击路径。查看提供密码重置特权的管理员角色的文档时，您经常会看到这样的措辞：

来源：https: //docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference#helpdesk-administrator

特别要注意突出显示的文本：“帮助台管理员是否可以重置用户密码并使刷新令牌无效取决于为用户分配的角色。”

对我来说，这很令人困惑。因此，我开始了解 Azure 中密码重置权限的所有不同可能性，并最终创建了以下表格：

这带来了一些清晰度，但是看看当我们使用图表对这些权限进行建模时会发生什么：

这时，这个系统的高明之处终于显现出来了。查看第一行，我们可以看到全局管理员和特权身份验证管理员可以重置彼此的密码以及所有其他用户的密码，但反之则不然。换句话说，只有GA 和 PAA 用户可以重置 GA 密码。这是后端 Azure 系统的一部分，Azure 管理员无法控制。

我喜欢这个系统，因为它为管理员提供了高效、不可配置、无摩擦的安全措施，可防止出现包括重置全局管理员密码在内的攻击路径。Azure 管理员可以安全地分配“密码管理员”角色，而不必担心其全局管理员的安全 — 至少在此特定攻击原语的上下文中。

通过滥用服务主体来提升权限

在 Azure 租户中创建或注册应用程序时，将创建一个具有唯一应用程序（客户端）ID 的应用程序对象：

在这里，应用程序“MyCoolApp”具有以 d6f118bc 开头的唯一标识符。在其下方，您还可以看到我的租户的 ID。此应用程序对象“驻留在”我的租户内。让我们开始从图表的角度来思考这个问题，看看攻击路径是如何出现的：

由于该应用“驻留在”我的租户中，因此任何能够控制我的租户的人都可以控制该应用。让我们通过展示我自己的全局管理员用户如何控制租户来对此进行建模：

这里没什么可怕的：我的用户是租户的全局管理员，租户包含应用程序，因此这里的“路径”是我可以控制应用程序。现在让我们扩展此模型以包含服务主体。

需要向租户进行身份验证才能执行某些操作的 Azure 应用使用名为“服务主体”的对象来执行此操作。服务主体的工作方式类似于用户 - 您使用“用户名”（对象 ID）和“密码”（证书或机密）向租户进行身份验证。您可以在此屏幕截图中看到应用服务主体的对象 ID：

让我们继续将其添加到我们的图形模型中：

再说一次，这里没有什么奇怪的：我的全局管理员用户可以控制这里的一切。

服务主体可以像用户一样在 Azure 中拥有管理员角色。例如，我们已经看到几个 Azure 环境，其中至少一个服务主体具有特权角色管理员角色。让我们在我自己的租户中重新创建它：

让我们扩展图形模型来包含以下内容：

再说一遍，没什么可怕的：从全局管理员到 PRA 角色的攻击路径不是问题。让我们将另一个用户引入其中：Alice App Admin。正如用户的名称所暗示的那样，我们将授予此用户在我的租户中的“应用程序管理员”角色：

我们还将这个用户及其角色分配添加到我们的图形模型中：

就这样……我们的攻击路径出现了，将 Alice App Admin 用户与 PRA 角色联系起来。攻击路径的工作方式如下：

• Alice App Admin 具有应用程序管理员角色，范围限定为租户。

• 租户包含 MyCoolApp 应用程序，授予 Alice App Admin 对该应用程序的控制权。

• Alice App Admin 可以为该应用程序的服务主体添加新的机密。

• MyCoolApp 以 MyCoolApp 服务主体的身份向租户进行身份验证。

• MyCoolApp 服务主体具有 PRA 角色。

• Alice App Admin 可以作为 MyCoolApp 服务主体向租户进行身份验证，并使用该服务主体的权限作为 PRA 将自己或其他用户提升为全局管理员。

以下是实际攻击路径的视频，从“应用程序管理员”升级到“全局管理员”：

预防

如前所述，Azure 具有内置机制，可防止通过基于角色的攻击路径进行特权升级。只有具有全局管理员或特权身份验证管理员角色的用户才能重置全局管理员的密码。这种简单而巧妙的机制提供了一种高度有效的安全措施，可保护 Azure 管理员不会在不知情的情况下将攻击路径引入其租户。但这种机制可以走得更远。

我认为，针对本博文中描述的特权升级技术的最佳预防措施是 Microsoft 自己扩展此机制以涵盖服务主体。正如系统为全局管理员用户提供内置保护一样，Azure 也可以（也许应该）为全局管理员服务主体提供内置保护。我不知道这个系统的内部工作原理，也不知道这种扩展在技术上是否可行，但我相信 Microsoft 可以通过扩展系统以涵盖服务主体来完全消除这种攻击原语，为所有客户创建一个更安全的平台。

同时，Azure 管理员应该审核服务主体所担任的角色，并确定这些服务主体对其余身份的暴露情况。

Azure 管理员可以通过审核服务主体所拥有的角色并将这些角色与其他具有应用程序控制权的身份进行比较来阻止此攻击路径。Azure 中最危险的角色是“全局管理员”，所以让我们从那里开始。打开 Azure 门户，导航到您的租户，然后单击“角色和管理员”：

向下滚动并单击“全局管理员”。在这里，您将看到当前激活此角色的身份列表。在“类型”列中，查找“ServicePrincipal”条目：

我的租户中有两个具有全局管理员角色的服务主体：“CanYouAddASecretToMe”和“ThisAppHasGlobalAdminRole”。这些是服务主体的名称，也是与这些服务主体关联的应用程序的名称。

这是您的第一个预防机会：确定这些应用程序是否确实需要全局管理员权限才能运行。如果这些是第三方应用程序，请与您的供应商合作，将此权限级别降低到应用程序运行所需的级别。

如果这些角色必须保留，那么下一步就是查看租户中具有租户级角色的身份，这些角色授予主体滥用服务主体的能力。这些角色是：

• 应用程序管理员

• 云应用程序管理员

• 混合身份管理员

此外，这些遗留/隐藏角色可能会被滥用来接管服务主体：

• 目录同步帐户

• 合作伙伴一级支持

• 合作伙伴二级支持

让我们通过导航到我们的租户，单击“角色和管理员”，然后单击应用程序管理员角色来审核“应用程序管理员”角色：

在这里，我们可以看到当前处于活动状态的所有用户和服务主体。这是您的第二次预防机会：所有这些用户是否都需要管理租户中所有服务帐户的凭据的能力？

我们还需要检查应用级角色和每个应用的所有者。之前我们看到服务主体“ThisAppHasGlobalAdminRole”当前是全局管理员。导航到您的租户，单击“应用注册”，单击“所有应用程序”，然后找到与该服务主体关联的应用：

首先，单击“所有者”，它将显示拥有该应用程序的所有主体（可以有多个）：

您信任Matt Nelson会将秘密添加到具有全局管理员权限的应用程序吗？我不会。

接下来，单击“角色和管理员”，它将显示特定于此应用程序的应用程序级角色。例如，单击“云应用程序”管理员，它将显示针对该应用程序具有此角色的主体，这些主体既明确地（范围为应用程序），也从租户继承该角色：

这是您的第三和第四次预防机会：您是否相信所有这些主体都可以控制具有全局管理员权限的服务主体？

您应该对拥有以下角色的服务主体重复此过程：

• 应用程序管理员

• 身份验证管理员

• Azure AD 已加入设备本地管理员

• 云应用程序管理员

• 云设备管理员

• Exchange 管理员

• 群组管理员

• 帮助台管理员

• 混合身份管理员

• Intune 管理员

• 密码管理员

• 特权身份验证管理员Privileged Authentication Administrator

• 用户管理员

这也是内置的针对全局管理员的密码重置保护可能被破坏的地方，通过滥用对服务主体的控制，创建从低权限用户到全局管理员的攻击路径。在现实世界中，这是我们见过的升级到全局管理员的最常见途径，无需先转向本地 AD。

手动完成此过程时，您可能会问自己：“是否有一个屏幕可以告诉我任何服务主体所拥有的所有角色？”据我所知，Azure 门户中不存在这样的屏幕，但您可以使用 Microsoft 编写的 PowerShell cmdlet 来回答这个问题：

# Install the AzureAD PowerShell module
Install-Module AzureAD
# Authenticate to the tenant
$username = "[email protected]"
$password = 'YourVeryStrongPassword'
$SecurePassword = ConvertTo-SecureString “$password” -AsPlainText -Force
$Credential = New-Object System.Management.Automation.PSCredential($username, $SecurePassword)
Connect-AzureAD -Credential $Credential
# Build our users and roles object
$UserRoles = Get-AzureADDirectoryRole | ForEach-Object {
        
    $Role = $_
    $RoleDisplayName = $_.DisplayName
        
    $RoleMembers = Get-AzureADDirectoryRoleMember -ObjectID $Role.ObjectID
        
    ForEach ($Member in $RoleMembers) {
    $RoleMembership = [PSCustomObject]@{
            MemberName = $Member.DisplayName
            MemberID = $Member.ObjectID
            MemberOnPremID = $Member.OnPremisesSecurityIdentifier
            MemberUPN = $Member.UserPrincipalName
            MemberType = $Member.ObjectType
            RoleID = $Role.RoleTemplateId
            RoleDisplayName = $RoleDisplayName
     }
        
        $RoleMembership
        
    } 
}
$UserRoles | ?{$_.MemberType -eq "ServicePrincipal"}

这将产生如下输出：

这可以更容易、更快速地识别具有危险管理角色的服务主体。

结论

微软正在不断改进 Azure，无论这些改进是与正常运行时间、功能还是安全性有关。微软有机会扩展其现有的与密码重置权限相关的设计选择，以涵盖服务主体。我不知道该系统的内部工作原理，也不知道将该系统扩展以涵盖服务主体是否可行。无论如何，这对微软来说都是一个保护所有客户并使 Azure 成为更安全平台的绝佳机会。