论文笔记- OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis

 

Hassan W U , Noureddine M A , Datta P , et al. OmegaLog: High-Fidelity Attack Investigation via Transparent Multi-layer Log Analysis[C]// Network and Distributed System Security Symposium. 2020.

• 1 摘要

因果分析的最新进展使用溯源图来追踪多阶段攻击。基于系统层审计(例如系统调用)方法忽略了应用程序来源的上下文（例如，email地址，HTTP响应代码），而这些信息可以在系统上更上层获取到。尽管这些信息对于理解攻击行为是必不可少的，但是由于系统不同层之间的语义鸿沟导致这些信息很难应用到因果分析中。为解决这个问题，本文提出了全局溯源的概念，该溯源方法编码了所有相关的因果依赖，不考虑这信息的来自系统哪一层。为了在商用系统中实现这一想法，本文展示了一种在系统与应用日志上下文之间建立语义桥梁的攻击溯源模型-OmegaLog。OmegaLog通过分析程序的二进制文件实现了对应用层行为的识别与建模，并且实现了应用程序事件与系统层访问的精确协调。然后，OmegaLog截取应用程序运行时的日志行为，并把其嫁接到系统层的溯源图上，可以辅助攻击调查人员更准确的推断出攻击的性质。OmegaLog系统可以广泛的应用于现有的软件系统中，在无需任何培训与开发人员干预的情况下可以显示的提升溯源图的执行划分。通过真实攻击场景的评估，可以看出本文方法能生成更简单的溯源图，同时也包含了更丰富的语义信息。

• 2 引言

当前系统入侵技术变的越来越复杂。尤其是APT攻击的攻击越来越偏重“低而慢”的攻击策略，攻击者在执行毁灭性攻击之间会在目标系统中潜伏很长一段时间，尽可能多的收集信息以扩大攻击范围。攻击者通过技术手段绕过企业防护设备，可以在目标系统中潜伏数周甚至是数月，就像当前很多备受关注的数据泄露事件一样。

在这种情况下，系统审计技术的发展对检测、调查和最终的威胁响应都是至关重要的。关数据溯源已经在传统的系统审计日志中被应用关取得了很好的效果，数据溯源可以把孤立的系统事件解析成溯源图来实现对系统历史执行的图谱化。溯源图可以辅助调查者根据因果关系追踪攻击的根因与影响，基于此，因果分析可以从离线的调查工作变成高效的实时的攻击溯源方法。

显然威胁调查是系统防御的关键，但是之前的因果分析相关工作都忽略了应用层的语义。以图1为例的web服务应用为例说明。

图1 NGINX应用

图1(a)表示事件序列，可以看出首先web服务接到两个HTTP请求会产生如图b所示的系统日志，此外该服务本身还会维护自己的事件日志如图c所示，而这个日志对于系统来说是不透明的。当前的因果分析方法会根据系统日志生成如图d所示的溯源图，而类似于图中的应用日志的信息被没有被编码到溯源图中，但是在分析过程中应用日志是主要提攻击调查取证的依据。

已有工作主要是基于系统日志来解决依赖爆炸问题，没有考虑应用层语义，也就是说这些工作没有为跨层攻击调查提供一种通用的、可靠的解决方法。关于已有工作可以参考原文介绍。

本文认为将系统上所有与取证相关的事件统一到一个整体日志中可以显著提高攻击调查能力。为了在当前商业系统中有效实现这一功能，本文提出了一种端到端的溯源追踪框架-OmegaLog，该框架集成了应用程序事件日志与系统日志生成了一个全局溯源图（UPG）。该图集成了系统层的因果分析能力和应用事件日志的语义上下文。OmegaLog 实时的解析分散的异构应用程序日志并与系统日志关联起来生成全局溯源图。Omegalog通过应用程序事件序列识别事件处理的环路来解决依赖关系爆炸问题，同时因为集成了应用程序的日志解决了语义鸿沟问题。同样，OmegaLog不需要在应用程序或是系统上安装任何工具。

全局溯源框架的依然面临一些挑战。首先，软件日志框架的生态系统是异构的，事件日志与其他文件I/O基本相似使，因此很难自动识别应用程序日志行为。其次，事件日志在应用程序中的多个线程之间进行多路复用，因此很难区分并发工作单元；最后，应用程序中的每个工作单元都无法生成事件日志，这些事件的发生和顺序是根据动态控制流而变化的，因此需要深入了解应用程序的日志记录行为，以确定执行单元分区的有效边界。

为解决以上问题，OmegaLog对应用程序二进制文件执行静态分析，以自动识别日志消息写入过程，使用符号执行和仿真为每个调用点提取描述性日志消息字符串（LMS）。接着，OmegaLog对二进制文件进行时序分析，以识别LMS之间的时序关系，生成一组在执行期间可能出现在的所有有效的LMS控制流路径。在运行时，在运行时，OmegaLog使用内核模块拦截写系统调用并捕获应用程序发出的所有日志事件，将每个事件与正确的PID/TID和时间戳相关联，以梳理并发日志活动。最后，这些处理的应用程序日志与系统级日志合并成全局溯源日志。在攻击调查中，OmegaLog可以在通用日志中使用LMS控制流解析应用事件流，将其划分成执行单元，并基于因果关联将其加入到溯源图中。

