从哪里开始SRC之旅
Q:你为什么要在SRC挖掘漏洞?
A:我觉得有3个理由:
1.SRC是一座桥梁,可以让我们认识很多志同道合的朋友;
2.提高自己的技术;
3.具有一定的收入,这是SRC对于白帽子最直接的福利了。
Q:如何开始SRC之旅?
A:个人觉得,首先应该选定一个SRC平台,投入一定的空余时间和精力分析该SRC的相关业务与系统,以及这些系统出现过哪些安全问题(这一点需要我们去收集)。
Q:很多人不能坚持下去的原因是什么?
A:主要有2个原因:
1.学习工作任务重,没有时间;
2.遇到一些挫折可能就放弃了,比如前期没有挖到高中危害的漏洞。
Q:那么如何来解决你说的这两个问题呢?
A:对于时间,只能靠自己挤出业余时间。对于前期不能在SRC挖到高中危害漏洞的原因,我们可以去补天、漏洞盒子等漏洞平台参与一些普通厂商的漏洞挖掘。最重要的是,不要怕受打击,有可能一个月没有挖到一个漏洞这都是正常的。
Q:如何开始挖掘漏洞?
A:同样分2点:
1.明白什么是漏洞,什么是Bug。SRC最害怕的是白帽子将一些Bug当作安全漏洞来提交。一句话总结漏洞:会造成机密性、完整性、可用性被破坏的就可以称之为漏洞;
2.要理解漏洞原理,我与一些初入SRC的白帽子交流过,他们喜欢问的一个问题就是"如何挖掘漏洞",其实当你了解了一个漏洞的原理,你就能很好地去挖掘该类型的漏洞。举个例子:如果你明白SQL注入漏洞的原理,你就能很清楚的知道SQL注入产生的位置,那么只要在业务系统中找到这些位置进行尝试,就有可能找到漏洞。
如何挖SRC的漏洞
上面说了很多废话,那么接下来就聊一聊,我是如何进行漏洞挖掘的。
SRC的漏洞挖掘与漏洞平台的众测是有区别的,很多时候众测比拼的是手速,而SRC考验的是认真与坚持。我一直相信认真做好下面的几步,大家都是可以成功挖掘到漏洞的!
第一步:信息收集
信息收集阶段,不同的人有不同的收集办法,对我而言,我喜欢一个主域名一个文件:domain.xlsx,文件等内容如下
子域名 IP 端口&服务 账号密码 历史漏洞
xxxx xxx xxx&xxxx xxxx/xxxx xxxx
# 如果单IP对应多个域名,不要重复进行端口扫描,费时费力还没有效果;
# IP段的扫描,要注意先判断存活再进行精准识别;
# 账号密码:可以是你收集的账号密码、暴力破解得到的账号密码,自己注册的账号密码(准备1-2个小号是有必要的);
# 出现过哪些漏洞,这些源自你的收集;
# 存储手段不一定是表格,个人更推荐使用数据库,写一个简易的SRC信息收集系统;
对于信息收集,选择一个好的搜索引擎是比较重要的,国内站点的话,只使用bing与baidu应该就已经能够满足我们的需求了;
主域名收集
一般都通过SRC的公告去寻找,公告会告知该SRC平台收哪些域名下的漏洞;还可以去主站的网站地图sitemap.html或者about页面查看。
子域名收集
收集好主域名以后,我们就需要收集子域名,收集子域名的文章很多,我这里不过多的介绍,大家可以自行百度。
域名信息获取
拿到子域名,我们一般会做以下几个操作
1.了解网站框架与CMS。这里一般针对的是struts2、jboss或者一些通用CMS等,我们可以直接利用一些已知漏洞进行测试;
2.识别waf。识别waf有两点需要注意:其一是waf的部署方式,有些waf以cname进行部署,如果我们拿到了真实IP也许就绕过了waf;其二是waf的版本信息,可以看看网上是否有公开的绕过方式;
3.获取域名对应的IP。这里主要是拿到真实IP,一般会遇到的是cdn、f5等。
敏感页面收集
robtos.txt、phpinfo.php等;
后台登录页面;
还有一些页面可能直接泄漏敏感信息。
Port&Server
对于端口这块,我曾经写过一篇端口渗透总结,地址如下:
http://www.91ri.org/15441.html
感兴趣的可以看一下。
账户信息收集
账号的信息收集:一些特殊页面会泄漏账号信息、常见账号、默认账号、账号的规律(这个一般针对的是邮箱、和员工号),还有就是社工库的泄漏;
账号的暴力破解:一般我们都是通过一些字典,当然不同的系统可能需要的字典不一样,需要根据场景进行构造;
第二步:漏洞挖掘
漏洞挖掘在我看来分为两种思路:
1.已知攻击方式直接进行攻击,如:SQL注入、XSS、CSRF、SSRF等;
2.需要自己对数据包进行分析,如:支付漏洞、密码找回等;
对于上述的两种思路,衍生出3种攻击方式:纯扫描器、手工结合扫描器、纯手工。我的建议是能使用工具的尽量别手工。
常规漏洞
对于常规漏洞,很多时候我们是可以利用扫描器的结果进行分析的,特别是当网站的目录结构比较复杂时;当然挖掘常规漏洞大多时候不需要过多的技巧,只需要明白漏洞的原理以及猥琐的思路,如果一定要说需要什么,那就是认真、仔细与耐心。
逻辑漏洞
对于逻辑漏洞,我们在开始之初就应该注重分析业务系统的功能,以及整个业务流程与逻辑,当我们明白了整个系统的结构,我们便能很轻松的找到脆弱点,然后针对这些脆弱点进行安全测试就好了。
还是用我曾经的举过的例子:某电商系统可能存在的漏洞(这里不讨论web server可能出现的问题)
首先进入这么一个系统:主要是商品的展示(这里有一个搜索,可以考虑SQL注入、反射XSS);
然后注册账户:批量注册(恶意)、任意手机号/邮箱注册、注册时用户名暴力破解、注册的信息存在SQL注入、存储XSS等等;
登录账户:暴力破解账号密码(包括一些验证码的绕过)、登录时的SQL注入等等
忘记密码:忘记密码的一大堆逻辑漏洞
登录以后的个人中心:修改个人信息(XSS、SQL注入),上传个人头像(直接上传shell、ssrf)等
对物品的操作:加入收藏与添加关注很容易存在CSRF
购物流程:一元购物、支付成功请求的并发,使用优惠卷的逻辑问题,打折的逻辑问题,订单备注、发票信息、收获信息的XSS、SQL注入等等;
订单结束:退货退款时的并发或多次退货、评价订单的XSS、SQL注入等等
与商家的聊天:聊天内容的XSS、聊天时的社工
还有就是每一个可控字段的越权操作:包括收货地址、个人信息、订单信息、发票信息等等
……也许还有很多等着去总结
第三步:漏洞整理
建议梳理一个系统出现过哪些漏洞,因为这个系统可能是同一个项目组开发的,这样做对于后期更新的模块,我们便可达到举一反三。
第四步:自我约束
不做一些违规操作是为了更好地保护自:
不对系统的数据进行插入、修改、删除等操作;
不要获取过多的敏感信息,那是违法的;
不要尝试拒绝服务攻击,会给对应的业务造成损失;
不要将一些未修复的漏洞在博客等公开平台进行公开;
第五步:合理沟通
沟通一般是指我们与审核和运营人员的沟通,我相信SRC会坚定维护白帽子的合法权益,当然前提是合理的测试。当双方对一些漏洞产生分歧的时候,建议可以以一种友好的态度来处理问题。
写在最后:本文基本全是一些自己的经验,没有太多技术性的东西,请大牛轻轻喷!