前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >攻击溯源-基于因果关系的攻击溯源图构建技术

攻击溯源-基于因果关系的攻击溯源图构建技术

作者头像
绿盟科技研究通讯
发布2020-09-08 15:02:44
2.7K0
发布2020-09-08 15:02:44
举报

一、背景

所谓“知已知彼,百战不殆”,在网络空间这个大战场中,攻防博弈双方实质上是信息获取能力的对抗,只有获取更多、更全的信息才能制定有效的攻防策略,在网络空间战场博弈中获得优势。作为防御者需要“知彼”,就是回答在网络攻防对抗中谁攻击了我,攻击点在哪以及攻击路径,这便是攻击溯源。通过攻击溯源技术可以确定攻击源或攻击的中间介质,以及其相应的攻击路径,以此制定更有针对性的防护与反制策略,实现主动防御。可见攻击溯源是网络空间防御体系从被动防御到主动防御转换的重要步骤。

但是无论是网络侧告警还是终端侧日志,我们看到的是孤立的数据,而攻击者的攻击行为步骤是具有因果关联的。攻击溯源就是基于这种因果关联把与攻击相关的信息关联到一起构建溯源图(provenance graph),并从中找到攻击者及攻击路径。因果关联分析需要依靠知识库,根据知识库构建若干规则,每一条规则定义了攻击行为发生的前提条件,以及它执行后导致的结果或是产生的影响。但是当前攻击溯源的研究工作还远没有走到这一步,主流的因果关系是挖掘告警或日志之间的依赖关系。

溯源图是攻击溯源的基础,所有的技术均是建立在对溯源图的分析处理上的。下面将从三个方面介绍攻击溯源图的构建:1 终端侧的攻击溯源图构建方法;2 系统日志与应用程序日志关联溯源图构建方法;3 网络侧与终端侧关联溯源图构建方法。

二、主机侧溯源图构建

BackTracker[1]是经典的溯源图构建方法,它是主机侧攻击溯源的奠基工作,后续的相关工作均是参考BackTracker。BackTracker溯源图的构建主要是挖掘进程、文件与文件名之间的因果依赖关系。BackTracker分别对主机侧的进程之间的依赖关系、进程与文件之间的依赖以及进程与文件名之间的依赖关系进行了定义。

进程之间的直接依赖关系是指一个进程通过创建、内存共享和通信对其它进程的直接影响关系。进程之间的间接依赖关系是指通过操作相同的文件或对象关联到一起的进程。进程与文件之间的因果依赖关系是指进程与文件之间存在的直接操作关系,如读、写等。进程与文件名是通过包含文件名的系统调用来构建文件名到进程的依赖关系。下面借用论文中的一个实例来说明主机侧溯源图的构建方法。图1.a表示系统相关日志,图1.b是根据系统日志构建的溯源图。

(a)系统日志

(b) 溯源图

图1 BackTracker溯源图构建

攻击溯源图的构建是挖掘不同实体之间的因果依赖关系,通过事先定义的规则来关联不同进程、文件和文件名,本质是一种依赖关系缺少因果语义。MCI[2]提出一种基于因果推理模型的攻击溯源方法,它利用了LDX[3]因果推理模型挖掘系统调用之间精确的因果关系。

图2 MCI 因果推理框架

MCI方法的核心是基于系统审计日志的因果推理技术,其对用户来说是友好的,不需要对系统内核进行任何修改,也不需要在系统执行期间执行任何操作。只需要打开操作系统附带的审计工具(如,Linux审计、Windows事件跟踪和DTrace)。如果用户检测到安全事件,只需要向安全运营人员提供系统调用日志和程序二进制文件等。