本文的主要贡献如下：

1 本文提出了全局溯源的概念，全局溯源集成了系统溯源的优点和应用程序日志固有的记录的灵活性为解决通用的威胁调查解决方案；

2 设计了一种有效的二进制分析技术从应用程序日志中提取日志行为。提出了OmegaLog来有效的收集并集成应用程序事件日志和Linux审计日志。

3 实验评估了OmegaLog的性能，其在系统中资源小号低于4%，可广泛的布置到现有的系统中，并能在真实的攻击场景中实现语义丰富的攻击重构。

• 3 动机

本节主要以在线购物网站的数据泄露和破坏攻击为例说明本文的研究动机。首先以此例说明现有攻击溯源系统的局限性。

示例：一个简单的WordPress网站托管在一个web服务器上，对网站的请求首先由HAProxy接收，HAProxy主要是负责实现web服务器上不同apache实例之间的负载均衡，而客户事务被记录在pgsql中。管理员已经找开了Apache httpd、HAProxy和PostgreSQL的应用程序事件日志记录。同时，服务器也在通过linux内核或是linux溯源模块（LPM）记录系统级日志。如果一天管理员发现了网站被涂改，一些敏感的客户信息被发布到了Pastebin网站上。然而一般网站通常每天会有数万请求，从这么多请求中找到一个恶意请求是一个是一个比较具有挑战的工作。

3.1应用事件日志

为了确定攻击事件并实现有效的攻击响应，管理员首先通过应用事件日志进行取证调查。管理员首先发现accounts数据库被访问，以此为起点进行调查。管理员对pgsql执行了grep查询返回如下查询日志：

该日志信息表明攻击者利用了网络的SQL注入漏洞，同时该攻击者访问了admin.php的login证书，这说明攻击有能力获取网站访问权限。

应用程序日志信息的局限

攻击调查到此，管理员无法仅通过应用事件日志来进行调查。显然，HAProxy和Apache httpd日志包含了与SQL注入攻击相关的重要证据，但是重新执行同样的grep查询在Apache日志上并没有返回任何结果。这是因为攻击使用的POST命令发送的SQL查询，而该SQL查询并没有包含在URL中，因此Apache日志无法提供相关证据。到此调查过程就停滞了，主要是面临的问题：1）获取与恶意http请求相关联的IP地址；2）如何利用登录证书来破坏网站，以及除了发现的问题之外还有没有其他破坏行为？3）网站上哪个PHP文件没有有效处理用户输入从而暴露了SQL注入漏洞？这些问题反应了应用程序事件日志的局限性，也就是无法跨应用对攻击事件进行因果关联分析，因此无法对溯源工作流的依赖关系。

3.2系统日志调查

图1 SQL注入攻击的系统溯源图

 

为了进一步调查，管理员使用系统层的日志进行因果关联分析。在系统层很容易对工作流的多个协作过程进行追踪溯源。由于之前的恶意查询肯定会产生PGSQL的读操作，管理员使用/usr/local/db/作为出发点，通过回溯查询生成如图2所示的溯源图。由于系统日志本身的限制这种溯源图也无法继续推进攻击调查过程。

系统日志的局限

由于系统日志的依赖爆炸问题，管理员通过回溯会发现数千个导致SQL注入的根因。这是因为系统层的溯源保守的假设一个进行的输出与所有进行的输入都有因果关联。尽管恶意查询字符串是已知的，但是在溯源图中因果分析引擎关不会将查询与/usr/local/db/datafile.db的特殊出边关联到一起。即使限制了Apache httpd和postgresql之间大部分依赖关系，但是在确定HAProxy到Apache httpd的攻击路径上依然会碰到同样的问题。

当前的一些研究工作通过执行分区来解决依赖爆炸问题。这些系统将长时间运行的执行过程分解成多个独立单元，每个独立单元表示一个事件处理循环的迭代，这样输入输出之间的依赖关系就只能通过相应的独立单元来进行追踪。但这些方法都有明显的局限性，如表1所示。

这些方法大都需要额外的设备来识别单元边界，需要领域知识或是手工操作，并且假设二进制文件都是可修改的，但是在真实情况下这是不被允许的。

系统日志溯源技术另一个局限就是语义鸿沟。现在的系统级的溯源技术的优势在于从全局视角来进行攻击溯源，但是缺少对专有应用程序的行为知识，这是攻击重构的关键。在本文提到的示例中无法从系统日志中提取如失败的登录尝试、HTTP头文件、WordPress插件行为和SQL查询等信息，这些信息需要从每个应用日志中获得。

