Conference - InForSec

Conference

北京之旅

Session 1

Precisely Characterizing Security Impact in a Floodof Patches via Symbolic Rule Comparison

Q: 为什么要识别与安全相关的 bug？
作者在探究之初提出了上述这个问题，然后围绕这个问题进行了很多思考，得出了以下的两点继续研究的动机;

  1. bug 报告数量很大
  2. 补丁与代码的传播不及时

以上两点总结起来可以理解为现有的一些项目或者代码的维护者的数量是有限的，同时每个人的精力也是有限的。对于每天上报的 bug 报告，维护者很难及时和全面的审查这些报告。为此，作者提出了以下 Goal：

Goal: 识别与安全相关的漏洞补丁
具体来说，识别与安全相关的漏洞补丁能够让一些项目或者代码的维护者能够及时的打上那些威胁严重的安全漏洞补丁以防止被恶意攻击者攻击，而不用耗费精力在修复那些无关紧要的 bug。

传统方法
传统的识别方法主要有：

  1. 文本分析：主要是依靠关键字分析
  2. 统计分析：主要是依靠分析趋势

但传统方法具有很明显的局限性，一是其精度难以保证，二是维护者难以判断 bug 的影响力。

通用代码安全规则和违规行为

  1. 界内访问（内存、数组）—— 越界访问(out-of-bound access)
  2. 不允许指针等 free 后被再使用 —— free 后重用(use-after-free)
  3. 变量应初始化后使用 —— 未初始化使用(uninitialized use)
  4. 敏感操作前的权限检查 —— 绕过权限(permission bypass)

基于以上通用代码安全规则和其对应的违规行为，作者提出了一个定义：给定一个代码和补丁，在没有打补丁的情况下，代码会违反以上安全规则。

SID 整体结构
根据上述定义，作者提出了 SID，这是一个基于 LLVM 的解决方案，其框架如下

主要分为三部分：预处理，剖析补丁，符号规则比较

  1. 预处理

在预处理部分，作者首先根据 bug 补丁将软件的版本分为打了补丁的版本和没有打补丁的版本，然后分别调用 LLVM 将其编译为对应的 LLVM IRS。

  1. 剖析补丁

主要是通过静态分析来对不同版本的代码进行分析。在这个阶段，SID 根据补丁模型对补丁进行剖析，以确定关键组件。SID 首先识别出打过补丁和没有打过补丁的版本中的安全操作。接下来，SID 对关键变量进行数据流分析，以收集存在漏洞的代码片段。

  1. 符号规则比较
  • 对于打了补丁的版本
    在打了补丁的版本中，存在的漏洞往往是存在于补丁之后。例如，对于越界访问来说，通常补丁会在进行访问操作之前校验访问的空间是否是正确的。换句话来说，在打了补丁的版本中，违反安全规则这一行为是不存在的，即打了补丁的版本不存在相应的漏洞。
  • 对于没打补丁的版本
    对于没有打补丁的版本，由于其存在漏洞的代码是程序执行流程中可达的，因此执行程序的过程中是会出发漏洞的。换句话来说，对于没有打补丁的版本来说，不违反安全规则这一行为是不存在的，即没有打补丁的版本一定存在相应的漏洞。

通过这两方面的约束，才能够证明这个补丁修复的是一个安全相关的 bug。

方法表现
作者分析了 54K 的补丁，平均对每个补丁的分析时间为 0.83 秒。同时，作者主要从假阳性和假阴性两方面来分析

  1. 假阳性分析
    作者通过 SID 共计找出了 227 个安全相关的 bug，其中仅有 8 个假阳性的样例
  2. 假阴性分析
    53%的假阴性，绝大部分都是因为对安全代码和漏洞代码的覆盖不完全导致的，这是有待改进的地方。

总结

  • 及时修补安全漏洞需要确定安全影响
    • 补丁的传播成本很高，维护者时间和精力有限
    • 为此，维护者需要确定和及时修复那些与安全相关的 bug
  • 使用受约束的符号执行的特性来确定哪些是与安全相关的 bug，哪些是常规的 bug
    • SID：符号规则比较
  • SID 发现了内核中许多被忽视的安全漏洞

Session 2

Automatic Policy Generation for Inter-Service Access Control of Microservices

研究背景
云应用架构的演进，从传统的模块紧耦合、不易维护和扩展的单体架构演变为将模块解耦、独立开发和部署的微服务架构，再到统一管理服务间通信的服务网格。

研究动机
首先是微服务之间通过网络 API 的通信方式会带来一些新的攻击面。其次，不安全的容器镜像可能会导致容器被渗透。

一个具体的例子：

  • 威胁：被攻破的微服务可能通过恶意请求窃取数据或发起攻击
  • 对策：服务间细粒度的访问控制

现在的微服务应用具有规模庞大且频繁更新的特点，如果手工配置访问控制策略的话，不仅耗时巨大且容易出错，也相对没那么灵活。

现有的分布式系统中的安全策略自动化方法：

设计思路
微服务应用的特点：

  • 单个微服务的内部复杂度较低
  • 单个应用类
    • 微服务间的调用方式相对统一
    • 涉及到的服务间调用协议和调用库的数量也十分有限

结合以上特点，作者采用了通过静态分析的方式从微服务代码中提取其正常的系统行为。
于是作者便提出了：
GOAL: 自动生成、维护、更新微服务的服务间访问控制策略
Challenge：如何获取完整、细粒度的服务间调用逻辑；如何对服务间的访问控制策略进行高效的生成和更新


基于静态分析的微服务间调用请求提取
具体来说分为三步：第一步识别网络 API 调用语句，即发起服务间调用的关键语句；第二步以第一步获取的关键语句为起点，沿数据流反向进行污点传播，获取程序切片；第三步通过语义分析在程序切片中提取服务间调用的详细属性。