离线的调查取证通常由安全运营专家来完成,MCI的任务是构建因果模型并基于此来解析相关的系统日志,并挖掘出精确的系统调用级日志的因果关系。图2显示了MCI因果推理的框架。MCI包括两个阶段:因果关系模型的构建与模型解析。MCI利用LDX[3]因果模型来确定系统调用相关日志之间的因果关系。LDX是一个基于双向执行因果推断模型。它通过改变系统调用的输入,观察输出的状态变化来推断系统调用之间的因果关系。

图3 LDX因果关系推理

三、系统日志与应用程序日志关联溯源图

前面介绍的攻击溯源相关工作主要是从系统层面挖掘系统行为的因果依赖关系,没有考虑应用层语义。对于攻击调查,应用程序日志能提供大量的攻击相关信息。文献[4,5,6] 认为将系统上所有与取证相关的事件统一到一个整体日志中可以显著提高攻击调查能力,基于此提出了一种端到端的溯源追踪框架-OmegaLog,该框架集成应用程序事件日志与系统日志构建了一个全局溯源图(UPG)。Omegalog通过应用程序事件序列识别事件处理的环路来解决依赖关系爆炸问题。同时,集成了应用程序的日志解决了数据孤立问题。

这种跨应用的关联溯源显然会有更效,但是这种溯源框架的依然面临一些挑战。首先,应用程度日志架构的生态系统是异构的。其次,事件日志在应用程序中的多个线程之间进行多路复用,很难区分并发工作单元;最后,应用程序中的每个工作单元都无法独立生成事件日志,这些事件的发生和顺序是根据动态控制流而变化的,因此需要深入了解应用程序的日志记录行为,以确定执行单元分区的有效边界。

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

图4给出OmegaLog的系统框架图,该系统要求同时启用系统级日志记录和应用程序事件日志记录。

图4 OmegaLog 结构

四、网络侧与终端侧关联溯源图

前面这些攻击溯源的方法均是在单一主机上进行,一个完整的攻击过程通常是跨多个主机。只有关联网络侧日志与终端侧日志才有可能溯源整个攻击过程。网络侧与终端侧关联溯源是攻击溯源的难点,相关的研究工作较少。文献[7]是BackTracker工作的扩展,通过相关日志记录来追踪网络数据包的发送与接收。比如主机A的进程1向主机B的进程2发送了一个数据包,那么进程1与进程2就具有了因果依赖关系。当前已有很多基于数据包标记的工作,为了减少工作量,采用的是通过源地址、目标地址和序列号来标记数据,相对来说实现简单,但是这种粗粒度的因果关联会造成太多的错误关联,基本上无法进行有效的攻击溯源,反而会有大量的计算开销。因此,该方法在工程实践中没有并广泛使用。

文献[8]提出了一个新的开源平台zeek-osquery,该平台主要是针对网络侧与终端侧数据的细粒度的因果挖掘来实现实时的入侵检测。其关键技术是将操作系统级的日志与网络侧日志实时关联。Zeek-osquery可以灵活地适应不同的检测场景,因为osquery主机是从Zeek脚本直接管理的,所有的数据处理都可以在Zeek中实现。例如,检测从互联网下载的已执行文件,通过SSH跳转检测攻击者的横向移动[18],或向Zeek提供从主机获得的内核TLS密钥,用于解密和检查网络流量。

为了提高入侵检测的准确度,着重介绍了与网络侧数据相关联的终端数据。也就是通过将主机上下文合信息集成到网络监控中来改进网络信息可见性。

