应急响应-提取黑客已删除的文件内容

应急响应过程中，经常会遇到黑客删文件的情况。比如上面这种黑客执行 echo > /root/.bash_history 的方式来删除文件，如果没有事先部署主机安全agent做命令审计，这种情况基本都无解。

但通过魔改debugfs的源码，解决了这一类痛点。

误区： echo >$file 真的覆盖了文件吗？

按照以往的理解，

rm -f $file

通过rm命令删除的文件，是可以恢复。

echo >$file

使用echo追加到文件，是“覆盖”文件的内容。这也是大部分黑客在入侵后清理痕迹时，更喜欢用echo来“覆盖”掉文件的原因，防止被溯源。

测试结论

但实际的测试结果证明，echo并不是真正意义的覆写文件，只是改变了文件的block指针。

模拟黑客删除文件的场景

假设黑客对 ~/.bash_history 文件做了删除操作，但应急需要提取黑客历史执行的命令。

此时 ~/.bash_history 文件是没有内容的，应急人员上机排查只能看到最后一条命令执行的记录。

使用魔改debugfs对磁盘内容进行提取

前面分析过，echo覆盖文件只是改变了文件指针，所以文件内容还是在磁盘上的。那么就可以用debugfs找回来。debugfs提供了一个查找未使用的block的命令为dump_unused。

我在debugfs源码做了大量修改，使dump_unused在查找未使用block的同时，并支持搜索block中的关键字。

比如我知道我在history中执行过 curl ip.sb 这条命令，那么原本的.bash_history文件中肯定会包含这条命令的内容，所以我可以将其作为关键字在debugfs中搜索。

原理分析

ext3/4文件系统中，当一个文件被删除后，系统会将inode中block的指针给覆写为0，并将对应的block标记为unused，但是不会覆写文件在block中的内容。

而系统中未使用的block是全0填充的，但如果一个block被标记为unused但是却有内容，就证明该block是被删除过的。

所以使用debugfs搜索磁盘中所有 被标记为unused但是有内容的block ，再从中提取存在关键字的block，就能快速找到被黑客删除的文件内容了。

魔改后的debugfs对于黑客删除history、ssh日志等强特征文件有非常好的溯源效果。

发散思考

与本文无关的内容，但是临时想到记录一下。上文件提到过 echo >$file 覆盖文件。

echo 0 > file.txt 和 echo 0>file.txt 的区别是什么？

当你在重定向操作符>前面加上一个数字，它会改变被重定向的文件描述符。默认情况下（即没有数字的情况下），>操作符会重定向标准输出（文件描述符1），echo >$file 等价于 echo 1>$file。当写0>时，你实际上是在重定向标准输入（文件描述符0），而不是标准输出。

echo 0 > file.txt和echo 0>file.txt在功能上是有区别的。前者是将”0″写入到file.txt，而后者是在尝试重定向echo命令的标准输入，而echo命令并不从标准输入读取任何内容，所以file.txt在执行后者之后是空的。

0 1 2 3 在Linux中的含义？

在Linux中，每一个进程都会有一些被预定义好的文件描述符。以下是这些预定义文件描述符的含义：

• 0： 这个文件描述符代表标准输入（stdin）。当一个程序需要从用户输入或者文件输入获取数据时，会使用这个文件描述符。
• 1： 这个文件描述符代表标准输出（stdout）。当一个程序需要打印或输出数据时，会使用这个文件描述符。
• 2： 这个文件描述符代表标准错误输出（stderr）。当一个程序需要打印错误信息时，会使用这个文件描述符。
• 3： 文件描述符3以及之后的数字，并没有预定义的含义，它们可以被进程用来打开和操作任何其他需要的文件。当一个进程打开一个新文件时，系统会提供一个最小的未使用的文件描述符。

例如将标准输出和错误输出都重定向到同一个文件，命令如下：

command > file.txt 2>&1

赞赏

微信赞赏支付宝赞赏