基于图的微服务间访问控制策略管理
运行时的策略检查时间随着安装的服务间访问控制策略数目线性增加，这会造成整个微服务应用性能下降。

往往同一微服务可能会存在不同版本在同一时间提供不同的服务，这又会造成冗余，于是作者提出了一种优化思路：将同一服务的各版本共有的权限进行整合。这既消除了冗余，减少了策略总数，又消除了不必要的策略更新。

AUTOARMOR


AUTOARMOR 主要由三部分构成：

  1. 静态分析引擎
    服务 E 代码提交，静态分析引擎生成清单文件描述其发起的调用。
  2. 权限引擎
    在 E 部署时，权限引擎获取其清单文件，生成权限节点加入权限图
  3. 策略生成器
    策略生成器根据权限图的变化生成并下发访问控制策略。

策略生成：将与当前权限节点相关的每个请求边翻译成一条服务间访问控制策略；如果一个调用请求的目标微服务尚未部署，就不授予微服务相应的权限

策略更新：版本更新对应版本节点的添加；版本回滚对应版本节点的删除

总结
AUTOARMOR 是第一个微服务间访问控制策略自动生成的解决方案。主要涉及到的一些技术有：

  • 一个基于静态分析的微服务间调用请求自动提取机制
  • 一个基于图的自动化为服务间访问控制策略管理机制

AUTOARMOR 可以有效地实现微服务间访问控制策略的自动生成、维护和更新，但只引入极小的性能开销。

Session 3

Understanding Audit Logs: Techniques, Experience, and Requirements

作者首先分享了其对于研究的一些理解和经验

计算机系统研究的维度
通常来说，开始一项研究往往由 Project/Paper 开始，向下是其具体的 Implementation，向上是其抽象的 Thesis/Theme。
对于 Thesis/Theme 来说，研究者需要将不同的 Claim 归纳为 Statement。

然后需要再将这些 Statement 进行总结，带入自己的一些想法，以形成在自己研究领域中的 View/Insight/Philosophy。

而对于不同的 Implementation，研究者需要再将其转换为 Tool/System/Platform，以方便纵向研究时能够较好地节省重复工作的成本。

综合来说，作为一名研究者，他应该既能写 paper 也能写工具，而读 pape 的目的是要去理解这些已有工作之间的关系，找出其中还没有做或者说还有待改进的地方。当你对于一个领域有一个稳定的 view 的时候才能够更好更深地去看待一个问题，以此来找 idea。

系统研究的维度
人与系统的相互影响如下

  • 系统对系统的影响
    系统与系统之间往往是孤立的，相应的要分析系统与系统之间的关系也就是分析不同系统之间的关联性
  • 系统对人的影响
    系统需要人来操作，相应的系统赋予了人有一定的责任来对系统负责
  • 人对系统的影响
    在系统中加入人的因素，而人往往是一个完备系统中的弱点。
  • 人对人的影响
    人对人的影响往往更多是在人类社会中的法律，伦理等问题上的影响。

Q: 怎么选取和开启一条线的研究?
首先就是要多读这个领域相关的一些论文，在读这些论文的过程中需要体系化的总结。最终的目的是要发现一个缺失的研究点以此找到研究动机。其次，当要解决自己提出的问题，即当找解决方法的时候，可以找其他领域的解决方案然后将其映射到自己的领域里。当然，这个过程中会遇到一些新的挑战，这需要靠自己前期积累的一些背景知识来解决。

总的来说，找到一个感兴趣的新方向，第一是总结前几十年的前人的工作，完备自己的知识储备；第二就是读其他领域的论文，找到解决方案来解决遇到的研究问题。同时，当要将一条研究线做深的时候，后续的代码可以依据前一次实验的基础，例如将一个论文的实现做成 tool 或者 system。

端点监视解决方案记录用于攻击调查的审计日志
审计日志：

  • 表示 OS 级活动的事件历史记录
  • 通过数据证明为安全事件提供可见性

行为抽象中的挑战

  1. 事件语义推断：日志记录一般用途的系统活动，但缺乏高级语义的知识
  2. 个人行为识别：审计日志的数量是十分庞大的

Insights
Q: 分析者如何手动解释审计事件的语义？

  1. 通过审计事件中的上下文信息来揭示系统实体和关系的语义。提取这种上下文语义的一般方法是采用嵌入模型，目的是将系统实体和关系映射到嵌入空间（即数字矢量空间）。
  2. 识别基于数据对象的信息流的行为。文中具体指的是属于个人行为的审计事件，主要是围绕着用户的预期目标，可以反映为一系列应用于数据对象的系统操作。如下图做一次审计事件的简化。

WATSON
WATSON 是一种自动化的行为抽象方法，它聚集了审计事件的语义来模拟行为模式。它不需要专家对事件语义的了解来执行行为抽象。语义是从审计日志中的事件使用背景中自动获得的，这个背景被称为是事件的上下文语义。具体来说，WATSON 首先利用基于翻译的嵌入模型来推断审计事件的语义，其依据是日志中的语境信息。 然后，WATSON 识别出与相关数据对象（即文件和网络套接字）相连的事件，并将其语义汇总为高级行为的表示。最后，WATSON 对审计日志中记录的类似行为进行聚类，并区分出其中的代表，供分析人员调查。

简而言之，WATSON 是一种自动的行为抽象方法，它聚合了审计日志的语义来建模行为模式。其输入为审计日志(Linux Audit)，输出则是具有代表性的行为。

WATSON 弥补了低级审计日志与高级系统行为之间的语义鸿沟：

  • 在基于日志的 KG 中使用上下文信息（事件语义推断）
  • 在语义上聚类相似行为（行为总结）