漏洞取证_使用Linux文件系统取证进行漏洞检测

漏洞取证

对Linux磁盘映像进行取证分析通常是事件响应的一部分，以确定是否发生了破坏。 与Microsoft Windows取证相比，Linux取证是一个与众不同的世界。 在本文中，我将分析来自可能受到威胁的Linux系统的磁盘映像，以确定事件的人员，事件，时间，地点，原因以及方式，并创建事件和文件系统时间轴。 最后，我将从磁盘映像中提取感兴趣的工件。

在本教程中，我们将以创造性的新方式使用一些新工具和一些旧工具来对磁盘映像进行取证分析。

场景

磁盘映像

为了对服务器进行取证分析，我要求PFE向我发送USB驱动器上pfe1的取证磁盘映像。 他们同意并说，“ USB已寄出”。 USB驱动器到货，我开始检查其内容。 为了进行取证分析，我使用运行SANS SIFT发行版的虚拟机（VM）。 SIFT工作站是一组免费的开源事件响应和取证工具，旨在在各种环境中执行详细的数字取证检查。 SIFT有各种各样的取证工具，如果没有我想要的工具，我可以轻松安装一个，因为它是基于Ubuntu的发行版。

经检查，我发现USB不包含磁盘映像，而是VMware ESX主机文件的副本，这些文件是PFE混合云中的VMDK文件。 这不是我所期望的。 我有几种选择：

1. 我可以联系PFE，更明确地表达我对他们的期望。 在这样的订婚初期，这可能不是最好的选择。
2. 我可以将VMDK文件加载到诸如VMPlayer之类的虚拟化工具中，并使用其本机Linux程序作为实时VM运行它以执行取证分析。 至少有三个原因不这样做。 首先，将VMDK文件作为实时系统运行时，文件和文件内容的时间戳将被更改。 其次，由于服务器被认为已被破坏，因此必须将VMDK文件系统的每个文件和程序都视为已被破坏。 第三，在受损系统上使用本机程序进行取证分析可能会带来无法预料的后果。
3. 要分析VMDK文件，我可以使用libvmdk-utils软件包，该软件包包含用于访问存储在VMDK文件中的数据的工具。
4. 但是，更好的方法是将VMDK文件格式转换为RAW格式。 这将使在磁盘映像中的文件上运行SIFT分发中的各种工具变得更加容易。

为了从VMDK转换为RAW格式，我使用qemu-img实用程序，该实用程序允许离线创建，转换和修改图像。 下图显示了将VMDK格式转换为RAW格式的命令。

^{图1：将VMDK文件转换为RAW格式}

接下来，我需要从磁盘映像中列出分区表，并使用mmls实用程序获取有关每个分区的起始位置（扇区）的信息 。 该实用程序显示卷系统中分区的布局，包括分区表和磁盘标签。 然后，我使用起始扇区，并使用fsstat实用程序查询与文件系统关联的详细信息，该实用程序显示与文件系统关联的详细信息。 下图显示了mmls运行的mmls和fsstat命令。

^{图2： mmls命令输出}

我从mmls输出中学到了一些有趣的东西：Linux主分区从扇区2048开始，大小约为8 GB。 DOS分区（可能是引导分区）的大小约为8 MB。 最后，大约有8 GB的交换分区。

^{图3： fsstat命令输出}

运行fsstat告诉我有关该分区的许多有用信息：文件系统的类型，上次将数据写入文件系统的时间，是否已干净地卸载文件系统以及文件系统的安装位置。

我准备挂载分区并开始分析。 为此，我需要读取指定原始图像上的分区表，并在检测到的分区段上创建设备映射。 我可以通过mmls和fsstat的信息手动完成此操作，也可以使用kpartx为我完成此操作。

^{图4：使用kpartx创建回送设备}

我使用选项创建只读映射（ -r ），添加分区映射（ -a ）并提供详细输出（ -v ）。 loop0p1是/dev/mapper下的设备文件名，我可以使用它访问分区。 要安装它，我运行：

$ mount -o ro -o loop=/dev/mapper/loop0p1 pf1.raw /mnt 

请注意，我将分区安装为只读（ -o ro ）以防止意外污染。

