应急响应-提取黑客已删除的文件内容
应急响应过程中,经常会遇到黑客删文件的情况。比如上面这种黑客执行 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赞赏
微信赞赏支付宝赞赏
4条评论