OfficeScan
一个圈住多种趋势公司产品远程控制的环：
大多数趋势公司的产品中都有一个用于管理员网页登陆的组件，尽管其产品的核心项目是使用Java/.NET语言编写的，这个组件却是用PHP实现的。这意味着，一旦他们决定使用这个组件，他们就需要将PHP翻译器放在产品中。这就为我们提供了一个完美的突破点：一个共同的代码存在于不同的产品中，所以一旦我们找到一个漏洞，就有完美的方法来实现可靠的漏洞利用。
由于以上我所陈述的理由，我针对趋势公司的OfficeScan产品的组件系统进行了一次代码审计，结果对我来说基友区又不幸，我发现了六个不同的漏洞，但是只有两个是0 day。
在深入漏洞之前，我想先分享这些组件库工作的一些细节。
开始着手：
这个组件框架有一个代理机制。简短来说，我们有proxy_controller.php这个点获取用户输入的参数然后根据输入调用有关的类。
组建类型主要分为两种。用户生成和默认的组件。以下的代码取自Proxy_controller.php:
base.php:
以上代码段分别执行了以下操作：
1、 将GET和POST参数合并并存储在$g_GetPost变量中
2、 验证变量$g_GetPost[‘module’]
3、 然后通过参数$g_GetPost[‘userGenerated’]来确定组件请求是否是用户生成的
4、 Include请求的php类
5、 最后一步，创建一个WFProxy实例，然后调用proxy_exec() and proxy_output()两个方法
基本上，我们有多种WFProxy的实现方式具体哪一种实现会被初始化取决于从客户端获得的值。
既然我们已经了解参数是如何被传递给不同的类，现在我们可以讨论我发现的技术细节了。
Vuln1.php
显而易见，我们有潜在的命令注入，但是我们需要回答一个问题，我们能控制$this->cgiArgs这个数组吗？答案是肯定的，如果你回到第一个我之前分享的代码块，你会发现$request = new WFProxy($g_GetPost, $wfconf_dbconfig);并且$g_GetPost是我们完全可以控制的。
每一个单独的WFProxy类都继承于ABaseProxy 抽象类，以下是基类的_consruct()方法的前两行。
-
public function __construct($args, $dbconfig){
-
$this->cgiArgs = $args;
这意味着，$this->cgiArgs 直接与GET 和POST 参数相关。
PoC
重要笔记：当exec()方法有第二个或第三个参数时，如果你想使用管道欺骗，你只需要成功的执行第一个指令。我们的指令看起来像
php ../php/lwcs_report.php TOP=2>&1|ping 4.4.4.4
由于我们甚至没有lwsc_report.php脚本，可以使用2>&1来欺骗exec()方法。第一部分的指令返回没有错误的指令。
不幸的是，我意识到这个漏洞已经被 Steven Seeley 从源码Incite(?)中发现几周之前也被发布（http://www.zerodayinitiative.com/advisories/ZDI-17-521/）。根据他的建议，利用这个漏洞首先需要身份认证。我发现了一个绕过认证的0day方法，我之后会在Vuln6中简单的多谈一点。
Vuln2 3 4
这些漏洞也正在被另外一个研究院发现。这些漏洞并没有引起他本作者的足够关注，因此我留下这个exploit-db链接所以好奇的读者可以去查看一些细节：https://www.exploit-db.com/exploits/42920/
Vuln5:
你还记得我刚刚提到的两种组件（用户生成和系统）？趋势公司在代码库中有一个默认的用户生成组件的实现。名字是modSimple.我相信他们是为了展示如何从用户组建实现开始所以把它留在了项目里。
这里是proxy_exec()方法对于这个组件的实现
Vuln5.php
它直接使用url参数而没有验证。你还记得￥this->cgiArgs[‘url‘]是用户可以控制的吗？
Vuln5_PoC
Vuln6:
我已经提过核心系统是用Java/.NET编写的，但是这个组件系统是用php实现的。所以最大的问题就是：
当组件接受到请求时他们是怎么知道用户已经被认证的？
最简单的回答这个问题的方法就是追踪Burp logs。以下HTTP POST请求尤其引起了我的注意。
Vuln6.txt
首先，我们在这里有一个CSRF验证检查。但是重点在于第17-23行。$wfuser->standalone_user_init()和$wfuser->product_user_init()和组件框架认证用户有关。我将从第一个调用开始。
Vuln6_2.php
以上代码块分别执行了以下过程：
1、 从cookie获取值
2、 调用loaduser_byuid()，并传值给这个函数
3、 使用已给参数调用get_user()函数。如果这个函数返回为真，他将返回true并帮助之前函数继续并调用recover_session()函数
4、 Get_users()函数只利用给出的id值执行sql语句
$wfuser->product_user_init()函数序列几乎是相同的。$wfuser****->****standalone_user_init****()**** and ****$wfuser****->****product_user_init****()唯一的区别在于第一个使用user_id，第二个使用username.
我在这里没有看到认证过程。Hash参数甚至没有被使用。所以使用相同的变量调用这个点将完成从底向上的认证。
一个带了他们所有并在黑暗中束缚他们：
现在我们有两个漏洞。第一个是最新修补的命令注入，第二个是绕过认证。这两者结合给我们一个没有权限便可以执行系统命令的机会。
相同的代码/漏洞：趋势
