近日，Zabbix的web后台爆出一个sql注入漏洞。青藤云安全团队立即响应，并提出了临时&最佳解决方案。

0x00  漏洞概述

漏洞类型：SQL 注入

危险等级：高

利用条件：该漏洞需要登录，但是系统内置Guest帐号且默认为启用状态。

受影响参数：profileIdx2

0x01 POC测试

http://xxx.testzabbix.com/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=3&method=screen.get×tamp=1471054088083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=2%27123&updateProfile=true&screenitemid=&period=3600&stime=20170813040734&resourcetype=17&itemids[23297]=23297&action=showlatest&filter=&filter_task=&mark_color=1

访问以上URL地址，若页面返回数据库INSERT报错信息，则漏洞存在。

0x02 漏洞分析

jsrpc.php该页面接受当传入参数 type不为6时（PAGE_TYPE_JSON 为常量6），如下图所示，可以给$data赋值$_REQUEST变量，我们知道$_REQUEST变量是接受 GET/POST/COOKIE任意一种输入的（接受COOKIE输入需要一定的配置支持），因此我们的payload不限于使用GET方法发送。

在我们输入的Payload当中 method=screen.get，调用的过程（switch case）是screen.get，如下图所示：

其中给$options[profileIdx2]赋值了$data[profileIdx2]，而该值是由未经过任何过滤的$data变量通过$_REQUEST传入。

之后该方法调用了CScreenBuilder::getScreen，该方法 (CScreenBuilder::getScreen)位于 ./include/classes/screens/CScreenBuilder.php

该方法(CScreenBuilder::getScreen)的构造方法(__construct)调用了 CScreenBase::calculateTime，并传入$option[profileIdx2]，此处也没有过滤，因此可以看到我们在$_REQUEST中传入的profileIdx2已经到达这里了。

在CScreenBase::calculateTime方法中，我们看到profileIdx2被带入了CProfile，并且是直接带入，如下图所示：

这里带入的时候是通过CProfile::update带入的，那么我们再来看CProfile::update方法，如下图所示：

发现该处也无任何过滤，而且最终该值被神奇的带到了CProfile的$insert中。

因此从用户输入（$_REQUEST）到带入到CProfile，参数profileIdx2未经过任何过滤器。

接下来jsrpc.php 的页面最后一行require_once了/include/page_footer.php

而/include/page_footer.php中调用了数据库操作，也就是CProfile::flush()方法，如下图所示：

该方法从CProfile::$insert中取出相应的值，并进行insertDB操作，此处没有过滤，通过遍历数组进行insertDB操作，因此总会遍历到我们的变量。

接下来，我们再来看insertDB操作

该操作的第四个参数又顺利的没有做任何过滤，最后带到了数据库进行查询 （DBexecute）。

我们再来看（DBexecute），文件位于/include/db.inc.php，发现是在本分的执行sql语句，因此我们的$_REQUEST[profileIdx2]成功的被送到了数据库并执行，也就是造成该漏洞的原因。

其实细心的读者会发现，带入数据库以前，许多变量都被zbx_dbstr这个函数过滤了，这个函数实际上就是mysql_real_escape_string，会对单引号双引号等特殊字符做转义。

最后不得不说的是，造成该漏洞真是需要开发人员编程时候的代码之间的各种“偶遇”，才能在层层过滤下都忘记过滤这个变量。

因此我们GET方法请求：

POST方法请求：

均可实现，如果配置允许的话COOKIE也是可以的。

0x03 影响的软件版本

目前已知受影响软件版本：2.0.x,2.2.x,2.4.x,2.5,3.0.x

0x04 相关案例

Zabbix 2.2.x, 3.0.x SQL 注入漏洞（latest.php）

点击“阅读原文”查看详细案例。

0x05 修复建议

（1）临时解决方案：

a.关闭guest访问权限，修改管理员账号为强口令。

b.对zabbix后台做访问控制，只允许指定IP访问zabbix-server后台。

（2）最佳修复方案：

升级目前最新版本的Zabbix系统（3.0.4）

0x06 总结

该漏洞需要登录，但是系统内置Guest帐号且默认为启用状态，因此攻击者可通过Guest帐号登录并进行攻击。该漏洞实际上是zabbix latest.php注入漏洞的另一种衍生攻击方式。

原创：青藤云安全

近日，Zabbix的web后台爆出一个sql注入漏洞。青藤云安全团队立即响应，并提出了临时&最佳解决方案。

