标签： pecker scanner

基于语法分析的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

为什么不能在字符组中使用反向引用

有个网友，发一封邮件给我，让我帮看下一段“加密”字符串的解密问题，在线解密的解密不了。代码大约如下：看到代码后，不禁惊讶起来，现在坏人们的想法真猥琐。利用preg_replace函数的e修饰符(e修饰符在php5.5里，被取消了)，来执行第二个参数里的内容，而第二个参数里的内容，不是常规的函数组成的字符串，其函数名都是ASCII码十六进制形式。从而避开了基于字符串形式正则匹配的“简易木马扫描器”的扫描。2010年时的在线解密功能，只支持eval gzinflate base64_decode三个函数的任意组合形式的字符串解密，且格式很严格，必须以<?php开头，以?>结尾，不支持嵌套解密。到了2012年，发现有好多网友在陆续使用，并反馈给我。我再次做了改进，支持嵌套解密，编码转换等功能。这次，看到这个加密方式，索性直接写一个支持任意以eval函数执行的合法php字符串解密，且支持同一份代码的多次出现、循环嵌套解密，格式也不用那么严格，只要被解密部分是合法的php代码即可，其他地方，可以有任意字符串，提高易用程度。方向定了，实现起来，也应该没什么难度，目的也是基于字符串处理，正则匹配php语法函数，提取加密部分，解密，替换到原文本中。所有的难点，就是正则匹配php语法了。我在匹配eval(base64_decode('xxxxxxx'))遇到了一个问题。因为不能确定代码使用的是单引号还是双引号，故我打算捕获分组，再反向引用一下，那正则表达式就是(['"]).+?\1，正则捕获的第一个分组里的内容会是',那么\1的反向引用将是'，看上去，匹配完成了，但会产生大量回溯，回溯次数取决于中间字符串长度。作为性能洁癖的码农，不能接受正则里出现大量无用的回溯，决定使用字符组的脱字符^来对字符取非匹配。那么，表达式就是 regexbuddy的测试结果却是这样：如图，调试信息中所示，绿色线条画出的部分，都是正常正确的匹配，表达式(['"])匹配字符串'，并且分配到group 1中；表达式最后的\1反向引用，也匹配到了'，这个可以在debug截图中得到确认。但红色部分，让我产生了疑惑，表达式[^\1]为何匹配到了字符串1230'''''cfc4n(解释一下：+为量词，先匹配，再将转动权交给表达式后的'，再去匹配，其发现后面没有字符，那么再回溯到前一位。。一直到匹配到字符')，匹配到字符串1230跟cfc4n倒是正常，但group 1就是'，[^\1]匹配到'''''实在不能理解。暂时改用其他办法实现，比如(['"]).*\1，但性能差，且不精确。或者用环视lookaround（也叫零宽断言）解决([\'"])(?:(?!\1).)+\1。对于这个问题，我困惑很久，在stackoverflow上找到一个相似的案例General approach for (equivalent of) “backreferences within character class”?问题也是跟我类似的问题，解决方案，也是用环视解决，其实，环视的效率，比非贪婪的方式还多一个回溯。但回答者只是给了解决方案，也没说出真正的原因。然后，又看到了另一个相似案例Negating a backreference in Regular Expressions，解决方案也是一样，正则环视解决，回答中，还说了原理： Instead of a negated character class, you have to use a negative lookahead: \bvalue\s*=\s*(["'])(?:(?!\1).)*\1 (?:(?!\1).)* consumes one character at a time, after the lookahead has confirmed that the character is not whatever was matched by the capturing group, (["'']). A character class, negated or not, can only match one character at a time. As far as the regex engine knows, \1 could represent any number of characters, and there's no way to convince it that \1 will only contain " or ' in this case. So you have to go with the more general (and less readable) solution. 但这个原理说的是环视匹配的原理，并没有说“为什么字符组中反向引用匹配的字符串不正确”的真正原因。对于我的好奇心，显然不能轻易放过这个疑问，继续google中搜索，终于在regexbuddy的另一个官网找到了介绍：Parentheses and Backreferences Cannot Be Used Inside Character Classes，刚打开这个页面时，被配色、布局震惊了一下，这跟regexbuddy官网出奇的相似，仔细看了下，才发现这也是他们的网站之一。这里给出了说明： Round brackets cannot be used inside character classes, at least not as metacharacters. When you put a round bracket in a character class, it is treated as a literal character. So the regex [(a)b] matches a, b, ( and ). Backreferences also cannot be used inside a character class. The \1 in regex like (a)[\1b] will be interpreted as an octal escape in most regex flavors. So this regex will match an a followed by either \x01 or a b. 这里提到，正则表达式中，不能在字符组中使用反向引用，原因是正则表达式的\1在字符组中[\1]，在大多数的正则流派中，会被正则引擎作为八进制转义，实际上的匹配结果将变成\x01。知道这个原因之后，就很好理解为什么之前的表达式[^\1]匹配到' ' ' ' '了。因为，这里的取非，是对字符\x01的取非，而不是对字符'的取非，我之前还天真的以为，取非的字符串是'呢。除了不能在字符组中使用反向引用，还不能使用捕获分组，这里也提到了，正则表达式的元字符括号()在字符组中将被理解为普通的字符()，也就是说，在字符组character class中，不用再转义了，即[()]是合法的表达式，且可以匹配到(或者)。比如文章中给的例子：表达式[(a)b]匹配结果并不是a或者b，如果a匹配到，再将a分配到group 1中，而是可以匹配到a或b或(或)四个字符。所以，在字符组中使用反向引用，是不能实现的了。如图：最后，解密的程序也写好了，支持eval base64_decode preg_replace gzinflate等各种函数的在线，目前除了自定义函数、字符串不支持解密以外，其他均支持，只要用eval函数执行的代码。跟http://ddecode.com/phpdecoder/相比，我的解密程序不支持变量函数、变量字符串解密，这是缺点。同时，优点是支持一段代码多个eval函数解密，且替换还原到原文。而phpdecoder中，只会保留最后解密的那个eval内代码解密情况，其他的都没了。其实，基于字符串匹配的解密方式，都肯定存在不严谨、不正确的解密行为，最准确的，莫过于写一个php拓展，劫持eval函数，并且执行被解密代码，使用加密代码内原有变量，来实现最准确，严谨的解密。 PS：如果你对这里的正则表达式的术语有疑惑，请阅读这个PPT《正则表达式》PPT-匹配原理 PPS:后来，无意中看到360网站安全检测的后门查杀代码里的正则的写法实在说不过去，作为国内一线安全厂商，这正则准确性、严谨性、误报、性能都有较大提升空间，忍不住的唱起“放只乌龟到处爬，放只螃蟹有点Zha，有点Zha”...如果他们不嫌弃的话，可以参考下《如何精确查找PHP WEBSHELL木马？》里的python版的webshell检测的正则，三年前的了，可能有很多东西已经变了。 2013/09/14更新：我自己开发了一个项目，PHP版本的webshell扫描，基于语法分析的，名字叫 Pecker Scanner，欢迎使用。

2013-08-30 2 0

如何精确查找PHP WEBSHELL木马？

上篇提到了关于网上流传查找PHP webshell的python脚本中，不严谨的代码，并且给出了一个python的检测代码，同时，下文里也提到不能检测到反引号的命令执行的地方。今天，我想了下，现在把思路发出来。先来看下反引号可以成功执行命名的代码片段。代码如下：正则表达式该如何写？分析：对于可移植性的部分共同点是什么？与其他正常的包含反引号的部分，区别是什么？他们前面可以有空格，tab键等空白字符。也可以有程序代码，前提是如果有引号（单双）必须是闭合的。才是危险有隐患的。遂CFC4N给出的正则如下：【(?:(?:^(?:\s+)?)|(?:(?P<quote>["'])[^(?P=quote)]+?(?P=quote)[^`]*?))`(?P<shell>[^`]+)`】。解释一下：【(?:(?:^(?:\s+)?)|(?:(?P<quote>["'])[^(?P=quote)]+?(?P=quote)[^`]*?))】匹配开始位置或者开始位置之后有空白字符或者前面有代码，且代码有闭合的单双引号。（这段PYTHON的正则中用了捕获命名以及反向引用）【`(?P<shell>[^`]+)`】这个就比较简单了，匹配反引号中间的字符串。然后我将这段代码写入程序中，测试跑了一下discuz的程序。结果有一个误报。误报的位置为“config.inc.php”中的“define('UC_DBTABLEPRE', '`ucenter`.uc_');”，什么原因造成的？这行代码符合了前面有闭合的引号，也有反引号的使用，所以，符合要求，被检测到了。如何再排除这种情况呢？这个有什么特殊的？前面有逗号“,”？如果是字符串连接的点号“.”呢？再排除逗号？好吧，我错了，我不该用我的思维来误导你。换个思路。找下反引号可执行的代码的前面字符串的情况，他们只能是行的开始，或者有空白字符（包括空格，tab键等），再前面也可以有代码的结束标识分号“;”，其他的情况，都是不可以执行的吧？嗯，应该是这样。（如有错误，欢迎斧正）既然思路有了，那正则代码更好写了。如下【(^|(?<=;))\s*`[^`]+`】，解释一下，【(^|(?<=;))】匹配位置，是行的开始，或者前面有分号“;”。【\s*`[^`]+`】空白字符任一个，然后是....(你懂的)。OK，写好之后，检测，又发现一个问题。匹配引入文件的正则也匹配了“require_once './include/db_'.$database.'.class.php';”这种代码，什么原因造成的，您自己分析吧。给出修复之后的python代码，如下：稍微检测了一下Discuz7.2的代码，还是有误报的，误报的为这种包含sql的代码：由于这个脚本是按照一行一行的代码来处理的，所以，有这种误报。您自己去修复吧。相对网上流传的脚本来说，还是比较准确的。欢迎转载。转载请注明来源，以及留下博客链接，同时，不能用于商业用途。（已经修复，增加了反引号后面【\s*;】的判断。2010-07-27 17:06） PS：如果说上传文件也算是危险的、值得注意的操作的话，建议加上move_uploaded_file函数的检测。你知道在哪里加的。^_^ 2010-12-17 关于这些代码，已经放到google 的代码托管上了。SVN地址为 https://code.google.com/p/cnxct/ 大家个获得最新版。我是一个PHPer，写的python有点憋，有点懒，还请各位安全界的大牛，程序界的前辈不要鄙视，要给建议，谢谢。php版的以后在写吧。同时，也欢迎各位安全爱好者反馈最新的web shell特征代码，我尽力增加到程序中区。 2013-09-13更新： PHP版基于语法扫描，语义分析的扫描器，已经实现，详情见： Pecker Scanner php编写的webshell扫描器

2010-07-27

+16 20 0