容器化环境
在云上部署应用的模式主要有以下几种，目前K8s已经成为容器集群管理的标准，同时也引入了新的攻击面。
Attack Matrix
根据 "attack-matrix-kubernetes" 做了部分改动
Initial Access/突破口
- 初始入侵点除了Docker所承载的应用本身漏洞(如Java RCE)以外，K8s还引入了新的攻击面，K8s API Server在未鉴权的情况下开放到公网，或是docker.sock开放到0.0.0.0地址段，都会迅速被蠕虫捕获。此外云厂商的AK泄露(github)也会对攻击者提供更上层的资产控制。
- K8s configfile是API Server的鉴权凭证，开发人员若将此文件上传到Github或者开发人员的办公机器遭到入侵，攻击者可以通过此凭证连接API Server并接管K8s集群。
- 攻击者常会将恶意镜像部署到dockerhub等公共源，并通过诱导或链路劫持来完成供应链攻击。针对此场景，我们对DockerHub构建了实时全量的镜像审计系统，将产出的恶意镜像情报应用于入侵检测。
Execution/执行指令
- 在获取K8s API Server权限后，可以通过kubectl对K8s资源进行管理，一种常见的方法是直接在已有的pod中执行指令，或者创建新的pod来承载后续的攻击行为，我们观察到部分蠕虫将含有后门的恶意镜像上传到dockerhub，并对已控制的K8s集群进行批量pod创建。
- K8s的每个pod中默认会提供service account方式与API Server进行连接，如果该用户被赋予高权限，入侵者可通过应用层漏洞(如WEB RCE)入侵之后直接通过service account对K8s进行管理。
- 小部分应用场景下容器内部会安装SSH服务，暴露入侵风险。
- 云厂商的一些应用中经常会通过K8s为用户创建一次性的沙箱服务，其中的权限配置和已知漏洞问题或导致K8s被攻破。
- 《啃硬骨头的经历：在25分钟内发现4个Google Cloud Shell漏洞（详情）》
Persistence/持久化
- 在掌握了高权限的账号后可以通过K8s API Server对每个node部署恶意pod以最大限度的劫持计算资源。
- 在部署pod时可以通过mount配置将宿主机核心目标挂载到pod内部，从而将K8s层的持久化下沉到VM层。
- Kubernetes CronJob计划任务，如同linux crontab一样，攻击者可以使用它集群中部署容器和执行恶意指令。
Privillege Escalation/权限提升
- 在获取Docker权限之后，可以通过Docker/K8s或操作系统自身漏洞逃逸到宿主机，除此之外用户的特殊配置也可以引发逃逸，详见：《容器逃逸方法》
- 获取K8s权限之后可以通过创建特权容器或利用文件挂载的形式，继续获取宿主机的权限，也可以创建后门用户并添加到Cluster-admin角色。
- 在已攻破的pod中搜寻配置信息，如云服务的AK、数据库连接信息等，可以获得其他系统/服务权限。
Defence Evasion/对抗防御
- 一种常见的反侦查手段是清理容器内部的应用日志/var/log，攻击者在获取K8s权限之后还可以通过APIserver或在master-node删除K8s日志以隐藏自己的连接和部署后门账号、创建pod行为。
- 许多云厂商所提供的K8s集群默认会携带一些应用/第三方插件并会初始化其pod，我们观察到一些蠕虫利用这一点将其恶意pod伪装成系统工具。
- K8s场景下很多安全厂商的agent通过side-car模式进行平行部署，攻击者在掌握了K8s的关联权限后，可以直接对这些安全agent进行清理和欺骗，以停止其对集群的保护功能。
- K8s API Server会记录请求IP，通过代理隐藏真实IP是常规操作。
Credential Access/窃取凭证
- 应用、K8s、云产品的凭证都是窃取的目标。事实上在基础设施高度容器化的场景中，绝大部分服务都是API化的，这使凭证窃取成为扩展攻击面、获取目标数据的重要手段。例如一个WEB应用被攻破，在pod中找到后端数据库、消息队列、短信服务等接口的AK并攻击这些服务。
Discovery/信息收集
- 攻击者在已控制的资产范围收集信息以便寻找攻击点进行更深入的渗透。一种常见的方式是通过K8s API Server/Kubelet API/K8s Dashboard UI获取信息，虽然一般是低权限(只读)账号，但仍能够获取一些node和部署状态等基础信息。
- 攻击者可以在cluster中发起内网扫描来发现不同pod所承载的服务，并通过其漏洞进行后续渗透。
- 在云厂商提供的容器服务中，由于底层VM/NC状态用户不可控，运营商会以API的方式向用户提供这些信息。
Lateral Movement/横向移动
- K8s环境下的横向移动方式在前文均有提及，包括通过pod内部的service account访问Api Server、通过窃取的凭证攻击其他云服务、或者通过内网漏洞进行横向渗透。
- 此外，一些第三方插件/工具会引入新的攻击面，并为横向移动提供便利，此类工具大部分复用K8s的RBAC机制，例如应用管理工具Helm："attacking default installs of helm on kubernetes"
Impact/影响
- 由于容器环境复杂，不同云服务商的环境差异化较大，exp难以自动化。目前观察到的自动化蠕虫仍以挖矿为主，链路简单。容器基础设施的普及会将对抗推入新的高度。
反入侵
基础判断：
- 针对容器服务/集群管理平台的攻击已被蠕虫广泛集成。
- 供应链攻击持续进化，镜像扫描(文件系统查杀)难以将风险完全暴露。
- 中间件、服务攻击面收窄，更多定向攻击将来自人员、鉴权与凭证泄露。
- 业务层威胁仍然重要，包括传统WEB漏洞、越权、数据泄露等。
- 入侵检测方法论从黑名单向白名单演化，异常检测将发挥更大价值。
产品功能考量：
- 检测：目前主流的数据采集方案有平行(在K8s中部署安全容器做日志采集)和垂直(通过HIDS的agent直接采集docker/K8s node数据)两种。K8s场景带来的两大问题：1) K8s自身的攻击面 2) 大内网。其中1)可以通过K8s audit审计来完成；针对2)内网攻击的流量侧解决方案，K8s自身机制已无法满足报文识别的需求，这一功能将成为安全产品的核心竞争力。
- 防御：在进程、文件、网络、syscall四个级别进行检测和阻断。syscall除了用于识别上古docker漏洞之外，还可以将管控粒度从进程级别下放到"行为"级别，即从"谁启动的"变为"谁做了什么"。可以通过基线或者机器学习对pod内部和pod间的历史行为进行建模，生成白名单规则进行管控，从而大幅强化对核心资产资产的安全性。另外一种模式是"快恢方案"：动态销毁被入侵容器并通过之前的快照生成"替代品"，可以在无先验知识的情况下增加入侵成本，并保证系统可用性。