0x00  漏洞概述

漏洞类型：SQL 注入

危险等级：高

利用条件：该漏洞需要登录，但是系统内置Guest帐号且默认为启用状态。

受影响参数：profileIdx2

0x01 POC测试

http://xxx.testzabbix.com/zabbix/jsrpc.php?sid=0bcd4ade648214dc&type=3&method=screen.get×tamp=1471054088083&mode=2&screenid=&groupid=&hostid=0&pageFile=history.php&profileIdx=web.item.graph&profileIdx2=2%27123&updateProfile=true&screenitemid=&period=3600&stime=20170813040734&resourcetype=17&itemids[23297]=23297&action=showlatest&filter=&filter_task=&mark_color=1

访问以上URL地址，若页面返回数据库INSERT报错信息，则漏洞存在。

0x02 漏洞分析

jsrpc.php该页面接受当传入参数 type不为6时（PAGE_TYPE_JSON 为常量6），如下图所示，可以给$data赋值$_REQUEST变量，我们知道$_REQUEST变量是接受 GET/POST/COOKIE任意一种输入的（接受COOKIE输入需要一定的配置支持），因此我们的payload不限于使用GET方法发送。

在我们输入的Payload当中 method=screen.get，调用的过程（switch case）是screen.get，如下图所示：

其中给$options[profileIdx2]赋值了$data[profileIdx2]，而该值是由未经过任何过滤的$data变量通过$_REQUEST传入。

之后该方法调用了CScreenBuilder::getScreen，该方法 (CScreenBuilder::getScreen)位于 ./include/classes/screens/CScreenBuilder.php

该方法(CScreenBuilder::getScreen)的构造方法(__construct)调用了 CScreenBase::calculateTime，并传入$option[profileIdx2]，此处也没有过滤，因此可以看到我们在$_REQUEST中传入的profileIdx2已经到达这里了。

在CScreenBase::calculateTime方法中，我们看到profileIdx2被带入了CProfile，并且是直接带入，如下图所示：

这里带入的时候是通过CProfile::update带入的，那么我们再来看CProfile::update方法，如下图所示：

发现该处也无任何过滤，而且最终该值被神奇的带到了CProfile的$insert中。

因此从用户输入（$_REQUEST）到带入到CProfile，参数profileIdx2未经过任何过滤器。

接下来jsrpc.php 的页面最后一行require_once了/include/page_footer.php

而/include/page_footer.php中调用了数据库操作，也就是CProfile::flush()方法，如下图所示：

该方法从CProfile::$insert中取出相应的值，并进行insertDB操作，此处没有过滤，通过遍历数组进行insertDB操作，因此总会遍历到我们的变量。

接下来，我们再来看insertDB操作

该操作的第四个参数又顺利的没有做任何过滤，最后带到了数据库进行查询 （DBexecute）。

我们再来看（DBexecute），文件位于/include/db.inc.php，发现是在本分的执行sql语句，因此我们的$_REQUEST[profileIdx2]成功的被送到了数据库并执行，也就是造成该漏洞的原因。

其实细心的读者会发现，带入数据库以前，许多变量都被zbx_dbstr这个函数过滤了，这个函数实际上就是mysql_real_escape_string，会对单引号双引号等特殊字符做转义。

最后不得不说的是，造成该漏洞真是需要开发人员编程时候的代码之间的各种“偶遇”，才能在层层过滤下都忘记过滤这个变量。

因此我们GET方法请求：

POST方法请求：

均可实现，如果配置允许的话COOKIE也是可以的。

0x03 影响的软件版本

目前已知受影响软件版本：2.0.x,2.2.x,2.4.x,2.5,3.0.x

0x04 相关案例

Zabbix 2.2.x, 3.0.x SQL 注入漏洞（latest.php）

点击“阅读原文”查看详细案例。

0x05 修复建议

（1）临时解决方案：

a.关闭guest访问权限，修改管理员账号为强口令。

b.对zabbix后台做访问控制，只允许指定IP访问zabbix-server后台。

（2）最佳修复方案：

升级目前最新版本的Zabbix系统（3.0.4）

0x06 总结

该漏洞需要登录，但是系统内置Guest帐号且默认为启用状态，因此攻击者可通过Guest帐号登录并进行攻击。该漏洞实际上是zabbix latest.php注入漏洞的另一种衍生攻击方式。

原创：青藤云安全