zeek-osquery使用流这一术语来表示两台主机之间的通信,该流表示为一个包含IP地址,主机端口和协议相关信息的5元组。使用socket来抽象流。Socket使用唯一的ID(文件描述符和pid结合),别外还包含相应5元组的属性。进程与socket的信息可以通过监控内核的系统调用(syscalls)获取的。别一种进程与socket信息获取的方法是通过当前内核状态。然而通过内核审计和内核状态获取的数据具有不同的属性。内核审计可以实现新进程和socket的异常推送,而内核状态机制需要频繁的探测内核并与前一时间的进行比较以判断其状态的改变。内核状态机制这种探测需要额外的开销,但在数据可靠性方面要优于内核审计机制。因为审计机制监控系统调用,只能记录这些调用的实际参数。例如,在连接的情况下,只有目标IP地址和端口是出现在调用中,即使在合并多个与套接字相关的系统调用时本机IP地址和端口仍然无法得知。然而,在数据关联过程中,如果仅仅依赖状态机制很容易出错,因为如果一个短暂的进程或是socket的生命周期是在两个状态探测之间,那么这进程或socket就无法被捕捉到。下面将介绍审计机制与状态机制组合方法,以实现网络侧与终端侧数据关联的完整性与可靠性。

图5 网络侧与终端侧数据关联

网络流的发起者与接收者可以通过识别socket得到,为简单起见,假设socket的足够,因为它是主机侧进程与文件关联中缺失的数据。网络流的socek表示需要匹配相应的5元组。对于发起方,这个socket表示输出流,对于接收方来说该socket是输入流。图5展示了发起者及其传出socket,接收者及其传入socket模式,以及网络流中完整的5元组。

1 通过网络流中的IP地址来识别发起方与接收方,因此需要维护网络中的IP地址与主机列表;

2 在发起方与接收方识别那些目标地址等于远程或是本地地址的socket信息;

3 还需要流的源等于本地或是远程主机socket信息。

如果满足步骤3的话,那么主机与网络的关联是明确的。否则关联有可能是模糊的。如果两台主机通过connect syscall连接到同一个目标主机的同一端口,那么根据步骤1,关联依然是明确的。但是,如果从发起方到同一目标有多个流到同一个端口,那么关联就是不明确的。对于这种相关性不明确的情况,需要列出所有可能的相关关联。

然面这种级别的跨主机攻击溯源依然会因为socket的不确定性而存在大量的错误关联。

文献[9]综合了多种技术提出了一种有效的跨主机追踪溯源方法-RTAG,可以从一定程度上解决当前网络侧与终端侧数据无法关联溯源的问题。RTAG是一种可以实现跨主机攻击调查的有效数据流标记与追踪机制。RTAG主机依赖于三个创新技术:

1 记录与重放,它可以将不同数据流标签之间的依赖关系从分析中解耦出来,从而在不同主机的独立和并行DIFT实例之间实现延迟同步;

2 根据系统调用级溯源信息,根据内存消耗永无止息并分配最优标签映射;

3 将标签信息嵌入到网络数据包中实现了跨主机的数据溯源追踪溯源,同时并没有明显的占用网络开销。

为了克服当前跨主机攻击溯源的挑战,RTAG通过标签覆盖和标签交换技术将标签依赖性(即主机间的信息流)与分析分离开来,并使DIFT独立于通信所施加的任何顺序。

(a)溯源图

(b)数据流覆盖

图 6 RTAG标签系统

为了追踪文件之间的数据流和不同主机之间的网络流,在现有的溯源图上构建标签模型作为一个覆盖图。在覆盖图中,RTAG通过为关注的文件赋予全局唯一标签,以实现字节粒度的追踪溯源。通过对标签的追踪可以实现对文件起源的追踪,同时也可以追踪文件对下游的影响。基于此能力,RTAG可以实现跨主机的攻击调查取证。溯源图依然是攻击追踪溯源必需的,它需要追踪从进程到文件的数据流,从进程到进程的数据流,从文件到进程的数据流。其中边表示两个节点之间的事件(如,系统调用)。

在覆盖标签图中,文件中的每个字节都赋予一个标签key,这个标签key唯一标记了这个字节。每一个标签key都与其原始数据的向量相关联。通过递归的检索key值,可以获得从这个字节开始的所有上流源,同时也可以扩展到远程主机上。相反的通过递归检索每一个值的标签,分析人员能够在一个树形图找到所有的下游的数据流向。

五、总结

