漏洞概要 关注数(24) 关注此漏洞
缺陷编号：wooyun-2014-084078
漏洞标题：金和OA SQL注入之2
相关厂商：金和软件
漏洞作者： 疯狂的dabing
提交时间：2014-12-30 13:06
修复时间：2015-03-30 13:08
公开时间：2015-03-30 13:08
漏洞类型：SQL注射漏洞
危害等级：高
自评Rank：15
漏洞状态：未联系到厂商或者厂商积极忽略
漏洞来源： http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]
Tags标签： 无
漏洞详情
披露状态：
2014-12-30： 积极联系厂商并且等待厂商认领中，细节不对外公开
2015-03-30： 厂商已经主动忽略漏洞，细节向公众公开
简要描述：
我司最近在内网部署了一套OA，正式上线前领导让先测下安全性，被人爆菊了就囧了。。黑盒一番，这次是个登录后的SQL注入，不过注入点还是很有意思的。
所测版本为C6V3,官网demo也存在该问题，貌似V2不存在。
详细说明：
因为是登录后的注入，因此没法给出更多实例，当然审核和CERT验证人员可以从第一个注入中提供的几个实例中，dump数据，然后再去验证是否存在。
./sqlmap.py -u http://oa.inofa.com/C6/Jhsoft.Web.login/AjaxForLogin.aspx --data="type=login&loginCode=admin=&pwd=123" -p loginCode --tamper base64encode.py -D C6 -T Users -C loginCode,PassWord --dump
现在只提供一个帐号供参考：
http://oa.inofa.com/
帐号：gdsw010
密码：20060108
注意数据库中的密码是使用sha1加密的。
注入点就在新闻搜索的地方（见第一张图片），不过这个地方也是在前端做了过滤，特别恶心，没法直接输入验证。
整个参数传输也是采用base64编码，然后解码后程序自己处理参数。在参数末尾有个非常诡异&h还不能去掉，目测是因为程序在后台是以&作为分隔的。
漏洞证明：
搜索39，得到两篇新闻。
下面是burp抓到的数据。
然后解码。
可以看到<MessageTitle ftype='input'>39</MessageTitle>中的39就是注入点。
不过这里先是类似伪静态的注入，然后再用base64编码传输，导致sqlmap没法用，只好写个中转脚本跑一下。
中转脚本就像exp，所以不上代码贴图了。。
直接访问看看效果：
跟搜索结果一直，证明可以使用。
放到sqlmap里面跑一圈。
sqlmap已经识别出搜索注入了，剩下就跑吧。
C6的数据库结构在百度文库有一份-，-我就说到这了。。
修复方案：
不要依赖base64编码，这只能提高攻击门槛不能杜绝安全漏洞。
不要拼接sql语句。
版权声明：转载请注明来源 疯狂的dabing@乌云
漏洞回应
厂商回应：
未能联系到厂商或者厂商积极拒绝