当前已有一些研究工作来试图解决系统溯源的语义鸿沟问题，这些方法主要是动态或静态的检测调用函数，以公开函数名、参数和返回值。但这种基于设备的每张有如下几个局限：1）开发人员需要针对固定需要进行开发，需要领域专家知识；2）日志信息基于每个应用程序采集的因此无法关联信息流；3）函数调用过程无法完全获取到高级语义事件。

3.3 OmegaLog

最近在应用程序日志[25]、[65]、[64]、[21]、[49]方面的工作显示了应用程序日志在程序理解、调试和分析方面的作用。OmegaLog基于这些工作的启发，在攻击调查中使用一应用程序日志。OmegaLog方法的思想依据的是开发人员已经完成了以事件日志语句的形式编码高级应用程序语义的艰苦工作，这些日志信息不仅包含了攻击调查需要的取证信息，还标准了程序中执行单元的边界。事件日志语句的插入是良好的软件实践的有机副产品，可以使开发者和用户能更好的理解程序运行行为。因此，可以使用应用程序语义来丰富系统日志，而无需额外的设备或是分析。此外，这些应用程序日志可以用来识别执行单元。

图3 OmegaLog生成的SQL注入攻击的溯源图

如果利用OmegaLog应用到上文的例子中会生成如图3a所示的溯源图。管理员可以把SQL查询与特定的系统调用事件（读操作）关联。通过使用OmegaLog的日志行为分析在Pgsql上执行划分，管理员可以追踪Apache httpd发出和接收过程的系统调用，同样追踪清凌凌的水在还可以用来对易受攻击的web表单的应用程序事件进行注释。然后，OmegaLog再次使用执行分区来追踪HAProxy中的正确工作单元，以识别攻击者的IP地址。在发现攻击如何窃取用户数据和登录证书来进行SQL注入之后，调查员试图通过对index.html的回溯查询来确认网站是如何被破坏的。根据OmegaLog生成如图3b的溯源图，调查者可以推断出攻击者使用WordPress文件管理插件更改了index.html。

• 4 模型与假设

本文工作主要是针对攻击者首要目标是利用系统上运行程序的安全漏洞，并泄露或操作系统上的敏感信息。本文对操作系统的完整性、内核审计框架、审计日志和应用程序事件日志等做了典型假设，所有这些都是在可信计算基础上的。通过信息强化技术使这一假设更加合理，这些技术主要用来减缓系统日志的威胁。与之前基于执行分析的溯源方法一样，还需要假设应用程序控制流的完整性。硬件层的木马、侧信道攻击和后门不在本文讨论范围之内。

• 5 应用程序日志行为

本文通过将长时间远程的程度划分为执行单元来解决依赖爆炸问题依赖于事件日志在这些应用程序的普遍性。幸运的是，应用登录的重要性已被广泛认可，所有开源程序都会打针事件日志消息，提供了四种详细的级别：FATAL是对一个错误执行关闭，ERROR是指对任何操作都致命的错误，INFO是一般可用信息，DEBUG是对诊断有用的信息。显然这种级别是可包含的，也就是上层日志信息会包含在下层日志中。

为了将应用程序的执行成功的划分到几个单元，需要在事件处理过程中包含详细的INFO或DEBUG日志信息。但是，这些应用是否具有这些功能并没有被确认。本文收集了79个不同类型的长期运行的LINUX应用，并查看了这些应用的源代码和手册以确定事件处理机制并了解这些应用是否为每个事件都打印了相关日志信息。结果如表2所示，观察到39个应用程序在事件处理过程中打印包含INFO和DEBUG详细日志，8个应用程序只在INFO级日志，17个应用程序只记录了DEBUG日志。同时发现有15个应用没有任何相关的日志信息。我们将这些应用分为如下几类：

轻量级应用：为了保证最小的资源占用一些固定的client-server应用被设计为轻量级应用，比如thttpd web服务和skod FTP服务，这些应用并不会对新的事件产生日志信息。

GUI应用：这次调查中发现17个GUI应用中有12个应用要么不会打印日志信息，要么打印的日志信息与调查取证无关。

本文的研究表明，在长期远行的应用的事件处理过程中已具有足够的日志信息，这些信息能够自动识别应用的单元边界。为了便于评估，本文只使用了如表3所示的应用。GUI应用通常使用带有回调的异步I/O，并且这种编程模型目标OmegaLog并不支持。

• 6 设计概述

6.1 定义

系统级溯源图：由系统级审计日志生成的一种图模型，其中顶点表示系统主题（进程）和系统对象（文件和socket连接），边表示因果依赖关系。边也具有一些信息比如时间戳和事件类型（文件读写等）。

因果分析：攻击调查者通过在溯源图进行分析来找到攻击源与其他未发现的攻击事件，而溯源图主要是利用图的因果分析方法。对于攻击调查者来说，可以以发现的攻击事件为切入点，在溯源图中执行回溯查询定位攻击源，然后再利用前溯(forward tracing)根据攻击源长到未发现的攻击事件，并返回所有的因果关联事件，来解决整个攻击过程。