装入磁盘后，我通过创建时间线来开始法医分析和调查。 一些法医审查员不相信创建时间表。 取而代之的是，一旦它们具有已安装的分区，它们就会在文件系统中爬行，以寻找可能与调查有关的工件。 我称这些法医为“爬行者”。 尽管这是法医调查的一种方法，但它不可重复，容易出错，并且可能会丢失有价值的证据。

我认为创建时间线是至关重要的一步，因为它包含有关以人工可读格式（即MAC（已修改，访问，更改））时间证据修改，访问，更改和创建的文件的有用信息。 此活动有助于确定事件发生的具体时间和顺序。

关于Linux文件系统的注释

诸如ext2和ext3的Linux文件系统没有文件创建/出生时间的时间戳。 创建时间戳记已在ext4中引入。 Dan Farmer和Wietse Venema撰写的《 取证发现》 （第一版）概述了不同的时间戳。

• 上次修改时间：对于目录，这是最后一次添加，重命名或删除条目的时间。 对于其他文件类型，这是最后一次写入文件。
• 上次访问（读取）时间：对于目录，这是上次搜索时间。 对于其他文件类型，这是最后一次读取文件。
• 上次状态更改：状态更改的示例包括所有者更改，访问权限更改，硬链接计数更改或任何MAC时间的显式更改。
• 删除时间： ext2和ext3记录了dtime时间戳中文件删除的时间，但并非所有工具都支持它。
• 创建时间： ext4fs记录在crtime时间戳中创建文件的时间，但是并非所有工具都支持它。

不同的时间戳存储在inode中包含的元数据中。 索引节点类似于Windows世界中的MFT条目号。 在Linux系统上读取文件元数据的一种方法是，首先使用命令ls -i file获取索引节点号，然后对分区设备使用istat并指定istat节点号。 这将向您显示不同的元数据属性，包括时间戳，文件大小，所有者的组和用户ID，权限以及包含实际数据的块。

创建超级时间表

我的下一步是使用log2timeline / plaso创建超级时间线。 Plaso是对基于Perl的log2timeline工具的基于Python的重写，该工具最初由Kristinn Gudjonsson创建，并由其他人增强。 用log2timeline制作超级时间线很容易，但是很难解释。 Plaso引擎的最新版本可以解析ext4以及不同类型的工件，例如syslog消息，审计，utmp等。

要创建超级时间轴，我针对已安装的磁盘文件夹启动log2timeline并使用Linux解析器。 这个过程需要一些时间。 完成后，我将拥有一个使用plaso数据库格式的不同工件的时间表，然后可以使用psort.py将plaso数据库转换为任意数量的不同输出格式。 要查看psort.py支持的输出格式，请输入psort -o list 。 我使用psort.py创建了一个Excel格式的超级时间轴。 下图概述了执行此操作的步骤。

（注意：从图像中删除了多余的线条）

^{图5：以xslx格式创建超级时间轴}

我将超级时间轴导入电子表格程序，以使查看，排序和搜索更加容易。 虽然您可以在电子表格程序中查看超级时间轴，但在诸如MySQL或Elasticsearch之类的真实数据库中使用它会更容易。 我创建了第二条超级时间轴，并将其直接从psort.py分发到Elasticsearch实例。 Elasticsearch将超级时间轴编入索引后，我就可以使用Kibana可视化和分析数据了。

^{图6：创建超级时间轴并将其吸收到Elasticsearch中}

使用Elasticsearch / Kibana进行调查

正如法雷尔中士所说：“通过准备和纪律，我们是命运的主人。” 在分析过程中，耐心细致并避免成为爬行者是值得的。 有助于进行超级时间表分析的一件事是，要了解事件可能何时发生。 在这种情况下（双关语是故意的），客户说事件可能发生在3月。 我仍然考虑客户端在时间范围上不正确的可能性。 有了这些信息，我就开始减少超级时间轴的时间表并缩小范围。 我正在寻找与事件的预期日期具有“时间邻近性”的感兴趣的工件。 目标是根据不同的工件重新创建发生的事情。

为了缩小超级时间轴的范围，我使用我设置的Elasticsearch / Kibana实例。 使用Kibana，我可以设置任意数量的复杂仪表板来显示和关联感兴趣的法证事件，但是我想避免这种复杂性。 相反，我选择感兴趣的索引进行显示，并按日期创建活动的条形图：

^{图7：pfe1上的活性随时间变化}

下一步是在图表末尾展开大条形图：

