转载

聊一聊chkrookit的误信和误用

很久不写文章了。BSRC在约稿以及个人最近吐槽模式的开启，索性就借着劲头写点东西缓解缓解。

chkrookit以及rkhunter基本上已经成为类unix系统的应急响应中的标配了。大多数处理安全事件基本上上机器的第一步都是来个两连发。但很多是以失望结束，或者出了结论又不知道如何是好。这篇文章或许能够解决你们的部分困惑。这篇文章主要是讲chkrootkit，rkhunter回头有空再吐槽。

首先对工具我们应该有一个明确的认识。工具是死的，人是活的，攻防本身就是人与人的对抗。挑战的对象是活生生的人而不是预定义好的程序时，机械的依靠某个工具，真正上战场了注定要悲剧。对于用于实际对抗中使用的工具，什么时间用，能够解决什么问题，对它的期望如何。我们心里应该很清楚，甚至我们有多大程度可以相信它的结论，欺骗或者bypass它的成本是什么样子也都需要了解。

言归正传，这篇文章我们先聊聊chkrootkit: http://www.chkrootkit.org。从README中我们了解到最近一次更新是：04/30/2014，而前一次更新是09年…看看CHANGELOG，大概也能够明白它都有哪些功能，代码目录的命名很好的反应出了这一点：

聊一聊chkrookit的误信和误用

chkrootkit本身是一个shell脚本。运行 chkrootkit –l 可以看到所有的检测集。注意 chkrootkit脚本 这几个字的重点飘红。一般来说，这种开源的 脚本调用外部命令方式工作的安全检查程序 ，按照经验注定是悲剧的节奏（注意定语）。而且上机器后看都不看运行环境就执行这类检测程序 极易被反补一刀 [1][2]

打开chkrootkit我们一开始就看到这样两句SHELL

pth=`echo $PATH | sed -e “s/:/ /g”`

pth=”$pth /sbin /usr/sbin /lib /usr/lib /usr/libexec .”

啧啧，检查范围让64位操作系统情何以堪啊

大体来说检测流程是什么样子吧：

1. 历史遗留rootkit/backdoor/蠕虫的默认检测；方式为根据位置、特殊的文件名、字符之类的来找文件，根据绑定的端口号来看是否有某个特定的后门（拜托…）。但这些查找特征赤裸裸的写在chkrootkit这个脚本里面的，绕过这类的检查的成本有多大,指望在实际对抗中，能查出什么样的东西，大家预期不要太高。

2. 后面进入checking阶段，有几个check点还比较有意思，但基本上都是靠外部的bin来实现的。但我们不要忘记了，这些bin运行的环境很有可能是恶意的哦。

这里不讨论从ring0上怎么躲避检查了，简单的一些open文件的redirect就能够bypass一堆，有兴趣的可以去phrack 97年的文章中看看思路[3]。靠ring3的 开源程序 去查 ring0级别的未知后门 本身出发点就有问题，这里注意是开源啊，再用ring0去bypass纯粹是欺负人啊：）。（当然对于实现不好的，只能被称作beta版的rootkit还是有可能，文件引用计数差异啊、没有相互配合好的cd和readdir调用啊之类的。但谁让你开源啊~啧啧。）

吐槽我还是限制后门在ring3下的实现吧。

Ldd看一下

聊一聊chkrookit的误信和误用