因果分析的性质：攻击溯源过程中的因果分析应该具有以下三种性质：1 有效性表示溯源图应该描述正确的系统执行过程，也就是溯源图中的实体之间如果没有因果关系不应该存在边；2 可靠性是指的是在进行溯源时是对之前的关系进行分析；3 完全性是指自包含并且能完全解释相关事件的。

6.2 研究目标

针对以上提出的问题，本文提出以下研究目标：

1 语义感知：本文的攻击调查过程必须包含所有与攻击相关的应用程序的上下文化相关的高级语义事件。

2 广泛适用：本文解方案应该能直接部署到企业环境中，而不需要依赖其他设备或是开发人员详细说明，此外本解决方法的技术应对应系统架构是不可知的。

3 取证的正确性：本文的解决方案对现有的系统级的溯源的修改都必须支持其已有的因果分析查询，并且其有效性、可靠性和完全性。

6.3 OmegaLog

图5示出了OmegaLog系统的高级概述，该系统要求同时启用系统级日志记录和应用程序事件日志记录。

OmegaLog的功能分为三个阶段：静态二进制分析、执行过程、调查取证。在静态二进制分析阶段，OmegaLog首先分析所有应用程序的二进制文件，提取所有描述代码中事件日志语句的LMS，然后使用控制流分析识别LMS在程序中不同执行中的所有可能时间路径。所有这些LMS控制流路径都被存储到一个数据库中，然后输入到日志分析器来辅助解释应用程序的事件。OmegaLog捕获所有应用程序事件，并使用应用程序的PID/TID和通过内核模块截取写入系统调用的日志事件的时间戳对其进行扩充。OmegaLog将通用日志和LMS控制流路径数据库传递给一个日志解析器，该解析器通过插入一个新的应用程序日志顶点来对整个系统图中的相关进程进行分区。最后，基于语义感知和执行划分后的图被称为全局溯源图，呈现给调查者来辅助攻击调查取证。

•  7 OMEGALOG：静态二元分析阶段

静态分析例程在应用程序二进制文件执行之前对其进行概要分析。在静态分析过程中，OmegaLog对二进制文件的控制流图（CFG）执行多次传递，以识别日志记录行为并生成在该二进制文件执行期间可能出现的所有LMS路径。具体来说，利用Angr[53]工具链来构建CFG，然后引入新的方法来自动识别二进制文件中的日志记录程序。接着，使用识别识别结果具体化LMS，最后生成在二进制代码执行期间可能出现的所有LMS控制流路径。这个过程如图5中所出。

由已有的工作可知二进制分析的代价很高。接下来介绍，OmegaLog如何在分析应用程序避免这种高代价的执行成本。为了方便使用源代码片段解释静态二进制分析过程，如算法1。

7.1 日志识别

事件日志框架的相关的系统是多样的和异构的。为此，OmegaLog使用两种启发式方法在二进制文件中标识日志：1） 应用程序使用知名的库或功能类似的自定义程序来生成、存储日志消息并将其刷新到日志文件。这些库利用Libc的I/O过程将日志消息写入磁盘。OmegaLog可以通过从这些进程调用站点向后遍历CFG来识别候选日志过程；2） 默认大多数创建事件日志的应用程序将消息存储在/var/log/目录中，OmegaLog可以根据文件路径区分日志I/O和其他I/O，并将所有写入/var/log/目录的过程视为日志程序。将这两种启发式方法结合起来足以识别评估数据集中应用程序的日志记录行为。另外，如果二进制文件不遵循上述约定，OmegaLog还提供了一个接口，系统管理员可以使用该接口添加日志过程的名称。

7.2 抽取LMS

在识别所有的日志程序名之后，为每个日志过程调用站点分配一个唯一的标识符。需要生成一个LMS来描述日志消息的专有格式（模板）。此步需要OmegaLog提取二进制文件的完整控制流图，并提取此类参数的值，把这个过程称为具体化。然而，对二进制文件执行完整的符号执行是一个计算开销很大的操作，会导致路径爆炸问题，特别是对于具有复杂编译时优化的应用程序。事实上，在对表3中列出的应用程序进行实验时，我们意识到大多数应用程序都是使用至少-O2编译器优化级别编译的，这使得CFG提取和符号执行的任务非常复杂。

为了解决这个问题，我们的主要目的是获取用于记录函数调用的格式说明符参数，不满足此目的的任何符号执行操作都是不必要的。因此，OmegaLog首先引用在没有符号执行的情况下构建的CFG，这是通过遍历二进制文件并使用一些启发式方法来解决间接跳转而生成的，这种方法大大降低了CFG的计算代价。使用FastCFG，可以识别包含函数调用或跳转到日志程序的基本块，在处理过程中只关注这些块。与完整的CFG不同，FastCFG不保留任何关于二进制文件的状态，因此OmegaLog可以具体化日志程序中参数的值。