^{图8：三月期间pfe1上的活性}

3月5日设有大型酒吧。 我扩展该栏以查看该特定日期的活动：

^{图9：3月5日pfe1上的活性}

从超级时间轴查看日志文件活动，我看到此活动来自软件安装/升级。 在这方面的活动很少。

^{图10：3月5日pfe1的日志清单}

我回到Kibana来查看系统上的最后一组活动，并在日志中找到它：

^{图11：关闭前pfe1上的最后一个活动}

系统上最后的活动之一是john用户从名为xingyiquan的目录中安装了一个程序。 兴义拳是一种类似于功夫和太极拳的中国武术风格。 用户john通过自己的用户帐户在公司服务器上安装武术程序似乎很奇怪。 我使用Kibana的搜索功能在日志文件中找到“兴义拳”的其他实例。 我在3月5日，3月9日和3月12日发现了围绕弦一圈的三个活动期。

^{图12：兴义泉对pfe1的活性}

接下来，我查看这些天的日志条目。 我从3月5日开始，寻找使用Firefox浏览器和Google搜索引擎进行互联网搜索的证据，以查找名为xingyiquan的rootkit。 Google搜索在packetstormsecurity.com上发现了这样的rootkit。 然后，浏览器转到packetstormsecurity.com，并从该站点下载了一个名为xingyiquan.tar.gz的文件到用户john的下载目录中。

^{图13：搜索和下载xingyiquan.tar.gz}

尽管用户john似乎先去google.com搜索rootkit，然后又去packetstormsecurity.com下载了rootkit，但这些日志条目并不表示用户在搜索和下载背后。 我需要进一步研究。

Firefox浏览器将其历史记录信息保存在用户主目录（即用户john）的.mozilla目录下SQLite数据库中，该文件名为places.sqlite 。 要查看数据库中的信息，我使用一个名为sqlitebrowser的程序。 这是一个GUI应用程序，允许用户深入到SQLite数据库并查看存储在其中的记录。 我启动了sqlitebrowser并从john用户.mozilla目录下的.mozilla目录中导入了places.sqlite 。 结果如下所示。

^{图14：john用户的搜索和下载历史}

最右边一列中的数字是左边活动的时间戳。 作为一致性测试，我将时间戳1425614413880000转换为人工时间，并获得2015年3月5日，8：00：13.880 PM。 这与来自Kibana的时间2015年3月5日20：00：00.000紧密匹配。 可以肯定地说，约翰用户搜索了一个名为xingyiquan的rootkit，并从packetstormsecurity.com网站xingyiquan.tar.gz一个名为xingyiquan.tar.gz的文件下载到了john用户的下载目录中。

使用MySQL进行调查

在这一点上，我决定将超级时间轴导入MySQL数据库，以获取比单独使用Elasticsearch / Kibana更大的灵活性来搜索和处理数据。

构建兴义拳rootkit

我将从plaso数据库创建的超级时间轴加载到MySQL数据库中。 通过与Elasticsearch / Kibana合作，我知道用户john从packetstormsecurity.com将rootkit xingyiquan.tar.gz下载到了下载目录。 这是从MySQL时间轴数据库进行下载活动的证据：

^{图15：下载xingyiquan.tar.gz rootkit}

在下载rootkit之后不久，就从tar.gz档案中提取了源代码。

^{图16：从tar.gz档案中提取rootkit源}

直到3月9日，rootkit都没有做任何事情，那时坏的演员使用More程序读取了rootkit的README文件，然后编译并安装了rootkit。

^{图17：构建xingyiquan rootkit}

命令历史

我将pfe1上所有具有bash命令历史记录的用户的历史记录加载到MySQL数据库的表中。 载入历史记录后，我可以使用以下查询轻松显示它们：

select * from histories order by recno; 

为了获取特定用户的历史记录，我使用类似以下的查询：

select historyCommand from histories where historyFilename like '%<username>%' order by recno; 

我从用户john的bash历史中找到了一些有趣的命令。 即，用户john创建了johnn帐户，删除了该帐户，再次创建了该帐户，将/bin/true复制到/bin/false ，将密码提供给whoopsie和lightdm帐户，将/bin/bash复制到/bin/false ，编辑了密码和组文件，将用户johnn的主目录从johnn移到.johnn （使其成为隐藏目录），在查找如何使用后使用sed更改了密码文件 sed ，最后安装了xingyiquan rootkit。

