logo头像

黑客的本质就是白嫖

zzcms CVE复现(中)

zzcms CVE复现(上)

CVE-2018-17412

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17412
poc URL https://github.com/seedis/zzcms/blob/master/README.md
漏洞位置:user/logincheck.php,影响版本:zzcms8.3
zzcms_24.png
可以看到这里又是直接将ip插入到了查询语句中,而在上面我们知道ip是通过getip这个函数得到的,我们可以通过三种方式来伪造ip
zzcms_25.png
成功造成时延

CVE-2018-17413

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17413
poc URL https://github.com/seedis/zzcms-xss/blob/master/README.md
漏洞位置:uploadimg_form.php,影响版本:zzcms8.3
zzcms_26.png
一个反射型XSS,说实话这个洞感觉好鸡肋啊,这样来说下面那个参数不是也能XSS
zzcms_27.png
zzcms_28.png
果然两个参数都存在XSS

1
**payload:uploadimg_form.php?noshuiyin="><script>alert(1)</script>"&imgid="><script>alert(2)</script>"**

CVE-2018-17414

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17414
poc URL https://github.com/seedis/zzcms/blob/master/SQL%20injection.md
漏洞位置:user/jobmanage.php,影响版本:zzcms8.3
zzcms_29.png
可以看到bigclass参数没有经过任何过滤就插入到了查询语句中,从而导致了存在SQL注入的风险
zzcms_30.png
一开始对着那篇文章复现老是失败,最后把提交方式换成了GETpayload换成了?bigclass=1%27%20or%20if(length(user())%3E0,sleep(5),0)%23才成功,不应该啊,难道那个利用过程不是原作者写的吗,为啥会复现不出来

CVE-2018-17415

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17415
poc URL https://github.com/seedis/zzcms/blob/master/SQL%20injection%20in%20zs_elite.php.md
漏洞位置:user/zs_elite.php,影响版本:zzcms8.3
zzcms_31.png
zzcms_32.png
同样是没有对参数进行任何处理就将其插入到查询语句中导致的SQL注入
zzcms_33.png
这里又有一个坑,怎么这些CVE的复现都写的这么简单!!!
坑在这里,第121行的代码会判断第二列结果是不是本人,不是的话就输出非法操作,我一开始用的是别人的名字,怪不得一直都测试失败,最后把payload里面第二列换成自己的注册用户名才成功
payload:?id=21’+union+select+1,’aaaa’,user(),4,5%23&page=1

CVE-2018-17416

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17416
poc URL https://github.com/seedis/zzcms/blob/master/SQL%20injection%20in%20%20addclass.md
漏洞位置:admin/adclass.php,影响版本:zzcms8.3
zzcms_34.png
还是没有过滤的问题,甚至参数都和上面的某个一样
通过\$_REQUEST传入的参数直接被插入到SQL语句中,导致了SQL注入
zzcms_35.png
成功执行SQL语句

CVE-2018-17797

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17797
poc URL https://github.com/seedis/zzcms/blob/master/arbitrary_file_deletion1.md
漏洞位置:user/zssave.php,影响版本:zzcms8.3
zzcms_36.png
又是同一个任意文件删除,只不过地点不同,原理和上面的一样,传入的oldimg参数没有进行过滤,代码直接将其删除了,这样可以构造参数,达到删除任意文件的效果
zzcms_37.png
zzcms_38.png
zzcms_39.png
成功删除

CVE-2018-17798

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-17798
poc URL https://github.com/seedis/zzcms/blob/master/arbitrary_file_deletion2.md
漏洞位置:user/ztconfig.php,影响版本:zzcms8.3
zzcms_40.png
同样的任意文件删除,这次出现在用户展厅页面处,更新网站banner时会将旧banner图片删除,加上没有对图片名进行任何处理,从而引发漏洞
zzcms_41.png
zzcms_42.png
删除成功

