标签： webshell

基于语法分析的PHP webshell扫描工具–WoodPecker Scanner

前段时间，在一位大牛的BLOG上看到其resume上撰写的开源项目列表琳琅满目，数不胜数。再跟自己对比一下，从来没有一个开源项目，没有成功的参加过一个开源项目，只是零星的贡献过几个所谓工具，脚本。顿时无地自容，同时也是羡慕不已，再暗自勉励鼓励自己，向这位大牛学习。也是在前段时间，遇到了一个正则的问题《为什么不能在字符组中使用反向引用》，使得我又跟着自己的思路，翻阅之前的博客，面包屑导航一般，跟着链接，走到了另外一篇博客《如何精确查找PHP WEBSHELL木马？》。写那篇博客时，是2010年7月，我还在久游网工作，工作内容也是代码安全相关。我最初的实现，也是基于正则表达式实现的字符串匹配，来捕捉查找危险代码。同时，也计划在二期里，用LEX+YACC来实现对PHP代码的精确分析，扫描查找，为此，也经常装模作样故弄玄虚的研究学习yacc、lex，学习PHP的Zend引擎实现方式，研究zend_language_scanner.l、zend_language_parser.y、zend_language_scanner.c等几个文件的编写思路等等等等。从我2月下旬入职，到11月初离职，总共7个多月的时间里，也并不是一直做这个项目，甚至这个项目只是作为我个人研究的范畴，平常工作中，只能利用空闲时间来研究。因为种种原因，在没有完成那个项目之后，离开了久游。不管是因为自己基础薄弱，还是时间不足还是什么原因，每次想起这件事，都因没有完成那个项目而觉得遗憾。人总喜欢找借口，好比我前段时间，心里烦躁不安、胡思乱想，开始玩起了英雄联盟，从5月到现在，断断续续玩了5个月了。支持者的角度上想，人总不能一直紧绷着大脑，偶尔玩玩游戏，放松一下自己，又何尝不可？反对者的角度上来想，放纵自己堕落，还找理由，找借口？我有时赞同前者，有时赞同后者，现在，我就觉得既然都是找借口去做事情，为何不给自己找个借口，做一些有意义的事情呢？“那就努力开发维护一个开源项目吧”我心理暗暗这么说道，决定完成曾经的遗憾。这线引得有点太长，也算是我的自我检讨与牢骚吧。所谓扫描工具，先要扫描，才能找到需要的东西。对于代码扫描方式，实现方式大约是特征关键字的捕捉，正则表达式的语法匹配，语法语义分析这些。这些实现方式，准确性、严谨性也是层级递增的。特征关键字方式，是最简单、最不准确的检测手段，上篇博客里有个比较好的例子：这里的正则的最后部分中文字符串那里|小组专用大马|提权|木马|PHP\s?反弹，这里的正则不是原本意义上的正则表达式了，只是简单的或逻辑，没有其他更严谨的匹配规则，所以只能当成简单的特征关键字来看待。比如代码或注释中出现螓首微微压下,右手倒提权杖、电影《特洛伊木马》均被当作webshell来抓获了。这种实现方式，最不准确。正则表达式匹配方式，是在特征关键字之后，更加准确的捕捉方式，但仍存在大量的误报、漏报情况，比如我在三年前写的python版php webshell检测工具里的代码：虽然可以更精确的匹配函数名符合的地方，字符串中出现的会被跳过，但仍无法排除注释中的代码，这种匹配结果，可以作为参考，仍需要管理人员认真校对每一个检测结果。当然，漏报情况，相比特征字符串的方式，要严谨的多。语法语义分析形式，是根据php语言扫描编译的实现方式，进行剥离代码、注释，分析变量、函数、字符串、语言结构的分析方式，来实现关键危险函数的捕捉方式。这样可以完美解决漏报的情况。但误报上，仍存在问题。误报问题所在，一是被检测文件是否为合法php语法文件，token_get_all函数的实现，是不验证是否问合法php语法文件的，只是对其进行扫描，分析。而语法验证是比较难于试下你的地方。其次是代码中因为业务需要而出现的危险函数，如何排除掉，恶意代码如何界定？服务器云判断是一种根据恶意代码串的指纹，根据大量后门数据，做语法、语义分析，做业务逻辑分析，理解这段代码的用途，给出其是否为恶意代码的定位，而其他使用者，直接可以得到该代码片段是否为恶意代码的结果反馈。Pecker Scanner首先是基于语法分析，剥离token、注释、字符串、变量、语言结构，再进行php语法检测，提取恶意代码的扫描工具，来解决漏报问题。同时支持服务器云判断，尽量避免误报问题。比如exec ($cfe,$res)在Discuz!中(只是举例)是正常的功能代码，而在木马后门中，这就是恶意文件。同样的一段代码，在不同的项目中，扮演着不同的角色，这也不能光凭借代码功能上判断，还得依赖所属项目。这需要大量的木马后门库，以及开源项目库希望大家可以帮着提交一些。 Pecker Scanner这个开源项目，托管在Github上，大家都可以fork它，完善它。目前Pecker Scanner生成的报告，跟服务器校对检验方式是通过jsonp方式通讯，若以后流量较高，则采用验证API形式，直接在pecker scanner代码中，根据api 、 key运算，post多个token代码段到服务器获取状态，展示到报告文件中。一来减轻jsonp这种大量http请求数。二来减少恶意无用的查询。 Pecker Scanner目前是beta 0.3版本，您可以在这里下载Pecker Scannerbeta 0.4.4版，不建议直接到github上下载，因为github上可能存在我正在调试的代码，或者不完善的新功能。 Pecker Scanner的项目主页在这里，以后的版本更新，新功能发布，也都会在这里公告。扫描报告样例在pecker scanner report样例，您可以先预览一下。 2014-03-03 发布新版本 pecker scanner 0.4 2014-05-27 发布新版本 pecker scanner 0.4.4 修复复杂语法complex(curly)syntax的检测，比如${ $ {func}}($evil)语法。 pecker scanner beta 0.4 releases fix bugs for some of the syntax with "{" and "[". fix bugs with code : (require '1.dat').'.php'; thanks for poker付 ( http://weibo.com/1776130645 ) add "include" to default checklist . Pecker Scanner Server目前收集的开源软件包括Discuz_7.2_FULL_SC_UTF8、DedeCMS-V5.7-UTF8-SP1-Full；木马后门包括PhpSpy 2011、PhpSpy 2013、PhpSpy 2011加密版。其他开源项目以及木马后门，等待各位的反馈。 2013-09-24新增开源软件、webshell后门特征： DedeCMS-V5.7-UTF8-SP1-Full Discuz_7.2_FULL_SC_UTF8 Discuz_X3.0_SC_UTF8 Discuz_X3.1_SC_UTF8 espcms_utf8_5.7.13.09.10_b HDWiki-v5.1UTF8-20121102 Joomla_2.5.14-Stable-Full_Package Joomla_3.1.5-Stable-Full_Package KingCMS_6.1.1641(Sp2) none phpcms_v9.4.2_UTF8 phpMyAdmin-4.0.7-all-languages phpspy 2011 phpspy 2013 phpspy 2013 加密版 phpwind_UTF8_8.7 phpwind_v9.0_utf8 WeCenter_2-2-1 wordpress-3.6.1 您能做的：风险函数列表总结木马后门样本提供服务器赞助(目前暂时将Pecker Scanner Server部分托管在朋友的服务器上，目前流量还能支撑，若...) 推广它(特别感谢黑哥的第一次推广，您的每一次使用，都是对我最大的支持) 使用反馈(感谢bgho4t的第一个测试报告) 我能做的：默默的开发，悄悄的维护，轻轻的调试，偷偷的发布。

2013-09-22

+1 5 0

关于网上流传查找PHP webshell的python脚本中，不严谨的代码

不是闲着蛋疼，也不是批评谁，只是不忍心看到不严谨的代码在网上被疯传，误导初学者。以下引用的代码以及思路来自网络，只针对代码，不针对人。如有雷同，纯属巧合。来自某大牛python版本的检测服务器上PHP代码中webshell的脚本代码片段如下：然后，接着是python处理上面列表（数组），把每个列表的第一个元素作为正则表达式内容，然后进行匹配处理的。先看第一个检测“PHP一句话木马”的这个正则。【eval\(\$\_POST】这里转义了字符【_】，字符“_”不是元字符，不需要转义的，其实，转义也无妨，聪明的正则表达式引擎会识别修正的。来说下这个思路的遗漏之处。这里仅仅匹配字符串“eval(”后面的变量“$_POST”，如果是“$_GET”呢？如果是“$_REQUEST”呢？如果程序先把$_POST/$_GET/$REQUEST的key的变量先赋值给一个自定义的变量名，然后在用PHP的“eval”函数执行这个变量呢？是不是就查找不到了？其实，并不需要知道“eval”函数执行的变量名是什么，只要查找“eval(”即可，当然，还要注意“eval”函数后面可以有空格，tab键之类空白字符。上面的代码片段中，也没考虑到这一点。再看看下一个列表的第一个元素。【(system|shell_exec|exec|popen)】，这个正则的意思是只要字符串里包含“system”、“shell_exec”、“exec”、“popen”这四组字符串即判定为危险字符。很明显，这个方法太不严谨。如果程序员写的代码中，包含了这四组字符，即可被判定为危险函数。很不准确，误报率极高。见下图到底什么样的代码是可疑的代码？关键词是什么？可疑的代码肯定是由可以执行危险操作的函数构成，可以执行危险操作的PHP函数最重要的就是“eval”函数了，对于加密的PHP代码（仅变形字符串，非zend等方式加密），肯定要用到“eval”函数，所以，对于不管是用哪种加密方法的代码，肯定要用到“eval”函数。其次就是可以执行系统命令的函数了，比如上面某牛的代码中提到的四个“system”、“shell_exec”、“exec”、“popen”。当然还有其他的，比如passthru等。PHP还支持“·”字符（ESC键下面那个）直接执行系统命令。我们可以把正则写成这样【\b(?P<function>eval|proc_open|popen|shell_exec|exec|passthru|system)\b\s*\(】。解释一下：大家都知道【\b\b】用来匹配单词两边的位置的。要保证【\b\b】中间的是单词，即使函数名前面加特殊字符，也一样通过匹配，比如加@来屏蔽错误。后面的【\s*】用来匹配空白字符的，包括空格，tab键，次数为0到无数次。前面的【(?P)】是捕获命名组。用来当作python代码直接引用匹配结果的key。还有的网友提到了，如果我把代码放到图片拓展名的文件里呢？那你只检测.php，.inc的文件，还是找不到我的呀。嗯，是的，如果恶意代码在gif、jpg、png、aaa等乱七八糟的拓展名文件里，是不能被apache、IIS等web Services解析的，必须通过include/require(_once)来引入。那么，我们只要匹配include/require(_once)后面的文件名是不是常规的“.php”、“.inc”文件。如果不是，则为可疑文件。正则如下【(?P<function>\b(?:include|require)(?:_once)?\b)\s*\(?\s*["'](?P<filename>.*?(?<!\.(?:php|inc)))["']】。解释一下：先看【(?P<function>\b(?:include|require)(?:_once)?\b)】，【(?P<name>)】为正则表达式的“命名捕获”，PHP中有同样的用法。也就是说，在这括号内的捕获的数据，会分配到结果数组的key为“name”的value中。再看里面的【\b(?:include|require)(?:_once)?\b】,【\b\b】不解释了，为单词边界位置。里面的【(?:include|require)】匹配字符串“include”、“require”两个单词，其中前面的【(?:)】未不分配组，用于提高效率，可以去掉【?:】变成【(include|require)】。在后面一个【(?:_once)】也是做不分配组的操作，便于提高正则表达式效率。同样，后面的量词是“?”代表这个组可有可无。就满足了“include”、“include_once”、“require”、“require_once”四种情况。有的朋友可能这样写【(include|include_once|require|require_once)】也能实现目的。但是，为了更搞的效率，我们对这个正则做优化，针对部分字符串做分支更改，改成上面那个【\b(?:include|require)(?:_once)?\b】。再看下面的【\s*\(?\s*["'](?P<filename>.+?(?<!\.(?:php|inc)))["']】中，【\s*】匹配空白字符，包括空格，tab键等。后面的【\(?】，匹配字符“(”，后面的量词“?”表示这半个小酷括号可有可无。防止“incude "123.php"”这种没有括号的情况。再后面【["']】匹配双引号，单引号的。最后的也是。再看看这个【(?P<filename>.+?(?<!\.(?:php|inc)))】，其中【(?P<filename>)】上面介绍了，为命名捕获，把结果放到match.group("filename")里。【.*?】为任意字符，后面的量词是“忽略优先量词”，也就是平常说的“非贪婪”。这里最少匹配零个，（防止.aa、.htaccess这种没有文件名，只有文件拓展名的文件被引入）。后面的【(?<!\.(?:php|inc))】，这里用到了反向零宽断言（环视）的非操作（只匹配位置，不匹配字符串，跟【^$\b】等一样）。这个表达式是针对这个位置的后面字符起作用的，也就是说后面的【["']】的前面不能是“.php”、“.inc”，这里也就是取了文件名的最后的拓展名。（正则里，可以用【^】对字符取非，但是不能对“字符串组”取非，这里用了零宽断言来实现。）综上所述，最后，鄙人给出的python代码如下：仅供参考，欢迎斧正。下面截图为扫描Discuz7.2的效果图，当然，也有误报。相对网上流传的python脚本，误报更少，更精确了。问：这个方法完美了吗？可以查找目前已知的所有危险函数文件了吗？答：不能，如果include等引入的文件没有拓展名，这里就匹配不到了。问：如何解决？答：留给你解决，聪明的你，肯定可以搞定。 PS：“`”反引号执行命令的还没写，暂时没好的办法。容易跟SQL语句中的反引号混淆。不太好匹配。如果光匹配反引号就提示的话，那误报太大了。待定吧。（术业有专攻，请勿因为一处不好的代码，否定一个人的能力。你懂的。再次重申，此文只针对代码，不针对人。其次，鄙人给出的python代码随便复制，随便传播，爱留版权就留版权，不爱留就删了相关字符，也就是您爱干吗干吗。）我先休息一会，明天再说。（前半句为三国杀曹仁的台词，哈。） =============================我是万恶的分割线====================================== 最新代码在这里给出了。

2010-07-26

3 0