为了有效的实现分析，引入了一种优化的具体化方法，称为peephole具化。基于表3所示的开源程序分析，可以看出在大多数情况下，日志记录的格式说明符参数要么作为直接常量字符串传递，要么通过入驻调用附近定义的固定变量传递。

使用peephole具化，只需要从上一步中标识的基本块进行本地符号执行，在执行对目标日志程序的调用指令后直接停止。在算法1中，给出了peephole具化的伪代码。如果给定基本块的符号执行任务未能具体化LMS值，OmegaLog将从每个前导任务（在算法1中b:predecessors()）启动新的符号执行任务。将从基本块的前件重新启动符号执行的操作称为回溯。OmegaLog通过在给定块上执行maxBackTrace回溯操作后停止符号执行来限制具体化步骤所使用的计算资源。如果在maxBackTrace操作之后符号执行无法生成具体化的LMS值，OmegaLog会将函数标记为未解析，从而生成不完整的LMS路径。

本文算法在上下文敏感度情况下会产生不确定的LMS路径，在这种情况下，函数调用会因为有不同基本块序列而具有不同的格式说明符。为解决这个问题，需要记录不每个LMS路径的调用堆栈。如果两个不同的调用堆栈为日志函数调用生成不同的LMS，那么将为每个调用创建一个新的LMS，然后将其与每个相应函数调用的最基本块相关联。这个过程将保证不会遗漏任何LMS，并且在构造LMS控制流路径时不会保证了LMS之间的可达性在一个合理的范围。使日志过程的格式说明符依赖于上下文在实践中并不常见，我们只在处理传输和CUPSD应用程序时遇到过这个问题。

7.3  构建LMS正则表达式

一旦LMS被具体化，就可以提取一个regex用于在运行时匹配事件消息。生成的regex描述LMS的格式说明，这依赖于运行时的上下文（例如%s、%d、%s）。每个格式说明符以一个合适正则表达式替换，例如，“%d”替换为“[0-9]+”，“%s”替换为“.”。例如，在OpenSSH中遇到的一个LMS是

提取后会变成如下形式：

7.4 LMS控制流路径生成

在使用选择性符号执行具体化LMS之后，OmegaLog可以持续使用FastCFG枚举在应用程序的生命周期中可能出现的LMS的有效序列。由此提取的所有可能的路径并不能直接应用深度优先便利。主要有如下原因：（1） 同一个基本模块可能会被不同的调用者调用多块，因此需要多次遍历；2）调用指令必须与相应的返回或是跳转指令相匹配；3）应用程序使用了大量的迭代与递归函数，这需要多次遍历避免跳出循环路径。为此这里通过缓存和临时节点来解决1与2的问题，通过固定点迭代解决问题3.

OmegaLog将路径识别任务划分为多个局部遍历功能模块，这将对每个函数生成子图。然后通过如下的调用或是返回/跳转指令关联这些子图构建完整的LMS路径图。对于二进制函数中的每个函数 (在算法1中cfg:functions())，OmegaLog标识控制流进入函数的入口点，以及控制流穿过f局部体的出口点，为这些点创建虚拟的LMS节点。然后OmegaLog对函数f的子图执行局部遍历。

每当OmegaLog遇到一个包含LMS的基本块时，该块就被添加到路径中，并遍历其传出边。为了准确捕捉循环行为，在循环边上执行固定点迭代，直到构建的LMS路径不再发生更改。也就是遍历同一循环边，直到不再检测到LMS路径。最后，为了加快遍历速度，OmegaLog缓存处理过的基本块，以便在多条路径重合时只需遍历它们一次。需要注意的是这里不考虑不包含任何系统调用的任何循环，因为此类循环不会生成审核日志。

在构建函数局部子图之后，OmegaLog解析每个子图中的调用和跳转指令，从而完成完整的LMS路径。对于LMS路径上的每个函数的调用，OmegaLog通过在调用 者的的基本块和被调用方的入口点之间以及被调用方的出口点（针对调用方的返回块和跳转指令）和被调用方的返回基本块之间创建链接，将被调用方的子图注入到路径中。基于此OmegaLog生成了完整的LMS路径，还通过创建自循环来处理递归函数。随后，OmegaLog通过删除BUILDLMSPATHS函数创建的虚拟节点并合并它们的扇入和扇出边来压缩图的规模。生成的压缩图将包含所有检测到的LMS路径。图6表示代码片段的LMS控制流路径的示例。代码片段在图的左侧，相应的LMS路径在图的右侧。从log3到log2的无法形成一个环，也就是会循环的出现在路径中多次。

LMS控制流路径用于指导OmegaLog将通用源代码日志划分为执行单元；但是，在某些应用程序中，在事件处理循环中打印的LMS不够精确，无法划分事件过程。例如，图4所示的Redis事件处理回路中每个迭代都打印两个LMS。第一个LMS在accept系统调用之后打印，如果基于这两个LMS划分事件处理回路的话只能捕获在两个LMS之间发生的系统调用，而损失了执行单元中的accpet系统调用。如果只对每二个LMS进行事件回路划分的话那么能得到正确的执行单元，这是因为在每二个LMS之后没有事件处理回路。

