漏洞概要
关注数(24)
关注此漏洞
漏洞标题:Ucenter Home最新版SQL注入二处
提交时间:2014-07-25 14:16
修复时间:2014-10-23 14:18
公开时间:2014-10-23 14:18
漏洞类型:SQL注射漏洞
危害等级:高
自评Rank:20
漏洞状态:厂商已经确认
Tags标签:
无
漏洞详情
披露状态:
2014-07-25: 细节已通知厂商并且等待厂商处理中
2014-07-25: 厂商已经确认,细节仅向厂商公开
2014-07-28: 细节向第三方安全合作伙伴开放
2014-09-18: 细节向核心白帽子及相关领域专家公开
2014-09-28: 细节向普通白帽子公开
2014-10-08: 细节向实习白帽子公开
2014-10-23: 细节向公众公开
简要描述:
Ucenter Home最新版SQL注入二处
详细说明:
不知道这种情况算不算二次注入
先使payload进入数据库或者某一空间内,再次取出payload,然后进入SQL
这里第一步操作先使payload进入了一个数组中
然后第二步操作中会取出第一步中的payload,然后进入了SQL导致注入
整个过程跟二次注入一致,但是没有payload第一次没有进入SQL中
不知道这种算不算二次注入,暂且都叫sql注入吧
============================================================================
下面来看看这个漏洞。
在个人设置——隐私筛选——动态筛选
文件/source/cp_privacy.php
这里存在两处问题:
1、这里在更新类型筛选时
将我们key直接为过滤带入了$space['privacy']['filter_icon']中
2、这里在更新通知筛选时
将我们key直接为过滤带入了$space['privacy']['filter_note']中
然后再来看看回到动态筛选页面
这里会整理通知内容,以及获取应用名称:
文件/source/cp_privacy.php
在上述代码的开头可以看
这里的$space['privacy']['filter_icon']和$space['privacy']['filter_note']就是我们上面privacy2submit提交的内容
这里的key是直接传进来的
下面再整理通知和获取应用名称时,这里进入了uids和appids数组里面,然后再次进入了SQL语句,造成了SQL注入。
漏洞证明:
第一处SQL注入证明:
第一步:
首先我们更新通知筛选和类型筛选
这里进行通知筛选
在个人设置——隐私筛选——动态筛选:
提交一次,抓包,修改POST:
添加通知筛选:
privacy[filter_note][type|key]:
第二步:
再回到在个人设置——隐私筛选——动态筛选这里
此时会进行通知整理,然后出发我们的payload,看看结果:
第二处SQL注入证明:
同第一处操作一样,但是要注意的是,这里的类型筛选是privacy[filter_icon],而且此时这里的type必须是整数型。
看看提交的内容及结果:
修复方案:
漏洞回应
厂商回应:
危害等级:高
漏洞Rank:20
确认时间:2014-07-25 16:28
厂商回复:
uchome已经停止更新维护,感谢您对我们产品的关注
最新状态:
暂无