记录一次漏洞挖掘到恶意攻击的精彩实战测试

文章转自freebuf,作者Ka1ier

前言

上次的那篇文章《一名代码审计新手的实战经历与感悟》得到了不少读者的支持,也得到了freebuf这个平台的肯定,这给了我这个菜的不能再菜的小菜鸟很大的信心。但是,不足之处还是很多,比如文章中出现的技术写得不够深入等等(这毕竟和个人实力挂钩的)因此,我决定尽我所能,尽量的写深入一点,每次写文章都深入一点,总有一天会深到很深的点。

本篇文章主要讲述我在zzcms8.2中挖掘到的漏洞,freebuf上已经有大佬写了这个cms的代码审计,当然,其他的平台也有人写了。所以,我既然写了,那么肯定是与他们的文章有所不同,漏洞也不同,攻击方法也不同,让读者读有所获。(新手可以考虑认真看看,后半部分有对于新手来说非常精彩的攻击演示)

漏洞集合

目录跳转读取敏感信息

在zzcms8.2/baojia/baojia.php的第四行,引用了zzcms8.2/inc/top.php这个文件,如图:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第1张图片

我当时追踪了一下这个文件,发现这个文件在引用的时候,首先就进行了if逻辑判断,而if逻辑判断中,又有可控变量。因此,我当时咋一看的时候,就很怀疑这里,感觉这里总可能存在一些问题。如图:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第2张图片

于是,我就打开网页看了一下,顺便抓个包瞧瞧。结果一看,哎,有点意思,代码是如果接受post请求,那么就执行跳转操作。而我们主动发送的请求是get,那就说明这个漏洞黑盒是百分之八九十测不出来的。黑盒又不知道这里居然还可能有post请求,就算测试post请求,也不知道参数是什么,因为前端压根没有这里的参数。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第3张图片


记录一次漏洞挖掘到恶意攻击的精彩实战测试_第4张图片

在我的上一篇文章中,我也有个感觉黑盒测不出来的漏洞,但是评论区大佬有人留言说黑盒能测出来,我仔细想了想,的确也有可能,因为当时那个漏洞前端能找到参数。

可是,这里就不一样了,无法猜测。莫名其妙的我就对白盒有了点小自豪,哈哈。回归主题,既然服务器端接收post请求,那么我就将get请求包利用burpsuite改造成post请求包。

将get请求包的数据格式以及内容改成post之后,我先尝试了构造xss,但是经过几次尝试,发现<">被html编码,单引号被转义。这就很尴尬了。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第5张图片

于是转换思路,既然是跳转,那么能不能跳转到敏感文件?或者跳转到远程文件呢?如果要按跳转思路,那么必须要进行截断。而在目录跳转中,问号伪截断比较通用,不受版本限制。

如图,我构造了这样的post请求包:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第6张图片

由于进行了伪截断,所以我这里执行的跳转就是跳转到服务器根目录,读取我本地的服务器根目录敏感信息:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第7张图片

我不清楚真实的网站根目录下是否也会存在这样的漏洞,但是,如果存在,那么危害还是挺大的。

比如,目标网站有cdn,但是你根据这个漏洞就可直接发现目标网站的真实IP,在本地进行域名和IP绑定后,就可以直接绕过cdn。

逻辑漏洞导致个人敏感信息泄漏

在zzcms8.2/baojia/baojiaadd.php的183-213行中,如果在用户的cookie中获取到用户名,那么将会提取出该用户名的个人信息,回显到浏览器页面。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第8张图片

比如公司名(这个感觉不重要),真实姓名,手机号码,emai。后面这三个信息我个人感觉是很重要的。会利用的人能利用出各种花样,这里我们只交流技术,不谈那些非法利用,因此这里如何利用这些信息我就不写了。

下图是我回显出的测试信息:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第9张图片

漏洞复现的方法非常简单,只要你设置COOKIE的UserName为数据库中真实存在的用户名,那么就会得到该用户的这些信息。

下图,浏览器中的cookie信息

下图,该王二狗用户在我的数据库中真实存在:

为了更加严谨一点的证明这个漏洞,我又注册了一个test2用户,并且注销了test2用户的登录。然后,构造请求包:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第10张图片

成功获得test2用户的敏感信息:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第11张图片

前提是我数据库中存在注册过的test2用户:

设计缺陷漏洞+CSRF=累死管理员并且让网站业务无法正常运行!(前方高能)

唉,本来是挖漏洞的,结果边挖漏洞,边给人改BUG。。。

这里插入的字段数据库中根本没有,导致发布功能压根无法实现,原因就是classid,被错写成了classzm。。。想挖这的漏洞,还得给他先改好BUG。。。帮助这个cms实现功能,我才好测试功能是否有漏洞利用。。。

所以,我个人是不建议新手费劲心思来挖这套cms,因为还有其他地方的功能存在错误,比如点击目录跳转的链接会显示“该文件不存在”,原因是程序员的跳转路径写错了。。又比如验证码压根不显示,为了方便测试,我只能注释掉检验验证码是否正确的代码。。所以,对于这套cms,新手随便挖几个洞就可以了,代码能力不强的要想练习改BUG技能,可以认真对待这套CMS。

言归正传,在对baojiaadd.php的测试中,我发现同一用户可以反复的发布报价信息,虽然发布报价信息需要得到管理员的审核,但是并没有对发布报价信息的用户做出数量限制或者其他的限制(普通验证码在一些大佬眼中可以直接利用机器学习识别的,我这里由于验证码的功能并没有实现,所以我就直接后台注释了验证码,在此前提下,有了后面的攻击实验),那么这就给“调皮”的用户留下可乘之机。