因此，在LMS控制流路径的构建过程中，OmegaLog标记了在该循环之前或之后没有任何系统调用的循环中存在的所有LMS。这种标记有助于OmegaLog在调查阶段对全局溯源日志进行正确的执行分区。如果循环中没有这样的LMS，那么OmegaLog将跟踪循环中最后一个LMS（loopending LMS）之后出现的所有系统调用，或者跟踪循环中第一个LMS（loop starting LMS）之前出现的所有系统调用。OmegaLog在调查阶段使用这样的系统调用映射来创建正确的执行单元。

7.5 静态分析局限性探讨

本文的方法对于底层的二进制分析工具是不可知的，但是这里使用了Angr工具，它本身有一定的限制。这里不详细说明了，感兴趣的可以参考原文。

• 8 OMEGALOG：运行阶段

在运行时，OmegaLog对应用程序和整个系统日志执行最小代价的维护；LMS控制流路径模型存储在数据库中，在开始调查取证之前，不会被检索。在运行时OmegaLog所面临的主要挑战是协调来自不同层的日志。为了解决这个问题，OmegaLog使用内核模块截取主机上的所有写调用，并使用第6节中的启发式方法标识哪些写调用属于应用程序事件日志记录。之后，只将发出事件的进程/线程的PID/TID以及事件发生的时戳附加到标识的日志中消息。最后，OmegaLog使用Linux审计API将集成的事件日志消息添加到整个系统来源日志文件中，该文件为应用程序级和系统级事件提供了执行顺序信息。

• 9 OMEGALOG：调查阶段

在攻击事件发生之后，管理员可以查询OmegaLog的日志分析器和图生成器模块，以构建记录与入侵相关的系统和应用程序层事件的UPG。

9.1 全局溯源

在攻击调查阶段，集成了二进制文件、系统溯源日志和应用程序事件日志生在保证因果分析三个特性的前提下生成UPG。算法2描述了如何从全局日志文件中构造反向跟踪UPG，特别是从可观察到的攻击事件中构造反向跟踪查询；构建正向跟踪图的方法也可基于该算法，因此不重复介绍了。在解析全局日志时如遇到应用程序事件日志时，需要将该事件与LMS路径中已知的应用程序LMS进行匹配。该过程是通过MATCHLMS函数完成的。

9.2 LMS 状态匹配

这个过程需要将运行时应用程序日志与LMS控制流路径DB中的相关LMS进行匹配。对于全局日志中的每个日志，匹配器标识所有候选匹配的LMS正则表达式。

LMS排序。应用程序日志可能与LMS路径DB中的多个LMS 正则匹配；这是因为LMS中普遍存在%s格式说明符，它可以匹配任何内容。因此，OmegaLog需要对所有可能的候选匹配进行排序。使用正则表达式匹配来标识每个匹配中非正则表达式（即常量）的数量。最后，匹配器将返回具有最高排名或非正则词匹配数（反映候选LMS中的真实状态）的LMS。

状态机匹配。一旦候选LMS被应用程序日志项识别，OmegaLog需要在数据中为候选LMS匹配一条有效的LMS路径。如果是首次的话，需要利用启发式算法长到开始点。由于匹配过程可能发生成应用程序生命周期中的任何时候，因此需要对LMS控制流路径中的所有节点都进行彻底的搜索。在确定初始点后，在解析器中保留状态，会指向LMS路径图中可能的状态转换。在下一个日志中，搜索前一个LMS的邻居以寻找可能的候选匹配，对它们进行排序并返回排名最高的一个；然后前移解析器的状态指针。如果OmegaLog在相邻的LMS状态中找不到匹配，它将前移到lookahead和lookback匹配步骤。

前向匹配。当已知LMS路径中的前一个状态时，可能无法在相邻LMS状态中找到匹配项，主是因为1）应用程序正在不同的日志级别上运行；2）OmegaLog在静态分析阶段错过了与日志消息对应的LMS； 3）日志消息来自第三方库。因此，需要深度研究当前解析状态的可到达状态。如果我们找到多个候选人，我们再次对他们进行排名，并返回排名最高的候选人。如果无法找到，需要继续增加lookahead，直到达到可运行时设置的某个阈值。如果找到匹配项，将解析器移动到该状态并重复，直到在LMS控制流路径的末尾匹配一个候选LMS。把flag设为true。

如第6节所述，在某些情况下，LMS可能无法进行正确划分，因为在循环结束LMS之后或是在循环开始之前有系统调用。离线时OmegaLog会标记这些LMS，并跟踪在运行时期望的任何系统调用。如果在状态匹配过程中观察到这种情况，那么除了匹配LMS之外，还匹配需要相关的系统调用，并将这些系统调用添加到执行单元中。这对应算法2中的函数MATCHLMS，并将标志设置为true。

