欢迎访问Sunbet官网(www.sunbet.us),Allbet欧博官网(www.ALLbetgame.us)!

首页Sunbet_新闻事件正文

Linux内存取证:分析用户空间堆

b9e08c31ae1faa592019-02-01131

效果评价

本节形貌了HeapAnalysis类及其插件的评价。

效果考证

效果考证是对上述所讲的要领和手艺牢靠性的主要考证历程,一切测试均可以或许在以下状况中举行,且考证历程支撑分歧的Glibc版本:

1.Arch Linux 32位,×86,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

2.Arch Linux 64位,×64,内核版本4.4.5-ARCH,Glibc版本:2.20,2.21,2.22,2.23和2.24;

HeapAnalysis类完成了多个函数,这些函数会将以后检测的数据与我们在处置惩罚内存时对每一个块的希冀举行对照:

1.测试准确的标记,比方,线程arena中的块的NON_MAIN_ARENA;

2.块的地点是不是一致;

3.巨细检测(比方是不是一致);

4.分派状况测试:是不是多是任何bin或fastbin分派的一局部? 

5.关于MMAPPED块,还要举行一些分外的测试(有关更多细致信息,请拜见MMAPPED地区);

关于MMAPPED块,另有另一个触及malloc_par构造的考证步调。 glibc一方面运用此构造的构建来掌握某些全局设置,另一方面用于盘算MMAPPED块的总巨细和数目。这是经由历程该构造的独一实例(名为mp_)完成的,它位于映照的Glibc库中。若是供应了mp_的偏移量,则HeapAnalysis类将运用该构造来考证一切已辨认的MMAPPED块的数目和巨细。若是存在任何差别,它会实验辨认隐蔽的MMAPPED块,若是辨认不出来,则会发出正告。别的,malloc_par构造会将一切块和堆相干构造的巨细离别与响应的vm_area构造的巨细和一切arena的巨细举行对照。

完整性考证

虽然这项事情如今还没法完成悉数的Glibc堆完成,但这其实不阻碍最先实验用种种步调来辨认与内存取证相干的一切相干信息和设计。我们试着开发了一套测试顺序,该顺序涵盖了我们所晓得的一切特殊状况,以供应最完整的检测,终究,我们将运用这些测试用例自动考证我们完成的输出的完整性。为简明起见,此文我们不会对这套测试顺序举行细致解说,不外你可以或许在完整手艺申报中看到全部细节。

实在运用案例剖析

本章节将演示我们的插件在实在天下示例中的运用,演示历程当中,请注重两个方面,一方面注重插件是不是是经由历程形貌剖析历程自身来完成,另一方面注重是运用的插件照样在全部堆中举行原始搜刮的特点来完成的。鄙人面的小节中实行的剖析是运用“黑盒测试要领”完成的,这意味着,若是没有别的指定,那末没有必要预先网络来自源代码的与历程相干的细节,比如构造界说。

zsh示例

之前形貌的Rekall和Volatility的bash插件在全部堆空间中先会搜刮以标签为前缀的时候戳字符串,然后再见搜刮指向时候戳的汗青构造,以便辨认发出的敕令字符串。插件的输出是敕令条目列表,每一个敕令条目都是由发出的敕令和响应的时候戳构成。我们的目标是为zsh辨认雷同的信息。本节中的响应剖析已在效果考证局部中列出的雷同状况中完成。

当运用history敕令检测汗青记录时,要剖析的zsh历程在其汗青记录中包罗142个已实行的敕令:第一个是ps aux,末了一个是#[email protected] &*()。剖析历程的第一局部是以“黑盒测试要领”完成的,这意味着没有关于zsh怎样存储敕令或时候信息的内部信息是预先以任何体式格局网络的。这类要领的独一信息是关于bash敕令剖析的现有信息,第一次检测实验是查找以标签为前缀的时候戳字符串。然则,Zsh好像没有以与bash雷同的体式格局存储时候戳。因而下一步是运用heapsearch插件在块中的某处搜刮已宣布的敕令。列表1显现了运用heapsearch搜刮字符串#[email protected]%&*()的效果,个中显现了地点0x09BCF830地方包罗的感兴趣的敕令块。

1548748333301246.jpg Linux内存取证:分析用户空间堆  第1张

列表1

运用heapsearch搜刮包罗已宣布的zsh敕令的块,虽然此敕令偶然可以或许在多个块中举行辨认,但每一个敕令好像最少会在分派的块中辨认一次,该块仅包罗敕令和末端生存的一些跟随字节。列表2显现了包罗已宣布的zsh敕令块的hexdump。

