| 关键词: userid string salt yunyecms SQL cookie 函数 payload 39 后台 |
前言某天挖完洞闲来无事浏览CNVD看到某CMS更新了一溜的SQL注入,似乎起了强迫症,于是准备分析学习记录一下,顺便填充一下工作内容(哈哈题外话请忽略),其实是个小众CMS,分析起来也不算难,后台的比较简单,主要看前台的。 版本:2.0.2PS:官方已跟新至了最新版本,且在最新版修复了以下漏洞。该文仅作学习和交流。 SQL注入1-后台de***.php对应CNVD编号:CNVD-2020-12871 漏洞出现在在后台文件de***.php中,de***_add函数对GET和POST参数先进行了是否empty判断,最终将传入的几个参数传给了edit_admin_department。 ![]() 跟入edit_admin_department,对参数依次进行了处理,但是发现只有$departmentname,$olddepartmentname进行了usafestr安全过滤,漏网的$id拼接到了sql语句中执行。 ![]() 最终导致了SQL注入。 ![]() SQL注入二-lo***.php这原本是在后台目录下但其实也是一个不需要验证后台登录的前台注入。 对后台文件的功能点分析。在lo***.php中功能adminlogin先获取了登陆者的ip,该ip参数的传参过程为getip()->$logiparr->encode->$logipstr然后拼接到$sql语句中lastip,中间并未进行其他过滤。 ![]() 再来查看getip() 该函数返回获取的ip,而HTTP_X_FORWARDED_FOR为我们可控的http头部。 ![]() SQL注入3-roe.php文件role.php同理对参数id没有进行过滤只进行了是否empty判断,最终在edit_admin_role中进行SQL查询。 ![]() ![]() 根据查询结果返回存在或not exit是一个盲注直接丢入sqlmap秒出结果。 ![]() 同类问题的还有yunyecmsmodel.php等文件自行发现,直接附上结果。 ![]() 接着我们继续来看前台的。 前台sql注入问题出现在前台me***.php文件中,自定义表单customform中的userid从cookie中获取,截取一段数据包可以看到cookie的userid如下: ![]() 经过了加密处理,根据解密算法yunyecms_strdecode可以在corefun.php找到对应的加解密算法 因为cookie里的userid可控因此我们根据算法流程我们可以在cookie中伪造userid值。还是用刚刚以上截取的userid测试。 可以看到真实的userid为9。构造一个SQL注入,生成如下payload: YmM0OWM5ZWY1ODk5ZGRkNzM0T1NjZ1lXNWtJSE5zWldWd0tEVXA4ZDdlNzk5NTliNDQyYTI1ZDE0ZWUzODZmZDI4MzY5OTM0YQ== payload生成代码front-test.php为: 继续追溯可控的userid,可以看到userid经过步骤3->4->5传递到了pagelist函数中 ![]() 跟入pagelist函数,将$where拼接到了sql查询语句中$sqlcnt,然后交给了前几次SQL注入都出现的SQL查询函数GetCount中。 详细查看下该函数,直接进行了sql查询。 附上截图 ![]() 手工有点麻烦,又想丢入sqlmap怎么办,由于userid经过了加密和编码处理,于是根据算法流程写一个tamper就可以很好的解决了, ![]() 对应tamper的的脚本为 yunyecms_front_sqli_tamp.py 搞定完事~ |
| 本文出处: https://www.toutiao.com/a6800737330278695431/ |
|
声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|