[KubeConEu2024]: Living off the Land Techniques in Managed Kubernetes Clusters

在托管的Kubernetes集群中利用“土生土长”的技术（Living Off The Land, LOTL）的策略和技术。这些技术主要涉及使用集群内已存在的工具和流程来执行恶意活动，以减少被检测的可能性。

1. LOTL

“Living off the land”这个短语是由Christopher Campbell（ @obscuresec）和Matt Graeber @mattifestation）在DerbyCon 3上创造的。

LOLBins 一词来自 Twitter 上的一次讨论，该讨论涉及攻击者可以如何使用二进制文件来执行超出其原始目的的操作。Philip Goh （@MathCasualty） 提议了 LOLBins。随后进行了一次高度科学的互联网民意调查，在达成普遍共识 （69%） 后，这个名字被正式宣布。Jimmy （@bohops） 紧随其后 LOLScripts.

LOTL技术通常涉及使用系统内部的合法工具（如LOLBins）来隐藏恶意行为，使其看起来像正常活动。这种方法可以显著降低恶意行为被发现的风险。

例如在传统的网络安全领域，典型的LOTL技术有 GTFOBins(https://gtfobins.github.io/)、LOLBAS(https://lolbas-project.github.io/) 。

本次演讲者介绍的是在托管k8s集群中的LOTL技术，并呼吁应该将相关的LOTL组件加入到威胁矩阵中。

2. LOTL in K8S

2.1 利用Node Problem Detector实现持久化

Node Problem Detector（NPD）是Kubernetes中用于检测节点问题的工具，通常作为系统服务运行。其配置有定期执行的特点，攻击者可以借此来实现持久化。

攻击者可以修改NPD的配置文件，插入恶意脚本或命令，但修改配置文件需要重启pod。

配置文件形如:

network-problem-monitor.json(https://github.com/kubernetes/node-problem-detector/blob/e8840b1a7d4af62b5330991d57a7c6959f1c61f7/config/network-problem-monitor.json)

{
  "plugin": "custom",
  "pluginConfig": {
    "invoke_interval": "30s",
    "timeout": "5s",
    "max_output_length": 80,
    "concurrency": 3
  },
  "source": "network-custom-plugin-monitor",
  "metricsReporting": true,
  "conditions": [],
  "rules": [
    {
      "type": "temporary",
      "reason": "ConntrackFull",
      "path": "./config/plugin/network_problem.sh",
      "timeout": "3s"
    }
  ]
}

修改执行脚本可以避免重启NPD pod。例如上述配置文件的脚本 ./config/plugin/network_problem.sh

2.2 利用Fluent Bit实现数据收集

Fluent Bit是一个日志处理器和收集器，经常在Kubernetes集群中用于日志管理。通过修改日志收集和传输的配置，攻击者可以从集群中悄悄抽取敏感数据。

修改Fluent Bit的ConfigMap配置，注入恶意的输入插件或过滤器配置。

fluent-bit-config-kafka-rest.yml(https://github.com/fluent/fluent-bit-kubernetes-logging/blob/c590a9ba0ec1e3034308b2884ec9ffc276bf09a0/fluent-bit-config-kafka-rest.yml)

kind: ConfigMap
metadata:
  name: fluent-bit-config-kafka-rest
  namespace: kube-system
apiVersion: v1
data:
  fluent-bit.conf: |-
    [SERVICE]
        Flush          1
        Daemon         Off
        Log_Level      info
        Parsers_File   parsers.conf

    [INPUT]
        Name           tail
        Tag            kube.*
        Path           /var/log/containers/*.log
        Parser         docker
        DB             /var/log/flb_kube.db
        Mem_Buf_Limit  5MB
...

INPUT模块也支持 exec 配置，详见：https://docs.fluentbit.io/manual/pipeline/inputs/exec

2.3 利用 AKS Entra ID Auth 实现权限提升

AKS提供了几种身份验证和授权方式，其中包括：

• 本地账户 + Kubernetes RBAC：使用Kubernetes自带的角色基础访问控制。
• Entra ID + Kubernetes RBAC：通过Azure的Entra ID服务进行身份验证，同时使用Kubernetes的RBAC进行授权。
• Entra ID + Azure RBAC：结合使用Azure的角色基础访问控制和Entra ID进行更细致的访问控制。

前提条件：

k8s集群管理员可能过度信任system:authenticated这类用户组，例如提供了get secrets权限

利用步骤：

1. 获取服务主体凭证：攻击者可能通过各种手段获取到服务主体的凭证，这些凭证可以转换为 k8s token，表现为 system:authenticated 用户组，但实际权限较低， 例如无法 kubectl get secrets。
2. 利用k8s集群对system:authenticated的信任提升权限。

Ronen Shustin 说明了上述问题在AKS、GKE中存在。

2.4 利用 EKS pod identity 实现权限提升

EKS pod identity通过IAM角色为服务账户 (IRSA) 提供了一种安全的方式来将IAM角色分配给Kubernetes中的Pods。这允许Pods直接使用IAM角色的权限与AWS服务进行交互，而无需在Pod内部明确存储AWS访问密钥。

Ronen Shustin 假设了一种具体的攻击场景，攻击者可能通过网络抓包(需要host network+CAP_NET_RAW)等技术窃取正常业务获取EKS pod identity的流量, 从而窃取IAM凭证，实现提权。

3. 为什么难以检测

目前，k8s系统级的相关插件，属于安全运营团队的监控盲区。

例如

• NPD案例，作者通过修改其配置文件来实现持久化，再结合恶意命令自身的躲避防御技术，因安全运营团队不熟悉相关插件的行为，很难察觉到异常。
• fluentbit案例，因其本身就是数据收集的功能，通过其采集任何数据，都不易引起注意。

4. 防护建议

安全运营团队需要了解LOTL技术，并检查系统级插件、进程的配置文件安全性，甚至建立相关配置的白名单机制。

5. 启示

针对特定云厂商K8S甚至弹性虚拟机等产品，研究LOTL利用技术，有助于躲避防御。有必要系统性地针对云厂商Agent作全面的漏洞挖掘及可利用性分析。

本文发布已获得"云原生安全资讯"项目授权, 同步发布于以下平台

• github.com/cloud-native-security-news/cloud-native-security-news
• 公众号: 石头的安全料理屋

欢迎加入 "云原生安全资讯"项目 👏 阅读、学习和总结云原生安全相关资讯