1548748341905978.jpg Linux内存取证:分析用户空间堆  第2张

列表2

包罗已宣布的zsh敕令的块的Hexdump,由于这些块没有供应任何元信息(比方,在什么时候发出敕令),以是下一步是再次运用heapsearch插件找到指向这些块的指针,但这次供应了包罗发出敕令的块的地点。你可以或许在零丁分派的块中找到每一个测试敕令的一个指针,其巨细为56字节(针对×86状况)。

在检测多个块(运用heapdump插件的转储内容)以后,可以或许取得以下信息:

1.字节5-8包罗指向已发出敕令的指针

2.字节25-32是2个时候戳,存储为4字节整数,个中前四个字节是发出敕令的最先时候,后四个字节是敕令完毕的时候。

3.字节41-44包罗敕令计数器;

当运用heaprefs插件检测这些块以猎取援用时(拜见列表3,输出已被删除和修正),它显现字节1-4,5-8(敕令指针),13-16,17 -20和33-36指向其他块。这些块的肇端地点列在“解释(Comment)”列中,而包罗指针的字节在“数据(Data)”列顶用方括号举行了标记。

1548748348691753.jpg Linux内存取证:分析用户空间堆  第3张

列表3,运用heapref剖析援用的块

经由历程将这些信息与zsh的源代码相结合,你就会在相干的汗青条目构造histent中发明两个指针:fields down(向上的字段)(字节17-20)和fields up (向下的字段)(字节13-16)。由于这些字段会用来援用上一个或下一个histent条目,因而许可牢靠地遍历histent实例。由于内容条目标链接列表是轮回的,以是按着一个偏向遍历,就足以取得一切histent条目,其他指针关于以后的检测其实不主要。

如今,我们的末了一项义务是构建一个插件,以随意马虎自动提取这些敕令信息。为了可以或许遍历该histent列表,第一步是牢靠地辨认一个histent条目。由于敕令可以或许包罗在种种巨细分歧的块中,而且不供应任何可搜刮的情势,以是这类要领是查找包罗histent构造的块。关于×86而言,包罗块的巨细为56字节,关于×64架构,包罗块的巨细为96字节。由于还存在具有雷同巨细的非相干块,以是须要辨别它们。由于每一个histent条目都应当有一个指向包罗敕令的块的指针和指向下一个和上一个histent条目标指针,因而测试会包孕检测这些指针是不是援用已知的块。若是测试效果为正,末了一个检测则是遍历向上和向下指向下一个和上一个histent构造的指针,并测试它们的向下或向上构建是不是指向以后块。若是是这类状况,则将以后块视为一个histent 构造,并运用向下构建遍历敕令汗青记录。

列表4显现了zsh插件的示例输出 (输出已删除)。

-------------------------------------

申博网络安全巴士站

申博-网络安全巴士站是一个专注于网络安全、系统安全、互联网安全、信息安全,全新视界的互联网安全新媒体。

-------------------------------------

1548748354964922.jpg Linux内存取证:分析用户空间堆  第4张

列表4,zsh插件的示例输出

虽然由于时候戳字符串,可以或许运用原始搜刮重修bash汗青记录,但这类要领对zsh不起作用,由于时候戳不是以带有附加标签的字符串情势生存的,而是作为一个4字节整数生存的。别的,由于在剖析历程中没法辨认其他可搜刮的情势,因而原始搜刮极能够不实用于上述剖析历程,此时运用堆剖析插件的上风就显现出来了。

KeePassX示例

检测的第二个工具是暗码管理器KeePassX(版本0.4.3),我们已在以下状况中举行了测试:

1.Ubuntu 15.10 32位,×86,内核版本4.2.0–16-generic,Glibc2.21版本;

2.Ubuntu 15.10 64位,×64,内核版本4.2.0-16-generic,Glibc2.21版本;

以下剖析的设置由KeePassX数据库构成,该数据库包罗多个暗码条目,这些暗码条目已被分为两个文件夹。每一个暗码条目都有题目、用户名、URL和解释的值。翻开数据库举行剖析时,只翻开第一个文件夹,同时连结第二个文件夹完整稳定。

