欢迎来到 黑吧安全网 聚焦网络安全前沿资讯,精华内容,交流技术心得!

Linux内存取证:解析用户空间进程堆(上)

来源:本站整理 作者:佚名 时间:2019-01-28 TAG: 我要投稿

前言
在取证分析中,对内存的分析通常是还原事件的重要步骤。以前对内存工作的分析主要集中于那些驻留在内核空间中的信息,如进程列表、网络连接等,特别是在Microsoft Windows操作系统上,但是这项工作主要关注的是Linux用户空间进程,因为它们可能还包含有价值的调查信息。由于许多进程数据位于堆中,所以这项工作首先集中在对Glibc堆实现的分析,以及如何将堆相关信息存储在使用此实现的Linux进程的虚拟内存中。到目前为止,从内存取证的角度来看,堆通常被认为是一个大的内聚内存区域,这使得在内部识别相关信息变得相当困难。我们为基于分析结果的内存分析框架Rekall引入了Python类,并允许访问堆中包含的所有块及其元信息。此外,基于这个类,我们已经开发了6个插件,支持研究人员分析用户空间进程,其中有4个插件提供了常用的分析功能,比如在块中查找信息或引用,并将块转储到单独的文件中以进行进一步的调查。目前这些插件已被用于对用户空间进程中的堆内数据结构进行逆向工程,你可以点此处,查看这些插件如何简化整个分析进程。其余两个插件则是这些用户空间进程分析的结果,而且还负责提取zsh shell的命令历史记录和密码管理器KeePassX的密码输入信息。
由于内存表示运行中的系统的当前状态,它包含有关浏览器历史记录、输入命令、运行中的网络连接、加载的驱动程序以及活动进程的信息,因此我们才可以对以前的活动进行详细的分析。虽然这些信息大部分位于内核空间,可以使用Rekall和Volatility等各种现有解决框架进行取证,但也有很多信息位于用户空间,例如,用户空间进程的堆通常是各种数据的丰富来源,而根据具体应用程序的不同,它可能包含凭证、IP地址、DNS名称或命令历史。但是,在Linux环境中,这些信息还不是容易提取的。
为了有效和可靠的识别和提取这些信息,研究人员需要查看与该进程相同或至少类似的堆的视图,以此来了解数据所在的位置,比如什么样的数据类型会存储在什么位置、哪些数据占用多少内存量。否则,取证人员对数据结构不理解,只能摸着石头过河,因为所有信息都位于堆内,只能将堆作为一个大内存区域来处理,这样效率就太低了。
为什么解析用户空间进程堆
在Linux进程的上下文中,以前对用户空间分析的重点仅限于在整个进程内存或整个堆或堆栈中搜索特定模式。例如,为了重建Linux bash shell的命令历史记录,Rekall的bash 7插件在堆中搜索一个主题标签,后跟一个字符串格式的Unix时间戳(例如#1471572423)。但是,如果感兴趣的信息没有以易于检测的方式进行标记,则简单的模式匹配将失败。
当研究者在内存中标识某个字符串并试图标识对该字符串的引用时,即使存在间接引用,这种模式匹配搜索也可能失败。如果字符串是结构或对象的一部分,并且不在开头,而感兴趣的指针直接引用结构而不是字符串,则可能出现这种情况。为了能够找到这些引用,你就必须知道该结构的开头,这就需要了解其字段的大小以及字符串在结构中的位置。但是,这些细节通常在"黑箱分析"中不可用。
在本文中,我们实现解析用户空间进程堆的步骤分为5步:
1.通过分析Glibc堆的实现,总结一些可以让调查人员能够执行手动堆分析的信息,其中重要的信息是关于堆结构的排列方式以及它们通常位于内存中的位置;
2.证明一些块可能隐藏在内存中的某个位置,为此我们提出了一种检索它们的算法;
3.这些算法已被用于开发一个名为HeapAnalysis的Python类,它可用于实现特定的堆分析插件。基于这个类,我们开发了支持取证人员分析堆及其块的插件;
4.我们会解释如何通过应用这些插件收集相关信息来分析用户空间进程的数据,类似于我们对Windows用户空间进程的分析;
5.对结果的进一步分析是两个插件,第一个插件从zsh shell(版本5.2)进程的堆中收集所有已执行的命令,第二个插件从堆中提取所有可检索密码条目的标题、用户名、URL和注释字段的密码管理器KeePassX(版本0.4.3)。
HeapAnalysis类和所有提到的插件都支持×86和×64架构。
除了本文之外,我们还发布了一份技术报告,其中包含更多技术细节和代码列表。
本文的文章目录结构:
1.Glibc分析章节详细介绍了使用Glibc堆实现的用户空间进程的堆;
2.在Plugin实现章节中,我们对开发的堆分析插件进行了概述;
3.插件的评估章节;
4.实践应用章节提供了详细的应用分析;
5.总结章节;
对用户空间进程堆进行解析的研究历史
到目前为止,对用户空间应用的分析还没有得到足够的重视,这正是我们此次研究的动机,另外关于该主题的文献目前还非常少,Linux内存取证arena的现有文献主要涉及内核主题,如Urrea, 2006, Case et al., 2010 和 Ligh et al. (2014). 。
少数例外是Leppert(2012) 和Macht(2013)的研究,他们都专注于基于Linux的移动设备的Android操作系统,并分析应用程序和它们的堆数据。但是,他们的分析主要集中在堆中包含的序列化Java对象上,而不是堆对象的管理方式上。除此之外,还有对插件cmdscan 和bash 的研究,它们分别从Windows的cmd和Linux的bash shell中提取命令历史记录。然而,这些插件的使用都是基于以下的事实:在这些情况下,只需将堆视为一个大内存区域就可以识别信息了,另一项相关工作是对记事本堆的分析。据我们所知,这是唯一使用任何堆细节的示例,而且与大多数先前的工作一样,它也与Windows相关。
如果不考虑取证,仅对堆进行的基础研究,特别是对Linux进程堆及其管理方式的研究,仅有Ferguson(2007) 对Glibc的堆实现进行了研究。然而,以前的研究更多的关注于如何利用堆,因此目前还没有足够的信息来让我们在内存取证场景中从堆中收集所有相关信息。
Cohen(2015)的研究是第一个通过一组Windows操作系统分析工具来解决这一问题的项目。虽然Windows的堆实现与来自Glibc的堆实现之间存在一些相似之处,例如,在两种情况下,分配的块前面都有一个至少包含块大小的结构,但它们在细节上有所不同。
Glibc分析
在本章节中,我们从内存取证的角度介绍了我们对Glibc堆实现的最重要分析结果,更详细的信息可以从我们的技术报告中获得。
不同的堆实现
我们的堆实现对象是Glibc 2.23版,它基于Wolfram Gloger的ptmalloc2 ,不过除此之外还有其他各种堆实现,其中大多数都是在某个操作系统

[1] [2]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。
  • 最新更新
    • 相关阅读
      • 本类热门
        • 最近下载