内容简介:当任务目标是一个wordpress站点的时候,是否让你感到过头大?wpscan扫了半天,却没有任何有利用价值的bug,这时候就拍拍屁股走人了?流行框架一般不会有什么太大的漏洞,顶多根据少有的特性接口找到一些可以利用的数据,比如用户的基础信息:ID、名称、邮箱等,为潜在的爆破登陆做轻微的贡献。NO,这时候更应该深入,越是扫不出的地方,越有可能发现有趣的点。而最容易出现非官方,有bug的地方就是插件、自定义插件、第三方功能了。
遇WordPress头大?让我们从插件入手!
当任务目标是一个wordpress站点的时候,是否让你感到过头大?wpscan扫了半天,却没有任何有利用价值的bug,这时候就拍拍屁股走人了?
流行框架一般不会有什么太大的漏洞,顶多根据少有的特性接口找到一些可以利用的数据,比如用户的基础信息:ID、名称、邮箱等,为潜在的爆破登陆做轻微的贡献。
NO,这时候更应该深入,越是扫不出的地方,越有可能发现有趣的点。而最容易出现非官方,有bug的地方就是插件、自定义插件、第三方功能了。
因此,在面对大型框架时,我们的入手目标就是“一般 工具 扫不出、普遍站点不一定有,根据管理员目的后来添加的,但混入站点拥有一定权限和功能的”漏洞点。
也就是去寻找笔者所戏称的“后入式BUG”。
寻找plugins的蛛丝马迹
总有人说,拿到一个目标是标准化框架,让人看着就觉得没什么容易下手测试的地方。其实测试的地方是有的,大佬和小白们的方式却略有不同。
1.工具扫描
使用工具扫描总是最轻松的,基础信息刺探、简单的资产挖掘,甚至某些心大未修复的捡漏、备份文件暴露,特殊路径挖掘等,都能靠扫描器就直接扫出来。但轻松是一方面,另一方面你应该也意识到了,使用工具拼的只是带宽和时间,你的任务入手时间,扫描持续时间,扫描完成程度,规则广泛程度,报告书写速度,都会影响“你与别人谁能拿到奖金”的结果。而初入安全行业,偷懒不进去不学习的人,都停步在了这里。
2.手工审计
扫描捡漏之余,一般才是大牛们开始发力的真正比武场。SRC排名靠前的师傅,据我认识的就有几个已经自己写出自动化开始做项目了。你用“开源扫描器+手工复测+疯狂写报告”跟他们拼?还是歇歇吧哈哈,他们早直接用SRC的API提交了,从SCAN->TEST->POC->GETSHELL->REPORT一条龙服务。
从前我不相信这个世界有龙,直到我看到了大佬们自己写的“日站一条龙”框架……而大佬们在抢走了第一波饭菜的时候,顺手也拿起勺子开始喝汤了。
事实说话,举例说明
大型开源框架很多,能使用插件的也挺多的。比如WordPress的站点这网上一搜一大把,那我们就拿WordPress举例说明吧。
首先随便找个WordPress的网站,我们就到网上搜一个随便看看吧。
按f12挂个黑页,哦不,按f12看看站点目前引入的文件,和现在的流量情况,找找API交互的endpoint以及现在直接能体现出来的error有没有可以利用的地方。
可以看见,这个站点使用了诸多的插件,某些插接因为太小众,并没被WPScan扫出来,即便扫出来了,或许规则库里也没有统计到有可利用的漏洞,这时候我们就可以找找这几个插件的源码着手审计。而审计之前,我们也可以在权限允许的页面,顺手测试一下这些插件的功能,说不定就有直观的能黑盒测试出来的bug呢?
可以看到,这个站点的PM功能(私信功能)出现了许多奇怪的error,看类型是xhr,流量中跟随输入拼写一直在递增。貌似是查询用户的?不如直接找到这个API,尝试手工测试。
可以看到,单单是黑盒测试,就发现此处API存在一个 SQL 注入点。
手工复测找到完美闭合方式后,调整速率再使用sqlmap确定一下,可喜可贺,确实找到一个注入点,类型Boolean & Time based。留好截图,组织一下语言,把前后发现、复测条件、payload全附上,一篇价值2k的高危漏洞报告就出炉啦!
这里在form里调用了javascript:autosuggest()来自动补全用户信息。
再看看补全用户信息怎么实现的,我们看看源码,果不其然,在这段代码中就存在一个教科书般的SQLinjection漏洞。
站点的开发在上线时使用了插件,却没经过严格审计,而选择了信任插件,实属失误。。
在刚刚的error信息中,隐约记得还看到了innerHtml()的调用,这可是容易出现xss的地方啊!当然,修复方式建议直接<?php die();?>了,也就不用考虑这个XSS了。。
年久失修遇见双管齐下
就在写文章的时候,看到上传图片都是直接传到CDN的图床了,直觉告诉我这里可能出现问题,那是不是图床的第三方SDK也会有洞呢?我们来找找看。
站点使用的是upyun-editor的上传代码,其中有个类似于demo的文件引起了我的注意。
这里看到代码,说不定可以造成反射XSS,那么我们直接POST到站点看看。
恩。。看来是正常解析了。但是Chrome下测试,会被xss defense的内部检查器拦截下来。。这可咋整。。
检查发现站点的返回还与源码本地测试的略有不同,并且既然有两个输入框,可不可以用组合方式绕过Chrome自带的XSS防护呢?
我们在第一个输入框填 <script>第2个编辑器的值=0;
第二个填 ;alert(1);//
测试一下?
打完收官~ 虽低危100元,挖到新姿势还有奖金,想想也足以。
总结
不管是做项目,还是企业内部测试,使用扫描器进行信息收集永远只是个开始,而主要精力应该放在加深对框架理解与功能测试跟进上。
框架是否有外来代码?是否使用三方插件?有没有其他子域?
没有挖不到的洞,只有不努力的黑客。
加油吧,各位少年~
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Spring Boot实战
[美]克雷格·沃斯 / 丁雪丰 / 人民邮电出版社 / 2016-9 / 59.00元
本书以Spring应用程序开发为中心,全面讲解如何运用Spring Boot提高效率,使应用程序的开发和管理更加轻松有趣。作者行文亲切流畅,以大量示例讲解了Spring Boot在各类情境中的应用,内容涵盖起步依赖、Spring Boot CLI、Groovy、Grails、Actuator。对于Spring Boot开发应用中较为繁琐的内容,附录奉上整理完毕的表格,一目了然,方便读者查阅。一起来看看 《Spring Boot实战》 这本书的介绍吧!