diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index 5191e9a2f..48bdb309c 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -13,8 +13,8 @@ - **单个目录**最多可以支持**10,000个管理组**。 - 管理组树可以支持**最多六个层级的深度**。此限制不包括根级别或订阅级别。 - 每个管理组和订阅只能支持**一个父级**。 -- 即使可以创建多个管理组，**只有1个根管理组**。 -- 根管理组**包含**所有**其他管理组和订阅**，并且**无法移动或删除**。 +- 即使可以创建多个管理组，**根管理组只有一个**。 +- 根管理组**包含**所有**其他管理组和订阅，并且**无法移动或删除**。 - 单个管理组内的所有订阅必须信任**相同的Entra ID租户**。

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

@@ -42,7 +42,7 @@ Azure 资源 ID 的格式如下： - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}` -对于在资源组`myResourceGroup`下，订阅 ID 为`12345678-1234-1234-1234-123456789012`的名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样： +对于在订阅 ID `12345678-1234-1234-1234-123456789012` 下的资源组 `myResourceGroup` 中名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样： - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM` @@ -106,7 +106,7 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 - **访客用户访问限制**选项： - **访客用户与成员具有相同的访问权限**。 - **访客用户对目录对象的属性和成员资格的访问有限（默认）**。这限制了访客访问仅限于他们自己的用户资料。对其他用户和组信息的访问不再允许。 -- **访客用户访问限制为仅限于他们自己目录对象的属性和成员资格**是最严格的。 +- **访客用户访问限制为仅限于其自己目录对象的属性和成员资格**是最严格的。 - **访客可以邀请**选项： - **组织中的任何人都可以邀请访客用户，包括访客和非管理员（最具包容性） - 默认** - **成员用户和分配给特定管理员角色的用户可以邀请访客用户，包括具有成员权限的访客** @@ -116,7 +116,7 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 - 允许外部用户离开组织 > [!TIP] -> 即使默认受到限制，具有授予权限的用户（成员和访客）仍然可以执行上述操作。 +> 即使默认受到限制，具有授予权限的用户（成员和访客）仍可以执行上述操作。 ### **组** @@ -146,13 +146,13 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 #### 关键组件： -1. **应用程序 ID（客户端 ID）：** Azure AD 中应用程序的唯一标识符。 +1. **应用程序 ID（客户端 ID）：** 您的应用在 Azure AD 中的唯一标识符。 2. **重定向 URI：** Azure AD 发送身份验证响应的 URL。 3. **证书、密钥和联合凭据：** 可以生成密钥或证书以作为应用程序的服务主体登录，或授予对其的联合访问（例如 GitHub Actions）。 1. 如果生成了**证书**或**密钥**，则可以通过知道**应用程序 ID**、**密钥**或**证书**以及**租户**（域或 ID）来**以服务主体身份登录**。 -4. **API 权限：** 指定应用程序可以访问的资源或 API。 -5. **身份验证设置：** 定义应用程序支持的身份验证流程（例如，OAuth2、OpenID Connect）。 -6. **服务主体**：创建应用程序时会创建服务主体（如果是从 Web 控制台创建）或在新租户中安装时创建。 +4. **API 权限：** 指定应用可以访问的资源或 API。 +5. **身份验证设置：** 定义应用支持的身份验证流程（例如，OAuth2、OpenID Connect）。 +6. **服务主体**：创建应用时会创建服务主体（如果是从 Web 控制台创建）或在新租户中安装时创建。 1. **服务主体**将获得其配置的所有请求权限。 ### 默认同意权限 @@ -161,11 +161,11 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 - **不允许用户同意** - 所有应用程序都需要管理员批准。 -- **允许用户对来自经过验证的发布者的应用程序进行同意，针对选定的权限（推荐）** -- 所有用户可以对被分类为“低影响”的权限进行同意，适用于来自经过验证的发布者或在此组织中注册的应用程序。 +- **允许用户对来自经过验证的发布者、内部应用程序和仅请求选定权限的应用程序进行同意（推荐）** +- 所有用户可以同意仅请求被分类为“低影响”的权限、来自经过验证的发布者的应用程序和在租户中注册的应用程序。 - **默认**低影响权限（尽管您需要接受将其添加为低影响）： - User.Read - 登录并读取用户资料 -- offline_access - 维护对用户已授予访问权限的数据的访问 +- offline_access - 保持对用户已授予访问权限的数据的访问 - openid - 登录用户 - profile - 查看用户的基本资料 - email - 查看用户的电子邮件地址 @@ -182,18 +182,18 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 Azure Active Directory 中的托管身份提供了一种**自动管理应用程序身份**的解决方案。这些身份由应用程序用于**连接**到与 Azure Active Directory（**Azure AD**）身份验证兼容的**资源**。这允许**消除在代码中硬编码云凭据**的需要，因为应用程序将能够联系**元数据**服务以获取有效令牌，以**作为指定的托管身份执行操作**。 -托管身份有两种类型： +有两种类型的托管身份： -- **系统分配**。某些 Azure 服务允许您**直接在服务实例上启用托管身份**。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个**服务主体**。当**资源**被**删除**时，Azure 会自动为您**删除**该**身份**。 -- **用户分配**。用户也可以生成托管身份。这些身份是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个服务主体。然后，您可以将托管身份分配给一个或**多个 Azure 服务实例**（多个资源）。对于用户分配的托管身份，**身份与使用它的资源是分开管理的**。 +- **系统分配**。某些 Azure 服务允许您**直接在服务实例上启用托管身份**。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个**服务主体**，该订阅信任 Entra ID 租户。当**资源**被**删除**时，Azure 会自动为您**删除**该**身份**。 +- **用户分配**。用户也可以生成托管身份。这些身份是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个服务主体，该主体由订阅信任。然后，您可以将托管身份分配给一个或**多个实例**的 Azure 服务（多个资源）。对于用户分配的托管身份，**身份与使用它的资源是分开管理的**。 托管身份**不会生成永久凭据**（如密码或证书）以访问与其关联的服务主体。 ### 企业应用程序 -这只是一个**在 Azure 中过滤服务主体**并检查已分配应用程序的表。 +这只是一个**在 Azure 中过滤服务主体**并检查已分配给的应用程序的表。 -**这不是另一种“应用程序”类型，** Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。 +**这不是另一种“应用程序”**，在 Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。 ### 管理单位 @@ -210,13 +210,13 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 - AU **不能包含 AU** - 分配管理员角色： - 将“用户管理员”角色授予区域 IT 员工，范围限制在其区域的 AU。 -- 结果：区域 IT 管理员可以管理其区域内的用户帐户，而不影响其他区域。 +- 结果：区域 IT 管理员可以管理其区域内的用户帐户，而不会影响其他区域。 ### Entra ID 角色和权限 - 为了管理 Entra ID，有一些**内置角色**可以分配给 Entra ID 主体以管理 Entra ID - 在 [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) 中查看角色 -- EntraID 标记为**`PRIVILEGED`**的角色应谨慎分配，因为正如微软在文档中所解释的那样 [在文档中](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)：特权角色分配如果不以安全和预期的方式使用，可能会导致权限提升。 +- EntraID 标记为**`PRIVILEGED`**的角色应谨慎分配，因为正如微软在文档中所解释的那样：[https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)：特权角色分配如果未以安全和预期的方式使用，可能会导致权限提升。 - 权限最高的角色是**全局管理员** - 角色组**细化权限**，可以在其描述中找到。 - 可以**创建自定义角色**，以获得所需的权限。尽管由于某种原因，并非所有细化权限都可供管理员创建自定义角色。 @@ -225,21 +225,21 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 ## Azure 角色和权限 -- **角色**是**分配**给**主体**的，具有**范围**：`principal -[HAS ROLE]->(scope)` +- **角色**被**分配**给**主体**，并具有**范围**：`principal -[HAS ROLE]->(scope)` - **分配给组的角色**会被组内的所有**成员**继承。 -- 根据角色分配的范围，**角色**可能会**继承**到范围容器内的**其他资源**。例如，如果用户 A 在订阅上具有**角色**，他将在订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。 +- 根据角色分配的范围，**角色**可能会**继承**到范围容器内的**其他资源**。例如，如果用户 A 在**订阅**上具有**角色**，他将在该订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。 ### 内置角色 -[来自文档：](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) 有几个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)。 +[来自文档：](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)有几个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色无法满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)。 -**内置**角色仅适用于**它们所针对的资源**，例如检查这两个关于**计算**资源的**内置角色**示例： +**内置**角色仅适用于**它们所针对的资源**，例如检查这两个**内置角色**在计算资源上的示例： | [磁盘备份读取器](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | 提供备份库执行磁盘备份的权限。 | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | | [虚拟机用户登录](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 在门户中查看虚拟机并以常规用户身份登录。 | fb879df8-f326-4884-b1cf-06f3ad86be52 | -这些角色也可以**分配给逻辑容器**（如管理组、订阅和资源组），受影响的主体将在**这些容器内的资源上**拥有它们。 +这些角色也可以**分配给逻辑容器**（如管理组、订阅和资源组），受影响的主体将在这些容器内的资源上拥有它们。 - 在这里找到 [**所有 Azure 内置角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) 的列表。 - 在这里找到 [**所有 Entra ID 内置角色**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) 的列表。 @@ -312,7 +312,7 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 与角色分配一样，**拒绝分配** 用于 **控制对 Azure 资源的访问**。然而，**拒绝分配** 用于 **明确拒绝对资源的访问**，即使用户通过角色分配获得了访问权限。**拒绝分配** 优先于 **角色分配**，这意味着如果用户通过角色分配获得了访问权限，但也通过拒绝分配被明确拒绝访问，则拒绝分配将优先。 -与角色分配一样，**拒绝分配** 适用于某个范围，指示受影响的主体和被拒绝的权限。此外，在拒绝分配的情况下，可以 **防止拒绝被子资源继承**。 +与角色分配一样，**拒绝分配** 应用于某个范围，指示受影响的主体和被拒绝的权限。此外，在拒绝分配的情况下，可以 **防止拒绝被子资源继承**。 ### Azure 策略 @@ -331,10 +331,10 @@ Azure 策略是 **主动的**：它们可以阻止不合规资源的创建或更 1. **确保符合特定 Azure 区域的合规性**：此策略确保所有资源在特定 Azure 区域部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR。 2. **强制命名标准**：策略可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。 -3. **限制某些资源类型**：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些 VM 大小等昂贵资源类型，以控制成本。 +3. **限制某些资源类型**：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些虚拟机大小等昂贵资源类型，以控制成本。 4. **强制标签策略**：标签是与 Azure 资源关联的键值对，用于资源管理。策略可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。 5. **限制对资源的公共访问**：策略可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。 -6. **自动应用安全设置**：策略可以用于自动将安全设置应用于资源，例如将特定网络安全组应用于所有 VM，或确保所有存储帐户使用加密。 +6. **自动应用安全设置**：策略可以用于自动将安全设置应用于资源，例如将特定的网络安全组应用于所有虚拟机或确保所有存储帐户使用加密。 请注意，Azure 策略可以附加到 Azure 层次结构的任何级别，但它们 **通常用于根管理组** 或其他管理组。 @@ -358,18 +358,18 @@ Azure 策略 JSON 示例： ``` ### 权限继承 -在 Azure **权限可以分配给层级的任何部分**。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的包含 **资源** 进行 **继承**。 +在 Azure **权限可以分配给层次结构的任何部分**。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的包含 **资源** 进行 **继承**。 -这种层级结构允许高效且可扩展的访问权限管理。 +这种层次结构允许高效且可扩展的访问权限管理。
### Azure RBAC 与 ABAC **RBAC**（基于角色的访问控制）是我们在前面的部分中已经看到的内容：**将角色分配给主体以授予其对资源的访问权限**。\ -然而，在某些情况下，您可能希望提供 **更细粒度的访问管理** 或 **简化** **数百个** 角色 **分配** 的管理。 +然而，在某些情况下，您可能希望提供 **更细粒度的访问管理** 或 **简化** 数百个角色 **分配** 的管理。 -Azure **ABAC**（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 **基于属性的角色分配条件** 来构建。_角色分配条件_ 是您可以选择性地添加到角色分配中的 **额外检查**，以提供更细粒度的访问控制。条件过滤作为角色定义和角色分配的一部分授予的权限。例如，您可以 **添加一个条件，要求对象具有特定标签才能读取该对象**。\ +Azure **ABAC**（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 **基于属性的角色分配条件** 来构建。_角色分配条件_ 是您可以选择性地添加到角色分配中的 **额外检查**，以提供更细粒度的访问控制。条件过滤掉作为角色定义和角色分配一部分授予的权限。例如，您可以 **添加一个条件，要求对象具有特定标签才能读取该对象**。\ 您 **不能** 明确 **拒绝** **对特定资源的访问** **使用条件**。 ## 参考文献 diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md index eb05995b6..6ea8d0763 100644 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md +++ b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md @@ -8,7 +8,7 @@ ### 应用程序同意权限 -默认情况下，任何 **用户都可以给应用程序提供同意**，尽管可以配置为用户只能同意 **来自经过验证的发布者的特定权限的应用程序**，甚至 **移除用户对应用程序的同意权限**。 +默认情况下，任何 **用户都可以给予应用程序同意**，尽管可以配置为用户只能同意 **来自经过验证的发布者的特定权限的应用程序**，甚至 **移除用户同意应用程序的权限**。
@@ -25,7 +25,7 @@ - 如果被钓鱼的用户是可以 **同意任何具有任何权限的应用程序** 的管理员，则该应用程序也可以 **请求特权权限** - **已认证**：在拥有足够权限的主体被攻陷后，**在帐户内创建一个应用程序** 并 **钓鱼** 一些 **特权** 用户，这些用户可以接受特权 OAuth 权限。 - 在这种情况下，您已经可以访问目录的信息，因此权限 `User.ReadBasic.All` 不再有趣。 -- 您可能对 **需要管理员授予的权限** 感兴趣，因为普通用户无法给 OAuth 应用程序任何权限，这就是为什么您需要 **仅钓鱼这些用户**（稍后将详细介绍哪些角色/权限授予此特权）。 +- 您可能对 **需要管理员授予的权限** 感兴趣，因为普通用户无法给予 OAuth 应用程序任何权限，这就是为什么您需要 **仅钓鱼这些用户**（稍后将详细介绍哪些角色/权限授予此特权） ### 用户被允许同意 @@ -125,6 +125,13 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \ 根据请求的权限，您可能能够 **访问租户的不同数据**（列出用户、组... 或甚至修改设置）和 **用户的信息**（文件、笔记、电子邮件...）。然后，您可以使用这些权限执行这些操作。 +### Entra ID 应用程序管理员 + +如果您以某种方式成功破坏了可以管理 Entra ID 应用程序的 Entra ID 主体，并且有应用程序被租户的用户使用。管理员将能够 **修改应用程序请求的权限并添加一个新的允许重定向地址以窃取令牌**。 +- 请注意，可以 **添加重定向 URI**（无需删除真实的 URI），然后使用攻击者的重定向 URI 发送 HTTP 链接，因此当用户跟随该链接时，身份验证会自动发生，攻击者会收到令牌。 +- 还可以更改应用程序请求的权限，以便从用户那里获取更多权限，但在这种情况下，用户需要 **再次接受提示**（即使他已经登录）。 +- 要执行此攻击，攻击者 **不需要** 控制应用程序代码，因为他可以将带有新 URL 的登录链接发送给用户，URL 在 **`redirect_uri`** 参数中。 + ### 应用程序后期利用 查看页面的应用程序和服务主体部分：