我们的第一次实验是在历程空间的某处找到未加密的主暗码(master password )和条目暗码,但找不到它们。然则,在5个带有分歧暗码管理器条目标测试中,我们已在3个已分派的块中胜利观察到以后翻开的暗码条目标未隐蔽暗码。只需暗码条目显现未隐蔽的暗码,这三个块就会一向存在。若是暗码再次隐蔽,三个块中的两个将被开释,生存个中一个举行分派。只有当输入窗口封闭时,包罗暗码的一切块才被开释。依据开释的块的巨细,暗码将在几毫秒(几分钟,以至几个小时也有能够)内被重写。虽然开释的块(包罗长度在1到40之间的暗码)通常在几秒钟或几分钟内重新分派,但在某些状况下,包罗一样巨细暗码的开释块会被合并到更大的开释块中。由于这些更大的块由于太大(比方在几百字节的范围内)不常常分派,暗码能够在该块中能够连结几个小时,但也更难被找到(由于它被其他数据围困)。别的,在块数据局部的前18个字节中从未观察到现实暗码,这意味着纵然在开释的块被合并到大型bin中,暗码也不会经由历程×86架构上的任何bin指针被掩盖。

在寻觅到暗码字段以后,下一步是寻觅更多感兴趣的字段,这个剖析历程当中挑选的字段是题目、用户名、URL和解释。 KeePassX在数据库被翻开后,会立行将完整的字段内容存储在已分派的块中。这不只实用于题目、URL和解释等字段,还实用于用户名字段,由于在KeePassX的示例中,该字段仅在概述中以星号显现,因而不应在堆内举行再加密。综上所述,若是暗码数据库被翻开而未被锁定,则可以或许从堆中提取一切文件夹中一切暗码管理器条目标概述(暗码字段除外)中的一切字段。为了剖析和对照来自分歧块(包罗字段字符串)的数据,我们已运用heapdump插件将它们转储到零丁的文件中。列表5显现了一个转储数据块的十六进制转储输出,该数据块包罗一个用户名(在本例中是yyyyyyyy_yyy_user5_aaaaaaaab):

1548748363323702.jpg Linux内存取证:分析用户空间堆  第5张

列表5,包罗KeePassX用户名字段的块数据局部的十六进制转储

在对照包罗来自雷同范例的字符串(比方用户名)和来自其他范例的字符串的分歧块以后,可以或许导出以下属性(关于未隐蔽的暗码也是云云):

1.字符串老是由16位的endian编码;

2.字符串并非从块的数据局部的开首最先的,而是在18字节以后,这很多是由于字符串是构造或工具的一局部;

3.字节5-8和9-12离别与字符串的巨细相干,而字节9-12透露表现准确的巨细(巨细是由编码的字节序列透露表现的字符数,而不是字节数),这两者都多是四字节无标记整数的实例。字节4-8中的值恰比如字节9-12中的值大1倍(请拜见列表5:0x19与0x18);

4.字节13-16指向字符串的开首;

5.该字符串后会紧跟4个空字节;

6.依据字符串的巨细,末了有一些分外的字节(某种添补字节),在大多数状况下从0到6个字节不等。然则,很少有这类状况,即这个分外的字节会到达14个字节(6加上直到下一个更大的块巨细的字节数);

字节1-4没有转变,而字节13-18和字符串完毕后的字节不只转变很大,它们也没有显现出任何与某个范例或暗码管理器条目标牢靠一致性。

因而,下一步我们就是运用heapsearch插件搜刮任何指向字段字符串的指针。虽然搜刮字符串的肇端地点没有显现任何援用(包罗在统一块中的援用除外),但搜刮这个块的数据局部的开首处会显现出另一个块中最少有一个指针。运用heaprefs插件剖析这个块时,它会显现指向其他块的12个指针,个中四个指针指向包罗题目、用户名、URL和解释字符串的块。在我们剖析了大批的暗码条目以后,就可以或许公道假定出每一个暗码条目,个中存在着巨细为96字节(在×86状况中)的块,这个块最少援用了这四个字段。这意味着,经由历程搜刮巨细雷同的块并检测给定偏移量的指针,就可以或许网络到雷同暗码条目标题目、用户名、URL和解释字符串,这个信息被用来建立一个观点考证插件,具体要领就是运用HeapAnalysis类,它会自动为一切暗码条目提取这四个字段。列表6显现了该插件的示例输出(输出已被删除)。

1548748370997897.jpg Linux内存取证:分析用户空间堆  第6张

列表6,KeePassX插件的示例输出

