VED (Vault Exploit Defense): Linux内核威胁检测与防护系统 September 6, 2021 | 5 最小读取

VED (Vault Exploit Defense): Linux内核威胁检测与防护系统

背景

自从1996年Aleph One在Phrack Issue 49上发表了 Smashing The Stack For Fun And Profit的论文后，开启了长期的争夺内存核心控制权的战争，攻击者在之后的10年里大多把目标放在用户空间，但随着用户空间mitigation的普及更多的攻击者开始把核心转移到了内核，2015年，PaX/GRsecurity作者接受华盛顿邮报采访并揭露了Linux内核安全问题后由Google, RedHat, ARM, Intel豪华阵容组成Linux内核自防护计划。

可惜此计划进行了6年后的今天已经接近流产，但Linux则进入了更多重要基础设施的领域，比如电力，能源，车联网，工业控制等，遗憾的是，Linux内核安全的问题依旧没有解决。

alter-text

  • 一个Linux内核漏洞的修复从upstream到发行版内核（生产环境）的链条过长，因为实际情况是没有人会真正意义上使用"upstream"的内核

  • 内核稳定分支以及发行版社区难以跟进每一个安全修复的分析，回归测试以及防御手段，甚至会出现漏掉的情况

  • Linux内核社区坚持"security through obscurity"哲学，这意味着内核社区从来不主动申请CVE漏洞编号，即使如此，2021年1月到8月，有CVE编号的内核漏洞超过110个

  • 漏洞军火商有自己的生态，他们并不关心是否有CVE的存在而只关注漏洞的成因以及漏洞利用的方法

Linux内核常见的漏洞类型：

  • 缓冲区溢出（堆/栈/静态数据）

  • 堆对象错误行为（double-free, use-after-free, etc）

  • 整数溢出（向下越界分配，缓冲区溢出，引用计数，etc）

  • 竞争条件

  • 信息泄漏

Linux内核常见的漏洞利用方法：

  • 执行注入的shellcode，比如ret2usr

  • 执行现有的代码构建ROP/JOP链条

  • 任意读，利用信息泄漏

  • 任意写，污染关键数据结构

我们的方案：VED

为了帮助行业客户解决以上问题，HardenedVault开发的Linux内核0day漏洞防护方案VED的威胁模型基本如下：

作为一个以LKM加载的方案，基本实现框架基于hook，兼容现有Linux内核安全防护的hook方案（比如AKO或者LKRG）

  • 尽量在更早阶段针对漏洞利用平面进行阻断，失败后再进行后期的检测类阻断

谁去守护守护者是一个安全哲学问题，VED是一款重要安全产品，因为它是防护企业生产环境的重要防线（突破内核后就是虚拟化，固件和硬件层了，所以可以说是最后一道有意义的防线），所以VED必须具备自防护特性

VED重要特性包括如下：

  • wcfi，扫描内核代码段并针对漏洞利用常见路径进行防护，支持两种可叠加的防御模式:

    ** 检察返回地址之前一个指令是否是一个call指令（无论是调地址还是调寄存器或指针），这里只判断范围。此feature可以抵御ROP链随机的使用任何block，只有以call开始ret结束的block才可能绕过wcfi，加大ROP的难度

    ** 重要且只可能被直接调用（调用地址，而非寄存器或指针）的函数，VED计算返回地址前的call 指令的地址（一个立即数）指向这个重点防护列表中的函数，满足其条件判断为合法，否则直接阻断。可以阻断结构体的函数指针被修改以后尝试调用提权相关的函数。

  • 针对重要数据结构的防护

  • VSPP（VED自防护体系），这个的重要性在多攻击方的场景更为重要：

alter-text
  • 后漏洞利用阶段中的检测手段，包括针对SMEP/SMAP , creds, MODHELPER等。

车联网场景

根据upstream auto 2020报告，车联网场景中来自云端，车载娱乐系统和ECU/TCU/GW的攻击占比为27.22%，7.69%和5.03%：

alter-text

而这些系统中运行Linux系统的比例是很高的，虽然在国际协作标准组织AUTOSAR针对车联网AP平台安全管理中有对Linux安全防护有一定要求（AUTOSAR APR20-11），但这些要求一方面过于简单，并未将当前车联网系统安全的漏洞利用情况以及场景化加入威胁模型：

alter-text

另外一方面技术层面并未与时俱进，赛博堡垒和AUTOSAR的沟通中提出了一些修订提议。

云原生安全架构

相比传统的物理机和虚拟机为主要业务支撑基础设施，Kubernetes架构对于业务来说大大的降低开发和运维的标准化难度，这对安全是一个利好，基本上基于云原生的架构可以简化为三大组件：

alter-text

  • 基于Falco定制开发的监控和审计系统，数据采集Falco的driver有两种主要模式（这里不探讨基于用户空间的实现），默认是基于tracepoint实现的内核模块去对大约88个syscall监控，第二种是用eBPF对大约81个syscall进行监控，底层实现也是基于tracepoints。企业用户可以基于Falco框架编写和定制代码和规则以满足需求。

  • 针对内核组件的防护，由于Falco增量部署越来越多使用eBPF，所以也需要防护eBPF这个重要的内核组件，另外，针对越级提权和容器逃逸的防护是必要的，这种业务环境哪怕一个容器逃逸成功也可能波及到整个集群的数据安全。

  • SIEM/ELK日志分析平台

在云原生安全架构中，VED可以和Falco监控和审计规则更好的配合，也可以把阻断攻击的日志发送给SIEM/ELK平台进行分析。近期收到了一些漏洞风险的询问，这里演示一个VED如何防御CVE-2021-22555的过程，这个漏洞是在kCTF（基于Kubernetes用于CTF安全竞赛的平台）上发现的：

alter-text