一、漏洞简介

用友NC是用友网络科技股份有限公司开发的一款大型企业数字化平台。它主要用于企业的财务核算、成本管理、资金管理、固定资产管理、应收应付管理等方面的工作，致力于帮助企业建立科学的财务管理体系，提高财务核算的准确性和效率。

用友NC 存在SQL注入漏洞，未授权的攻击者可以通过该漏洞获取数据库敏感信息。

二、影响版本

NC633、NC65

三、漏洞原理分析

漏洞主要因为complainbilldetail接口的pk_complaint参数未进行过滤，存在SQL注入。

首先定位到漏洞入口

nc.bs.ebvp.adviceorappeal.AppealrespController#complaindetail

在入口处设置断点，构造payload并进行发送，成功在断点处停下。同时可以看到，我们传入的载荷。

继续跟进该参数，直接传递到nc.impl.ebpur.adviceorappeal.service.AppealQueryServiceImpl#queryComplaintVOByPk函数，该函数接收两个参数，两个参数都是从http请求传递过来，未进行任何过滤。

紧接着又把pk传递给nc.pubimpl.srmsm.complaint.ComplaintMaintainServiceImpl#queryComplaintVOByPk，另一个参数不用理会，用不到。

接着把pk参数转换成字符串列表，传递给nc.impl.pubapp.pattern.data.bill.BillQuery#query(java.lang.String[])。

接下来就开始拼接sql语句了。这里的query函数，说明是一个查询语句。进行跟进

先判断参数长度是否为空，接着用nc.impl.pubapp.pattern.data.table.TableIDQueryCondition构造查询条件，后边就进行数据库中操作了。

主要的sql语句拼接就是在这个位置，该函数先把传递的字符串初始化给idList数组。

之后会调用build进行生成

可以看到，在buildInSql中直接把参数拼接进了sql语句。这里之所以两个处理函数，是为了应对多个where条件的情况。第二个参数field就是表列名，不同的模块，不同的表列名。这里不用理会第二个处理函数，因为sql注入的时候，直接用注释符把后边的语句注释掉了。

现在的sql语句虽然没有过滤就进行了拼接，还不能100%保证一定存在sql注入。还需要继续跟进，看看执行sql语句的时候，是否用来占位符查询。

跟进另一个Query函数，这里正是进入sql执行阶段。第一个红框把表列传递给build生成sql语句。第二个红框进行查询执行。

把前边where语句拼接进整个sql，用DataAccessUtils.query()进行查询。

同样没有进行任何过滤，也没有用占位符查询的方式。同样的，后边的sql语句不用理会，直接被注释掉了。

至此，已经可以确定存在SQL注入漏洞。

四、环境搭建

环境搭建部分，这里就不重复了，奇安信攻防社区有很详细的安装过程。直接参考即可。

传送门： (通过代码审计某友获取CNVD高危证书)[https://forum.butian.net/share/3058]

五、漏洞复现

http://192.168.45.148/ebvp/advorappcoll/complainbilldetail?pageId=login&pk_complaint=1'waitfor+delay+'0:0:10'--

六、总结

该SQL注入漏洞主要是因为系统未对pk_complaint参数进行任何过滤，导致sql注入漏洞。经过我的分析，这个接口很有可能是被作者忘记了，因为其他接口基本都采用占位符的方式进行查询，可以有效的防治SQL注入漏洞。