比如,我大量的发送具有迷惑性质的报价信息,让这些信息存入数据库,并且让读取这些信息的审核人员无法分辨是否是真实用户,那么这个漏洞就完全可以严重影响该网站的业务。所以,我给这个漏洞的评价是“高危”

漏洞出现的文件在zzcms8.2/baojia/baojiaadd.php中的183-242行以及274-313行。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第12张图片

我图片中没截取到的代码部分,是我觉得不影响理解漏洞,利用漏洞,所以就没截取。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第13张图片

上面两幅图实际上是我说的第二个漏洞,逻辑漏洞,但是当时只能读取用户私人敏感信息,在这里,因为我写的exp顺便就读取了个人敏感信息,需要用到那个逻辑漏洞的判断逻辑,所以我就截取了,方便大家阅读。而且之所以用到这个漏洞,是因为正规网站不会让游客发帖,而这里貌似是可以的(我没刻意去追踪不伪造cookie能否发帖的文件,感兴趣的读者可以自己尝试),为了保险起见,我就当作伪造cookie才能发帖。

下面两幅图是服务器端的处理逻辑

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第14张图片


记录一次漏洞挖掘到恶意攻击的精彩实战测试_第15张图片

最后,附上我写的伪造数据包之“洪水攻击”exp脚本,第一次写exp,写得不好多多见谅!功能就是根据我们想伪造数据包的个数,进行个人信息伪造,同时打印返回包(返回包中能看到逻辑漏洞中的敏感信息,我没写正则,所以读者可以自己改造)

exp脚本位置:

简单说明一下,我写的这个exp只是雏形,如果你想伪造的更像,更难以排查,更难以被审核人员过滤,那么我脚本中的那些变量,list,你可以加以改造,增加他们的数量以及不同的值,利用暴力破解的思路组合成新的个人信息,就像生成新的字典那样。

exp脚本攻击演示:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第16张图片

输入数字后,就会一直发送数据包,直到发送5个为止,会出现提示结束的信息。这里可以在返回的html代码中找到逻辑漏洞的敏感信息,用正则能匹配出来,我脚本中没写。。。懒了。。。感兴趣自己写吧。

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第17张图片

为了证明我们的攻击是有效的,我下面提供我的数据库截图:

记录一次漏洞挖掘到恶意攻击的精彩实战测试_第18张图片

像这里的用户信息,都可以通过改造我的exp或者读者自己写exp来实现。注意看我这里伪造的地址,电话,邮箱,是不是很真实?其他的值也都可以做到这种地步,我这个exp只是提供思路,进行简单的攻击演示。

总的来说,我觉得这个漏洞应该属于设计上的缺陷吧,不知道读者是怎么定义这个漏洞的。


另外,我一开始就觉得这里还有有CSRF漏洞,因为按道理来说,进行这类操作最好都要先token验证一下,可是这里并没有验证。在说点题外话,在我我进行CSRF页面构造的时候,遇到一个urf8编码的坑,导致我一度以为这里引用了token机制,但是怎么看前端源码,服务器源码都没找到token机制。无意之间在html中看到自己写的中文变成了乱码,才忽然想到可能是编码问题导致我CSRF总是失败。于是我改了自己CSRF利用页面的源码,果断成功!

下面是我CSRF攻击页面的源码:


综上所述,攻击思路就是:在访问流量比较大的网站挂上有CSRF攻击的伪造网页(可以做的逼真一点,我这里并不逼真),或者想其他方法引诱大流量的互联网网民来到你这个CSRF攻击页面,诱导他们点击触发CSRF攻击的按钮,让所有访问这个大流量网站的人亦或是访问这个CSRF页面的人,都去浏览zzcms这个站并且发布报价信息。同时,自己在本地利用脚本,对目标进行恶意发布报价的“洪水攻击”(不知道怎么形容,就这样用洪水攻击形容了)来掩盖正常用户的正常发布报价的业务请求,同时也要能够尽可能的迷惑审核报价信息的管理人员,让其无法轻易利用脚本或者过滤机制分辨哪种报价信息是真实用户的业务请求,哪种报价信息是攻击者恶意伪造的。


记录一次漏洞挖掘到恶意攻击的精彩实战测试_第19张图片

只要有用户进入我们这个CSRF页面,便会自动生成伪造信息。只要用户点击我们这个CSRF页面的小电影“开始播放”按钮,那么就会向zzcms站发送一次请求,报价信息便会存入zzcms的数据库中,混淆其他的真实数据,影响网站业务,累死负责审核信息的管理员~

看下图,伪造的信息成功进入了数据库:

我点击了两次CSRF页面的播放按钮,所以就生成了两条不同的数据。由于点击完,还会再次刷新到此CSRF页面,若用户第一次点击不明所以,还有可能再点击一次。那么在流量非常大的情况下,就等于将非常大的流量放大两到三倍去攻击zzcms站点。可以说,很恐怖了。

如果想最大限度的进行DDos攻击,那么还得补充相关知识,比如,什么情况下服务器解析最慢?我这里只提供思路。。技术有限。。

总的来说,这思路结合了DDos攻击、无线网干扰中的“洪水攻击”思路,同时结合一些欺骗的艺术以及利用网站的逻辑漏洞/设计缺陷来完成的一次精彩攻击。(尽管我伪造的页面很简陋,但是也不失为一次精彩的攻击,不是吗?)

你可能感兴趣的:(记录一次漏洞挖掘到恶意攻击的精彩实战测试)