diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 6172b28d3..d05776c71 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -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) diff --git a/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md b/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md index 46da0e5b4..750e1ef72 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md +++ b/src/pentesting-cloud/azure-security/az-services/az-cosmosDB.md @@ -9,7 +9,7 @@ 支持 HackTricks * 查看 [**订阅计划**](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 分享黑客技巧。 @@ -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://.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://:/ 在 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}") 支持 HackTricks * 查看 [**订阅计划**](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 分享黑客技巧。 {% endhint %} diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md deleted file mode 100644 index 69cddf21a..000000000 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-vms-unath.md +++ /dev/null @@ -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}} diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index d3f34baea..a85098873 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.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 -n -- 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 保护 +#### 绕过只读保护 -如果你足够幸运，并且高度特权的能力 `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://:/api/v1/namespaces/kube-system/secrets/ ``` ### 列出秘密 -**列出秘密的权限可能允许攻击者实际读取秘密** 访问 REST API 端点： +**列出秘密的权限可能允许攻击者实际读取秘密**，访问 REST API 端点： ```bash curl -v -H "Authorization: Bearer " https://:/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` 中使用资源名称 `/` 或 `/*` 进行批准。 +根据 [文档，您可以自动批准这些请求](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)，因此在这种情况下您 **不需要额外的权限**。如果没有，您需要能够批准请求，这意味着在 `certificatesigningrequests/approval` 中更新，并在 `signers` 中使用资源名称 `/` 或 `/*` 进行批准。 一个 **具有所有所需权限的角色示例** 是： ```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 ### 节点和 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 ``` -![mutating-webhook-status-check.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433436353/yHUvUWugR.png?auto=compress,format&format=webp) - -然后部署一个新的 pod: +然后部署一个新的 pod： ```bash kubectl run nginx --image nginx kubectl get po -w diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md index 668c3083a..e758d2d82 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-enumeration.md @@ -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= {{#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//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//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 [-n ] -o yaml ``` @@ -496,11 +505,11 @@ restartPolicy: Never # or using # node-role.kubernetes.io/master: "" ``` -在那之后，您创建了 pod +在那之后，你创建了 pod ```bash kubectl apply -f attacker.yaml [-n ] ``` -现在您可以通过以下方式切换到创建的 pod： +现在您可以按如下方式切换到创建的 pod ```bash kubectl exec -it attacker-pod [-n ] -- sh # attacker-pod is the name defined in the yaml file ``` @@ -508,7 +517,7 @@ kubectl exec -it attacker-pod [-n ] -- 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