通达OA 11.5版本某处SQL注入漏洞复现分析

1、前言

2、某处注入漏洞复现分析

登录后抓包，直接请求POC，发现确实延时语句确实执行成功。

接下来我们分析下源码，通达OA采用了Zend加密，可以先利用SeayDzend工具进行批量解密。从请求的路径来看，入口文件在
general/appbuilder/web/index.php。分析index.php源码，发现appbuilder采用了Yii2框架。

跟进到166行，此处对Yii2进行了配置，配置在
general/appbuilder/web.php中，跟进到该文件，可以发现appbuilder被分为几个小模块

分析该漏洞路由，我们跟进到
appbuilder/modules/calendar/controllers/Calendarlist Controller.php，找到actionGetcallist方法。从257行开始，$_POST转码后直接传递到$data，其中的多个元素被赋值，并代入到get_list_data方法中。

跟进到
calendar/models/Calendar.php的get_list_data方法，63行开始我们发现，$begin_date、$end_date等可控字段被直接拼接到了SQL语句中，导致了SQL注入的发生。

3、一些有趣的问题

这个漏洞真的如同表面上这么简单么，后续通过继续分析入口文件index.php，我们发现了一些有趣的问题，下面我们一一解答。

3.1 全局addslashes的绕过？

之前分析过通达OA源码的同学会发现，文件中一旦包含了inc/session.php，会对GPC进行全局的addslashes转义。具体的包含流程如下：

session.php-> conn.php-> td_config.php-> common.inc.php

而在common.inc.php的99-147行，除了某些键值的POST请求，其他都要做addslashes处理。

而appbuilder/web/index.php中恰恰引入了inc/session.php，却依然没有阻止漏洞的发生。仔细分析源码，发现在文件最开始6-20行，$_GET和$_POST中的参数值被base64编码。

在138-151行，$_GET和$_POST中的值被解码。

而引入inc/session.php在25行，恰巧此时请求的参数值处于编码状态！因此，后续从该入口的所有请求GET、POST参数值都不受addslashes转义影响。

3.2 授权注入漏洞？

我们去掉上述POC中的Cookie字段，发起请求依然产生了延时，这证明SQL语句确实被执行，只是状态码变成了302。

我们继续分析index.php，查看用户登录权限控制的地方，跟进27行if条件，如果$_SESSION[“LOGIN_UID”]存在且不为空或者0，进入if语句。

68行为else语句，判断uri中是否有”/portal/”字符串，如果没有则设置header为302跳转。熟悉PHP的人应该都知道，即使程序中执行了header(location)，后续代码的逻辑还是会继续执行，因此该SQL注入漏洞可以未授权执行。

3.3 多个模块未授权？

index.php中除了用户权限判断外，还对模块权限进行了判断。具体可以从79行开始看，定义了$b_dir_priv默认为false，通过对uri进行分割，获取模块名称。

我们直接定位到120行的if语句，如果$b_dir_priv仍然为false，并且在

$config[“params”][“skip_module”]中，设置$b_dir_priv为true。

我们看看$config[“params”][“skip_module”]的定义，包含portal、hr、meeting等多个模块，上述模块可以被认为是跳过验证的模块，也就意味着如果在方法中没有做进一步验证，上述模块的所有方法都可以未授权访问，其中包含不少敏感的增删改查接口。

简单看了下未授权模块的一些方法，可以执行很多敏感操作，同时我们也找到一处未授权的SQL注入，建议使用该版本OA的用户及时升级。

4、安全产品解决方案

百度度御关WAF、高级威胁感知系统，以及智能安全一体化产品已支持该SQL注入漏洞的检测和拦截，有需要的用户可以访问anquan.baidu.com联系我们。