Lookback匹配。如果在LMS路径中找不到结束状态导致Lookahead匹配失败，则首先尝试搜索LMS控制流路径中形式为(while(1), for(;;))的循环。Lookback匹配的依据是，已经启动了一个新的执行单元，因此需要从一个新的阶段重新启动。如果失败了，对LMS路径中当前状态之前可能发生的LMS执行彻底搜索。如果在两种情况下，得到一个匹配，将标志设置为true。注意，Lookback匹配会生成执行单元，即使在循环的开始或结束时只有一条日志消息，因为我们使用下一个执行单元的日志消息来划分当前执行单元。

• 10 评估

在本节中，将对 OmegaLog进行实验评估以回答以下研究问题（RQ）：

（RQ1）：从二进制文件中提取日志信息时，OmegaLog的静态分析程序的计算代价是多少？

（RQ2）：在应用程序中找到所有LMS时，的二进制分析的安全性达到什么程度？

（RQ3）：相对于典型的日志基线，OmegaLog在运行时会带来多少额外的时间和空间开销？

（RQ4）：全局溯源图满足因果关系的正确性么？

（RQ5）：相对于典型的因果分析方法，OmegaLog在重建攻击方面有优越程度？

实验环境

针对18个实验应用程序评估了本文的方法。根据受欢迎程度和类别，从第四节讨论的应用程序库中选择了这些应用程序。此外，这些应用中的大多数都用于评估先前的种源追踪工作。在考虑上述研究问题时，将每个程序分为两个详细级别：INFO和DEBUG。使用标准基准测试工具（如Apache Benchmark ab[1]和FTPbench[2]）为数据集中的应用程序生成工作负载。

所有测试都是在一台服务器上进行的，该机器采用英特尔酷睿[email protected]，内存32gb，运行Ubuntu 16.04。为了收集整个系统源代码日志，使用Linux审计模块和以下syscall规则集：clone、close、creat、dup、dup2、dup3、execve、exit、exit group、fork、open、openat、rename、renameat、unlink、unlinkat、vfork、connect、accept、accept4、bind。OmegaLog的离线算法使用了一个单独的配置参数maxBackTrace，它设置符号执行操作的最大深度。在对该参数进行实验之后，发现取5足以保证我们分析的18个应用程序中的12个应用程序的95%的覆盖率。

10.1 静态分析的性能

表3显示了从应用程序二进制文件中识别和具体化LMS并随后生成LMS路径模型所需的时间（算法1）。可以看到构建LMS路径的开销对于一次性成本来说是合理的，大多数应用程序需要1-8秒，PostgreSQL最多需要3分钟；PostgreSQL的时间是由于OmegaLog捕获的LMS路径数量过多导致的。另一方面，生成LMS列的平均时间显示生成FastCFG和具体化LMS的时间在OmegaLog的静态分析任务占绝大部分，从最短一分钟半（传输）到最长1.2小时不等。。这两项任务实际上高度依赖于Angr的性能。正如Angr工具开发人员所承认，由于用Python语言编写的所以静态分析器的性能受到了限制，而且没有对并行执行的官方支持。

实验结果表明，所分析的应用程序二进制文件的大小与分析时间没有直接关系。通过检查应用程序的源代码，发现OmegaLog的性能更多地取决于代码的结构和日志程序。可以直观地看到，随着发现的callsite数量的增加，所需的peephole符号执行步骤的数量也随之增加，从而会导致具体化时间的增加。但这并不能适用于所有的应用程序；例如，对NGINX（2044kb二进制）的分析在13分钟内完成925 LMS的具体化，而Lighttpd（1212kb，几乎是NGINX二进制大小的一半）只需要32分钟就完成了358 LMS的具体化。

在对Lighttpd的源代码进行更深入的研究后，发现格式说明符（以及LMS）通常作为结构成员而不是常量字符串传递。这将触发peephole 级联算法的回溯行为，试图具体化结构成员的值，从而增加Angr执行符号执行操作的成本。下面将展示Lighttpd中触发这种行为的示例代码片段：

Lighttpd和NGINX的例子表明当只考虑二进制大小或已识别的调用站点的数量时，OmegaLog静态分析运行时的不可预测性。运行取决于代码的结构和对日志函数调用的剖析。

10.2 静态分析完备性

OmegaLog的覆盖率代表了具体化的LMS相对于日志过程中已识别的调用站点计数的百分比。如表3最后一列所示，除了PostgreSQL、Transmission和wget之外，OmegaLog的覆盖率为95%。这里不考虑thttpd，因为它只是一个小样本量的LMS。其中OmegaLog在具体化过程中只漏掉了1个LMS，这说明OmegaLog有能力持续获得所需的LMS，并构建相应的LMS控制流路径。实验表明，这种覆盖率足以使OmegaLog在不损失精度的情况下执行划分和辅助调查过程。此外，当LMS丢失时，OmegaLog的运行时解析器可以通过前向和后向技术处理丢失的日志消息。如果OmegaLog无法具体化LMS，这反映了符号执行任务解析日志过程格式说明符的能力。