此时,你应当注重,若是没有来自有关块高低文的肇端地点的信息,查找字段字符串的援用将会越发难题,而在最坏的状况下,种种字符串联系关系到一个暗码条目标能够性也会下降。

总结

本文重点引见了怎样在Linux历程的高低文中剖析堆,其研讨目标是支撑研讨者剖析用户空间历程堆中包罗的数据。起首,要对Glibc的堆完成有了深切的相识,这在Glibc剖析局部中有细致的引见。该剖析侧重于从内存取证角度剖析堆相干数据的存储体式格局和存储地位。其次,这些学问已被用于构建内存取证框架Rekall插件,该框架用于剖析Linux用户空间历程的堆并供应对已辨认块的接见。细节在插件完成局部中有细致申明,个中迥殊形貌了一种辨认隐蔽MMAPPED块的算法。由于发生牢靠的效果是盘算机取证的症结请求,因而局部评价涵盖了可以或许考证网络到的效果的信息。为了申明研讨的实用性,在实在的运用顺序示例中中,我们运用了zsh和KeePassX的例子形貌了用户空间运用顺序的黑盒剖析历程。

本文研讨效果的一些局限性

因为通信空间在某些情况下是用户空间进程分析过程的关键所在,目前在我们的讨论中还没有触及这一点。当本研讨会中引入的插件用于创建包含堆相关数据的通信页面时,它们无法可靠地解析堆并提取所有块。

本研究的目的之一是存储在内存的数据提供一个类似的观点,来自上述讨论的影响,尽管我们必须清除桩过程中一切的详细信息(具体信息状态及其侵入),但现在仍然不能提取样本数据信息,基本原因是桩不存储任何数据样本信息。考虑到数据范式的知识和数据本身的大小,仍然有一种方法可以将特定块连接到特定范式。通过搜索特定大小的特定数据块,取证人员可以访问特定网络范式的数据。然而,这样的需求需要对这些块进行进一步的测试(如ZSH中的本地显示),因为包含不同数据的相同块可以有更多大小相同的块。

如上所述,分析特定堆取决于特定的操作系统。在分析一堆差异时,已经成功测试的要点和插件是非常不切实际的。到目前为止,我们研究的HeapAnalysis类和插件只支持上述体系结构和Linux剖析的Glibc版本。但是,在详细的技术文档中,我们提供的信息可以用于添加对其他体系结构或操作系统的支持。

虽然可以在不提供调试信息的情况下分析用户空间历史记录堆,但这不是一个可靠的观点。例如,当转换任何一致的结构(malloc_chunk、malloc_state或heap_info)时,插件将无法解析堆,如果没有指向全局变量mp_的指针,效果仍然是不完整的。如果没有mp_,就不能确定是否已经创建了所有mmapping块。否则,因为在本例中我们没有开始搜索隐藏的mmapping块,所以输出中可能至少缺少一个mmapping块。

除了隐藏的mmapping块之外,HeapAnalysis类还可能丢失块。如果分析过程不正确地删除vm_area_struct(其中包含所有arena),测试结果似乎是准确的,但是arena的块丢失了。出现这种不确定性的场景如下:在分析过程中,没有提供关于main_arena状态的调试信息,并且main_arena抓取过程找不到它,这意味着在分析过程中找不到线程竞技场。因为在此场景中没有指向任何竞技场的有用指针,所以可能存在未检测到的竞技场,这意味着没有注意到某个竞技场。虽然这在理论上是可能的,但在我们的评估中并未检测到arena的丢失。

将来的研讨偏向

由于最主要的限定是缺乏对交流空间的支撑,为了周全剖析历程的堆,必需确保对包罗堆相干数据的一切页面的接见。因而,将交流空间集成到内存取证历程中,就是进一步剖析用户空间历程的症结一步。

为了增添HeapAnalysis类的支撑,我们设计更多体系架构上测试插件,并在须要时举行恰当调解。别的,对诸如jemalloc之类的进一步堆完成的剖析许可剖析来自诸如Firefox之类的运用顺序的历程的堆分派。别的,对诸如jemalloc等其他堆完成的剖析,还许可来自Firefox等运用顺序的历程的堆分派。

总而言之,本文中引见的插件简化了剖析历程,并运用情势婚配要领辨认内存中没法随意马虎找到的信息。这些插件和内存中有关堆工具的细致信息,也可用于支撑内存取证的进一步研讨。别的,本文还演示了用户空间历程的剖析,同时申清楚明了在剖析历程中怎样猎取堆的细节信息。


网友评论