ECShop最新4.1.0前台免登录SQL注入0day漏洞披露与分析 – 作者:Xcheck

1618814839_607d277736cf632c97873.png!small?1618814839623

0x00 漏洞概述

影响版本:ecshop4.1.0及以下
是否需要身份认证:否,前台漏洞
漏洞类型:SQL注入
CNVD编号:CNVD-2020-58823,https://www.cnvd.org.cn/flaw/show/2454613
漏洞来源:xcheck代码安全检查
源码获取:https://www.ecshop.com/,登录注册下载,最新版本为4.1.1(已修复)。

0x01 漏洞详情

漏洞代码:/source/ecshop/delete_cart_goods.php,16行

1618814883_607d27a3b9800c6e7a490.png!small?1618814884822

$_POST变量直接传入sql语句进行拼接,再进入数据库查询,触发漏洞。

如果有对ecshop进行过代码审计的话,应该会知道在includes/safety.php存在个waf,但是在这个版本并没有生效,这里漏洞触发可以不进入这里的过滤防护逻辑

1618814913_607d27c1c7de447530924.png!small?1618814914368

本地搭建验证如下,配置默认是开了报错,线上的测试环境也是,不存在报错的话可以通过盲注验证。报错注入的截图证明如下。

1618814939_607d27db4327048c2106f.png!small?1618814939611

漏洞修复:对请求参数进行过滤。

1618814960_607d27f0aa978acf10869.png!small?1618814961015

0x02 注入漏洞利用分析

思路一:获取注入获取管理员密码md5

ecshop默认密码不加盐,所以可以直接注入找到ecs_admin_user表获取管理员密码的md5.

思路二:获取管理员session

如果管理员使用了较为复杂的密码,md5解不出来时,可以考虑获取session。即cookie中ECSCP_ID的值。
登录用户的session存在ecs_sessions表,但是只有sesskey。

1618814989_607d280d3f485b644c197.png!small?1618814990311

代码中登录成功后cookie设置:setcookie($this->session_name, $this->session_id . $this->gen_session_key($this->session_id), 0, $this->session_cookie_path, $this->session_cookie_domain, $this->session_cookie_secure, TRUE);.

其中$this->session_name就是ECSCP_ID, $this->session_id . $this->gen_session_key($this→session_id)就是最终cookie的值,数据库中sesskey对应的是$this->session_id,至于后半部分是通过gen_session_key这个函数生成。

1618815018_607d282abc5b9a86b8abc.png!small?1618815019050

后半部分gen_session_key通过ip和ROOT_PATH来确认,ip也在session表中可以找到,至于ROOT_PATH,可以通过猜测或者部分路径的报错拿到。最后拼凑到的,就是最终的cookie。

思路三: ecshop/api/client/includes/lib_api.php 写入shell

api/client 的访问需要登录,位于ecshop/api/client/includes/lib_api.php的API_UserLogin接口。这里登录是直接校验密码md5,也就是说当思路一解不出来时,这里也能用上密码的md5。

1618815045_607d2845ece33ac4a670a.png!small?1618815046915

登录成功后访问api接口,可以利用一个任意写入漏洞。触发点为upload_image函数,在API_AddBrand函数中被调用。

1618815066_607d285ad07285785f7b9.png!small?1618815067179

1618815082_607d286a614d61f9160df.png!small?1618815083698

最后登录成功后写入文件的payload为:

1618815109_607d2885d24f404a83788.png!small?1618815110208

最后getshell

ecshop后台能读写文件的地方,大多做了限制。现在找到能shell的地方,就是在利用smarty模板渲染来执行代码,可参考ecshop原来爆过的一个任意代码执行漏洞,这里简要概述下。

  1. 首先插入代码,在模板管理里找到邮件模板,修改为{str:{\$asd'];assert(base64_decode('ZmlsZV9wdXRfY29udGVudHMoJ3hjaGVjay5waHAnLCc8P3BocCBwaHBpbmZvKCk7Jyk7IA=='));//}x

1618815229_607d28fd14ca78e7a3b48.png!small?1618815229346

  1. 再回到管理密码找回页面,点击确定,即可触发。

1618815348_607d29747596fbee1c656.png!small?1618815348745

         分析如下:$template['template_content']为我们插入的数据。

1618815392_607d29a00fc13bdd55d85.png!small?1618815392537

跟进fetch函数,进入eval函数前还有个fetch_str函数,会对payload进行一些过滤,这里不展开细节。

1618815423_607d29bf97b209e33acbf.png!small?1618815424490

_eval函数将过滤后的字符串拿过来进行执行。由于是无回显,所以payload采用的是写文件的方式。

1618815450_607d29da049fbe54c1705.png!small?1618815450409

0x03 结束语

这个前台SQL注入较为简单,但是危害较高,只通过一些简单字符匹配规则去找类似这种漏洞的话,整个项目大概有三百多个,其中前台的风险大多被单双引号包裹且开了GPC防护,对xcheck来说仅需要加一点字符串比对处理即可筛选找出。

这个漏洞由xcheck检出,已第一时间上报CNVD,现在官网版本已经修复。本文仅限技术研究与讨论,严禁用于非法用途。

专注于代码安全 | 公众号:腾讯代码安全检查Xcheck

来源:freebuf.com 2021-04-19 14:59:29 by: Xcheck

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论