当前,攻击技术的发展日新月异,攻击者入侵手段已经从单步定点攻击转向高级、隐蔽并长期潜伏的趋势发展。而当前防守手段通常跟不上攻击手段更新。攻击溯源为实现主动防御提供了一个新的思路。

虽然从BackTracker工作到现在已经有16年了,但是攻击溯源技术依然是一个新兴的技术领域。溯源图的构建依赖于网络侧与终端侧数据之间因果关系,研究细粒度的因果关系挖掘进一步精确溯源图依然是急需研究的工作。完全利用图分析算法进行复杂攻击识别是有天花板的,外部知识的引入是一种有效的手段,但是当前外部知识只是简单的根据规则抽象出一些已有攻击的威胁子图,利用ATT&CK相关的攻击战术手法。并没有全面并联相关的知识上下文,绿盟近年来致力于研究安全知识图谱,知识图谱的强大关联与丰富的语义是下一步攻击溯源提高的技术关键。

参考文献

1 King S T , Chen P M . Backtracking Intrusions[J]. Operating Systems Review, 2003, 37(5):p.223-236.

2 Kwon Y , Wang F , Wang W , et al. MCI : Modeling-based Causality Inference in Audit Logging for Attack Investigation[C]// Network and Distributed System Security Symposium. 2018.

3 Kwon Y , Kim D , Sumner W N , et al. LDX: Causality Inference by Lightweight Dual Execution[J]. Acm Sigarch Computer Architecture News, 2016, 51(2):503-515.

4 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.

5 Pasquier T., Han X., Moyer T., Bates A., Eyers D., Hermant O., Bacon J. and Seltzer M. Runtime Analysis of Whole-System Provenance. Conference on Computer and Communications Security (CCS’18) (2018), ACM.

6 Pasquier T., Han X., Goldstein M., Moyer T., Eyers D., Seltzer M. and Bacon J. Practical Whole-System Provenance Capture. Symposium on Cloud Computing (SoCC’17) (2017), ACM.

5 Kwon Y , Wang F , Wang W , et al. MCI : Modeling-based Causality Inference in Audit Logging for Attack Investigation[C]// Network and Distributed System Security Symposium. 2018.

6 Kwon Y , Kim D , Sumner W N , et al. LDX: Causality Inference by Lightweight Dual Execution[J]. Acm Sigarch Computer Architecture News, 2016, 51(2):503-515.

7 King S T , Mao Z M , Lucchetti D G , et al. Enriching intrusion alerts through multi-host causality[C]// Network & Distributed System Security Symposium. DBLP, 2005.

8 Steffen Haas, Robin Sommer, Mathias Fischer,zeek-osquery: Host-Network Correlation for Advanced Monitoring and Intrusion Detection. IFIP SEC '20,2020

9 Yang Ji, Sangho Lee, Mattia Fazzini, Joey Allen, Evan Downing, Taesoo Kim, Alessandro Orso, and Wenke Lee. Enabling Refinable Cross-Host Attack Investigation with Efficient Data Flow Tagging and Tracking. In Proceedings of The 27thUSENIX Security Symposium. Baltimore, MD, August 2018

关于天枢实验室

天枢实验室聚焦安全数据、AI攻防等方面研究,以期在“数据智能”领域获得突破。

内容编辑:天枢实验室 薛见新 责任编辑: 王星凯

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-09-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 绿盟科技研究通讯 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 参考文献
相关产品与服务
主机安全
主机安全(Cloud Workload Protection,CWP)基于腾讯安全积累的海量威胁数据,利用机器学习为用户提供资产管理、木马文件查杀、黑客入侵防御、漏洞风险预警及安全基线等安全防护服务,帮助企业构建服务器安全防护体系。现支持用户非腾讯云服务器统一进行安全防护,轻松共享腾讯云端安全情报,让私有数据中心拥有云上同等级别的安全体验。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档