为了更好地了解OmegaLog的性能状况，分析了PostgreSQL、Transmission和wget的源代码（覆盖率分别为64%、78%和31%）。分析显示，在这三种情况下，符号化执行无法处理使用GNU的gettext进行内部化的日志程序，如下所示：

由于gettext作为共享库动态加载，Angr无法在符号执行期间对其进行适当处理，也无法提取其返回值，从而导致在peephole具体化步骤对LMS提取失败。为了证实，重新对wget和Transmission进行了静态分析，删除了对gettext的调用，覆盖率分别为98.18%和96.03%。使用Angr解决这个问题就是需要为所有gettext方法添加hooks，并在不做任何更改的情况下返回参数。这将反过来为Angr的符号执行引擎提供具体化的参数。计划在今后的工作中解决这个问题。

10.3 运行时间和空间开销

测量了OmegaLog的运行时开销，并将其与运行Linux审计的INFO和DEBUG详细程度上的应用程序事件日志收集基线进行了比较。根据执行分区所需的应用程序日志记录行为打开信息和调试级别。如图7所示，对于在事件处理循环中进行日志记录的所有应用程序，OmegaLog的平均运行时开销为4%。一些应用程序，比如Memcached和Proftpd，由于它们是写密集型应用程序，因此开销很高。由于OmegaLog会截取每个写系统调用以消除PID/TID的歧义，因此会有更高的执行代价。然而，OmegaLog在取证分析中的优势已经证明了其执行代价的合理性，并将在未来的工作中考虑用于过程消歧的替代方法。

因为它OmegaLog会记录每个应用程序事件消息的PID/TID和时间戳，因此也会有空间上的开销。每个LMS条目最多需要12个字节。实验证实，在典型的使用过程中，这种空间成本可以忽略不计。例如，NGINX中的每个未增强事件消息大约为8.6kb。如果NGINX服务器每天接收100万个请求，每个请求生成一个事件，那么原始的事件日志将为860 MB，OmegaLog将仅添加12 MB，大约1%的空间开销。

10.4 全局溯源图的正确性

OmegaLog通过添加应用程序日志顶点来修改系统溯源图，生成语义感知和执行分区的全局溯源图。在第五章中，描述了三个因果分析的性质，全局溯源图需要在取证过程中保证其正确性。

为了保证算法的有效性，在运行阶段用PID/TID信息和时间戳来增强LMS，从而使整个系统溯源图中的应用程序日志顶点和进程顶点具有因果关联。为了确保稳健性，OmegaLog使用来自与整个系统溯源图相同的系统时钟的时间戳来增强LMS，并使用该时间戳作为从进程顶点到应用程序日志顶点的标注。最后，由于全局溯源图没有删除任何因果连接的顶点，保证其完备性。

10.5 攻击调查

图8（a）给出了使用传统因果分析解决方案的攻击调查结果，该解决方案确认访问了敏感文件。但是，由于依赖关系爆炸，无法确定谁访问了该文件以及将其传输到了哪里。相反，图8（b）表示OmegaLog产生的全局溯源图。OmegaLog能够根据事件日志分析将服务器划分为不同的工作单元，消除依赖性爆炸，并识别敏感文件下载到的IP地址。然而，这些信息可能证明不够精确，无法将攻击归因于特定的员工或远程代理。幸运的是，由于OmegaLog能够将因果图与来自FTP服务器的事件消息相关联，因此管理员能够将盗窃归因于一组特定的用户证书。虽然现有的执行分区系统可以消除这种情况下的依赖性爆炸，但它们不会启用攻击的用户级属性。

网络钓鱼电子邮件：员工使用Mutt电子邮件客户端在BYOD工作站上发送和接收个人电子邮件。有一天，该员工收到一封钓鱼电子邮件，其中提供了下载大片电影的种子。员工打开电子邮件，下载附加的.torrent文件，然后利用下载工具下载该电影。员工打开下载的电影文件，但该文件实际上是恶意软件，在机器上建立后门。

管理员随后注意到工作站上正在运行可疑程序，并启动调查取证分析以确定其来源。图9（a）示出了基于简单审核的调查将产生的因果图。如图所示，该员工实际上已经用传输守护程序打开了三个.torrent文件。无法确定哪个.torrent输入文件导致恶意软件下载。即使使用外部专家知识来识别恶意torrent，管理员仍然无法追踪到电子邮件。

图9（b）示出了由OmegaLog产生的UPG。由于OmegaLog成功地对Postfix和传输进程进行了分区，因此该图不会有依赖性爆炸问题，因此很容易从可疑进程跟踪到仿冒电子邮件。此外，OmegaLog图还提供了应用程序语义的附加文档，例如发件人的电子邮件地址，这可能有助于管理员将此攻击与其他入侵关联起来。现有溯源追踪无法提供此类证据。