CVE-2018-18787

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18787
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:zs/zs.php,影响版本:zzcms8.3
zzcms_43.png
zzcms_44.png
变量$px直接使用了请求\$_COOKIE[‘pxzs’]的值,没有任何其他处理,这样可以构造payload进行SQL注入
zzcms_45.png
注入成功

CVE-2018-18791

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18791
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:zs/search.php,影响版本:zzcms8.3
zzcms_46.png
zzcms_47.png
CVE-2018-18787一样的成因,一样的利用方式,这里就不再重复演示一遍了

CVE-2018-18786

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18786
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:ajax/zs.php,影响版本:zzcms8.3
zzcms_48.png
zzcms_49.png
还是和CVE-2018-18787一样的成因以及利用方式,我在想难道大佬们用同一种方式就可以拿7、8CVE吗?之后还有好几个连号的CVE,不会都是同样的漏洞吧...

CVE-2018-18792

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18792
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:zs/zs_list.php,影响版本:zzcms8.3
zzcms_50.png
zzcms_51.png
连续四个了,虽然这里CVE编号不是连着的,但是确实应该是同一个人一起交的,因为其他几个的复现也被他写在一起了,我这里写的顺序是按照他写的顺序来的

CVE-2018-18785

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18785
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:zs/subzs.php,影响版本:zzcms8.3
漏洞的源点在zs/subzs.php的函数showcookiezs()中,直接使用了请求中的\$_COOKIE[‘zzcmscpid’]
zzcms_52.png
而在zs/label.phpfixed()函数中调用了showcookiezs()函数
zzcms_54.png
fixed()函数又在同一个文件的showlabel()函数中被调用
zzcms_55.png
最后在zs/search.php文件中被调用,而这里也是发现漏洞的人找到的需要使用到cookie的地方
zzcms_56.png
zzcms_57.png

这样我们需要在zs/search.php页面构造一个cookie,在代码中我们可以看到对空格以及delete进行了过滤,我们可以使用0a代替空格来进行绕过
zzcms_58.png
成功得到当前数据库用户名

CVE-2018-18788

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18788
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:admin/classmanage.php,影响版本:zzcms8.3
zzcms_59.png
漏洞出现在函数showtag中,其中没有对\$_SESSION[‘tablename’]没有任何过滤,而该参数的值在文件的开头直接由GET传入的tablename赋予
zzcms_60.png
构造payload
zzcms_61.png
得到数据库用户名

CVE-2018-18790

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18790
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:admin/special_add.php,影响版本:zzcms8.3
漏洞在文件的133行处,直接将传入的zxbigclassid合并到SQL语句中执行
zzcms_62.png
构造payload
zzcms_63.png
成功,不过感觉这个和上面的那个漏洞都稍稍有些鸡肋,毕竟都要有管理员权限了才能进入到这个页面,既然有管理员权限了,以各位师傅的实力,getshell还是没有任何问题的吧…

CVE-2018-18784

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18784
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:admin/tagmanage.php,影响版本:zzcms8.3
zzcms_64.png
zzcms_65.png
和上面的几个如出一辙,参数直接插入至SQL语句中
zzcms_66.png
仍然是需要有管理员权限,略微鸡肋

CVE-2018-18789

CVE URL http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18789
poc URL https://github.com/qiubaoyang/CVEs/blob/master/zzcms/zzcms.md
漏洞位置:zt/top.php,影响版本:zzcms8.3
在文件的第四五行存在SQL注入,稍微构造一下即可绕过
zzcms_67.png
而在zt/news.php文件中引用了本文件,所以目标文件存在SQL注入
zzcms_68.png
但是这个出现在HOST中的漏洞暂时复现不出来,一改HOST我这边就出现400错误,等解决了这个问题之后再复现这个和上面一个一样的漏洞吧
找到了一个差不多的问题解决方案,但是看起来貌似没办法解决,链接

评论系统未开启,无法评论!