^{图18：john用户的活动}

接下来，我查看用户johnn的bash命令历史记录。 它没有显示异常活动。

^{图19：用户johnn的活动}

注意到用户john将/bin/bash复制到/bin/false ，我通过检查这些文件的大小并获取文件的MD5哈希值来测试是否正确。 如下所示，文件大小和MD5哈希值相同。 因此，文件是相同的。

^{图20：检查/bin/bash和/bin/false}

调查成功和失败的登录

为了回答“何时”问题的一部分，我将包含登录，注销，系统启动和关闭数据的日志文件加载到MySQL数据库的表中。 使用简单的查询，例如：

select * from logins order by start 

我发现以下活动：

^{图21：成功登录到pfe1}

从该图中，我看到用户john从IP地址192.168.56.1登录到pfe1。 五分钟后，用户johnn从同一IP地址登录到pfe1。 用户lightdm进行了两次登录，之后四分钟又是一分钟，然后johnn用户在不到一分钟的时间内登录。 然后pfe1重新启动。

查看不成功的登录，我发现此活动：

^{图22：登录pfe1失败}

再次，用户lightdm尝试从IP地址192.168.56.1登录到pfe1。 鉴于伪造的帐户登录到pfe1，我对PFE的建议之一是检查IP地址192.168.56.1的系统是否存在泄露的证据。

调查日志文件

对成功和失败登录的分析提供了有关事件发生时间的有价值的信息。 我将注意力转向调查pfe1上的日志文件，尤其是/var/log/auth*的身份验证和授权活动。 我将pfe1上的所有日志文件加载到MySQL数据库表中，并使用如下查询：

select logentry from logs where logfilename like '%auth%' order by recno; 

并将其保存到文件中。 我使用最喜欢的编辑器打开该文件，然后搜索192.168.56.1 。 以下是活动的一部分：

^{图23：在pfe1上的帐户活动}

本部分显示用户john从IP地址192.168.56.1登录并创建了johnn帐户，删除了johnn帐户，然后再次创建了该帐户。 然后，用户johnn从IP地址192.168.56.1登录到pfe1。 接下来，用户johnn尝试通过su命令成为用户whoopsie，但失败了。 然后，更改了用户whoopsie的密码。 用户johnn接下来尝试使用su命令成为用户lightdm，该命令也失败了。 这与图21和22中所示的活动相关。

我的调查结论

• john用户搜索，下载，编译并将名为xingyiquan的rootkit安装到服务器pfe1上。 xingyiquan rootkit隐藏了进程，文件，目录，进程和网络连接； 增加后门； 和更多。
• 用户john在pfe1上创建，删除和重新创建了另一个名为johnn的帐户。 用户john将用户johnn的主目录设为隐藏文件，以掩盖此用户帐户的存在。
• 用户john将文件/bin/true复制到/bin/false ，然后将/bin/bash复制到/bin/false以方便通常不用于交互式登录的系统帐户登录。
• john用户为系统帐户whoopsie和lightdm创建了密码。 这些帐户通常没有密码。
• 用户帐户johnn已成功登录，而用户johnn未能成功尝试成为用户whoopsie和lightdm。
• 服务器pfe1已严重受损。

我对PFE的建议

• 从原始发行版重建服务器pfe1，然后将所有相关补丁应用到系统，然后再将其恢复使用。
• 设置集中式系统日志服务器，并将PFE混合云中的所有系统日志记录到集中式系统日志服务器和本地日志中，以合并日志数据并防止篡改系统日志。 使用安全信息和事件监视（SIEM）产品来促进安全事件的检查和关联。
• 在所有公司服务器上实施bash命令时间戳。
• 在所有PFE服务器上启用根帐户的审核日志记录，并将审核日志定向到集中式syslog服务器，在该服务器上可以将它们与其他日志信息相关联。
• 研究IP地址为192.168.56.1的系统是否存在漏洞和危害，因为它被用作pfe1危害的关键点。

如果您已使用取证来分析Linux文件系统是否存在漏洞，请在评论中分享您的提示和建议。

---

Gary Smith将在今年的LinuxFest Northwest上发表演讲。 查看计划亮点或注册参加 。

翻译自: https://opensource.com/article/18/4/linux-filesystem-forensics

漏洞取证