CSDN云上容器 ATT&CK 矩阵详解,阿里云助力企业容器化安全落地( 六 )


5.2 K8s Audit日志清理
Kubernetes Audit功能提供了与安全相关的按时间顺序排列的记录集 , 记录单个用户、管理员或系统其他组件影响系统的活动顺序 。 日志提供了包括事件、时间、用户、作用对象、发起者、执行结果等详细信息 , 为运行时安全审计提供便利 。 攻击者可以通过清理本地日志文件(用户/服务商可自定义位置)以及切断服务商/安全产品的日志上传通道(卸载agent或者阻断网络通路)来隐藏对K8s集群的操作 , 一些容器安全产品通过K8s AuditSink功能将日志导出到外部审计 , 也可通过修改K8s配置进行开启或关闭 。
示例:阿里云容器服务KubernetesAudit审计中心:
CSDN云上容器 ATT&CK 矩阵详解,阿里云助力企业容器化安全落地
本文插图
5.3 利用系统Pod伪装
K8s在部署时会在kube-system namespace中内置一些常见的功能性pod 。 在云厂商提供的容器服务中 , 集群还会默认携带一些云服务的组件(如日志采集、性能监控的agent) 。 攻击者可以利用常见的K8s内置pod作为后门容器 , 或将后门代码植入这些pod来实现隐蔽的持久化 。
示例:阿里云托管版K8s服务内置pod:
xy@x-8 ~/D/test> kubectl get deployments --namespace=kube-systemNAME READY UP-TO-DATE AVAILABLE AGEalibaba-log-controller 1/1 1 1 183dalicloud-application-controller 1/1 1 1 183dalicloud-disk-controller 1/1 1 1 183dalicloud-monitor-controller 1/1 1 1 183daliyun-acr-credential-helper 1/1 1 1 183dcoredns 2/2 2 2 183dmetrics-server 1/1 1 1 183dnginx-ingress-controller 2/2 2 2 183dtiller-deploy 1/1 1 1 183d5.4 通过代理或匿名网络访问K8s API Server
利用代理或匿名网络执行攻击是常见的反溯源行为 , 在K8s Audit日志中记录了每个行为发起者的源IP , 通过公网访问API Server的IP将会被记录并触发异常检测和威胁情报的预警 。
示例:K8s Audit日志对pod exec行为的记录:
CSDN云上容器 ATT&CK 矩阵详解,阿里云助力企业容器化安全落地
本文插图
5.5 清理安全产品Agent
目前主流容器运行时的安全产品部署方式有两种:平行容器模式和主机agent模式 。 前者创建安全容器采集pod、K8s集群日志以及实现网络代理;后者在VM层对容器层的进程网络文件进行采集 。 攻击者在获取到集群管理权限或逃逸到宿主机时 , 可以通过清理掉安全产品植入的探针 , 破坏日志完整性 , 使后续攻击行为无法被审计工具发现 。 在这一过程中 , 安全容器或主机agent异常离线往往会触发保护性告警 。
5.6 创建影子API Server
攻击者可以复制原生API Server的配置 , 修改关键参数(例如关闭认证 , 允许匿名访问 , 使用HTTP请求) , 再使用这些修改过的参数创建Pods 。 攻击者可以通过这个影子API Server直接获取etcd内存储的内容 , 使后续渗透行为在审计日志中匿名 。
5.7 创建超长annotations使K8s Audit日志解析失败
一般情况下云厂商/安全产品会使用自身日志服务的agent对K8s Audit日志进行采集和解析 , 以便于与后续审计规则结合 。 在入侵检测中 , 日志的采集-存储-计算的过程会受限于agent的性能占用、Server端日志服务以及其他云产品/开源组件对存储和计算的限制 , 过长的字段将有可能触发截断 , 导致敏感信息无法经过审计规则从而绕过入侵检测 , K8s API请求中允许携带1.5MiB的数据 , 但在Google StackDriver日志服务仅允许解析256KB的内容 , 这将导致Audit日志中的敏感信息(如创建Pod时的磁盘挂载配置项)绕过审计 。
示例:通过无意义的超长annotations攻击日志分析链路:
apiVersion: v1kind: Podmetadata: name: annotations-bypass annotations: useless-key: useless-value(1 MiB)...


推荐阅读