从实战中学习漏洞挖掘与渗透测试流程

0x01 前言

作为一个职业又非职业性的漏洞挖掘者，除工作内做渗透和挖洞，其它挖洞基本上都是为了写公众号，并没有很专注的去了解职业SRC，清晰的记得有一次，挖到的一个在线商城漏洞，根据特征找到了存活站点一千多个，独立IP几百个，上交CNVD或一些广泛收录通用型漏洞的平台也可以换马内，但是我最后还是交了公益，现在有点后悔哈哈

而且我自己在正常漏洞挖掘过程中，专注状态下，并不对单一站点或一两个漏洞去写，因为觉得没有什么成就感，而是通过完整的渗透测试流程，对企业进行域名，端口，备案，APP，小程序，公众号等进行信息收集，收集信息越多，拿到漏洞概率越大，漏洞数量越多，我这里画了一个思维导图，仅供各位师傅参考

    以上思维导图仅供参考，细化分支不进行拓展，因为网络安全没有固定套路，每个人打法不同，思路也不相同，关于思路技术可留言区进行留言或加好友交流

* 文中所展示的过程、平台、方法仅为个人观点模拟，请勿非法操作，后果自负

0x02 测试流程

**1. 信息收集阶段**   - 概述信息收集的方法和工具   - 收集到的关键信息总结**2. 漏洞挖掘过程**   2.1 神奇的纵向轰炸绕过       - 描述纵向轰炸技术及其绕过策略   2.2 奇妙的功能越权       - 分析功能越权漏洞及其影响   2.3 失败的OSS接管尝试       - 讨论OSS接管的挑战和失败原因   2.4 运气极好的shiro反序列化       - 详细说明shiro反序列化漏洞的发现和利用   2.5 账户登录授权别样绕过       - 探索账户登录授权的非传统绕过技巧   2.6 OSS接管及Spring Boot Actuator未授权访问       - 揭示通过Spring Boot Actuator实现的未授权访问和OSS接管

信息收集阶段

此处拿到目标单位为targetzgs.com的域名及企业名称(域名已进行虚化)、某股份公司，通过域名及icp备案信息查询到其企业还存在其它域名

而后又通过fofa、Google、hunter、quake、公众号等引擎找到企业相关关联域名以及股权穿透下属单位企业相关资产

targetsh.com(资产已虚拟化)-上海分公司targetjs.com(资产已虚拟化)-江苏分公司targettouzi.com（资产已虚拟化)-投资及交易企业targetapp.com(资产已虚拟化)-APP

    暂未找到相关小程序及其它更多资产，将收集的资产进行整理后放到ARL进行枚举，主要是对子域名及可能存在的敏感文件进行搜集，端口就TOP100即可，因为流量太大我这里网络可能不稳定，加之可能影响业务，这里需要注意的是，在ARL配置文件中，尽量把可以配置的搜索引擎KEY都配置上，因为字典并不会完全枚举到域名，一些自定义域名可能没在字典内

我们将力所能及收集到的子域名及结果分别查看，尤其是IP，这个不容忽视，将CDN去掉并导出，观察规律，有些可能是IP段，可以尝试在搜索引擎搜集此IP段可能存在的资产及信息，排除CDN后，将服务器IP尝试进行小流量端口探测

漏洞挖掘过程

接下来是愉快的漏洞挖掘过程，主要注意的就是OWASP TOP10，这里文章可以参考我以前总结的一篇文章，攻防不分家↓

以及一些API漏洞、逻辑漏洞、框架漏洞和探测出一些端口漏洞等，给我的经验是："漏扫并不能代替人工，不要过于依赖漏扫，它的逻辑是将POC和owasp的逻辑整理为库进行辅助扫描"，当然，我们不能否认有些漏扫的强大和智能

神奇的纵向轰炸绕过

企业的业务站点，已知多个子域名全是同样模板，经后期测试，数据还不互通，也就是说，正常不算重复，先来到注册页或短信登录页面，尝试抓包

我们可以看到，数据包为GET传参，通过/api/home/getphone/xxx接口进行发送验证码，我们可以尝试拼接一下此接口，然后查看404页面，可以看到使用的springboot框架，有可能是swagger-ui了

然后我们可以看到返回数据包中的datalist是4，这个代表一个手机号一天内可以发送最多5次验证码，目前还剩4次，我们继续重放，发现确实达到上限了

首先这里说明一下，GET传参的是查询此手机号剩余发送次数，POST则是发送验证码，先发送在接着查询次数，这时候有些师傅会想着，可能不存在漏洞，就忽视了，我们可以尝试在手机号处加一些拼接符号或拼接其它手机号

我此时在手机号处进行了添加逗号，发现确实发现成功并收到了短信

我尝试了拼接手机号，是否可以达到2个手机号接收验证码的目的进行任意用户登录，但是失败了，企业使用的是阿里的SMS网关，后面会讲到，然后总结以下流程

接着我们查看一下运营商阿里的SMS规则，为什么不能进行双写呢

正常情况下官方是允许使用逗号分隔发送的，这里试了很多方法都不行，原因可能是SMS网关做了策略，或者是前端做了过滤，我更偏向于前者

奇妙的功能越权

在平台正常情况下，我们登录后，后端校验账号密码正确，回包会给类似于token，userID，JWT编码ID等来表明用户身份，此处给的是不规则USERid

而这里想要在cookie中改ID不太容易，看了一下，平台使用的是session进行验证用户身份，我们都知道session是服务器生成的，用户在首次访问应用时，服务器会发送一个随机session给cookie，这里将身份信息给了session，所以不能用自己的userid进行替换

那么我们就需要找到可能存在userid功能的地方进行替换，注意观察流量包，因为用的是API，所以大概率会存在

好在通过个人信息的时候，找到一处API为/api/user/getUserinfo/userid的数据包

然后通过一处发帖处，找到了管理员的userid进行替换，成功达到越权的目的，证实漏洞存在即可

失败的OSS接管

某处的文件上传点，经过上传成功后发现，文件是存储到OSS中的，有经验的师傅都知道，一般这种情况都可能会存在AK,SK信息泄露，不出所料，往上翻流量包发现确实有，当时确实比较激动

由于STS特性，时效短，我赶紧使用OSS浏览器进行连接，结果失败了，运维或开发做了策略权限，无法连接

不过这里我也学到了点东西，我发现我在测试过程中，重复上传一个文件的情况下，并不会调用OSS上传文件，当不同文件(不同名/数据)时才进行调用，我大概根据我自己想法画个流程图

运气极好的shiro反序列化

企业开放的百分之70-80的业务网站均使用了shiro框架，在测试过程中，尤其登录的时候，很明显，当然了，特征可以隐藏或更改key，在曾经挖过的很多漏洞里，遇到的shiro也不少，但是基本上都是有key无链

输入错误账号或密码，产生错误返回请求，此时会在返回包内看到shiro特征，在set-cookie里面有rememberMe字段，rememberMe=deleteMe基本上就无疑了

这里使用shiro_tool或shiro_attack工具进行爆破key和链子，shiro确实比较吃运气的

经过短暂的爆破获取到了key和构造链，并且可以成功执行命令，权限为root

然后通过此方法拿到了十余台主机root权限，且被赐予脚本小子称号

哈哈哈，确实脚本小子，但是在实战过程中，我们速战速决的情况下能用脚本就用脚本，当然了，需要搞懂它的原理和流量判断，包括key和链子的构造等，这些都是在面试中经常问到的和实战可能遇到的

关于shiro、log4j、S2、thinkphp等框架有时间还是需要深入学习一下，避免下次再被赐名脚本小子，整理出后会将总结整理为文章一起学习

账户登录授权别样绕过

主站就那点东西，现在看其它旁站，在某旁站下:start.targetyw.com是另一个业务站点，但是当登录时，会跳转到auth.target.com去授权，也就是SSO系统，是企业自研发的，经过测试是没有漏洞的，正在发愁之际翻了一下前期信息收集的资产，发现有一个teststart.targetyw.com的网站，且登录是跳转到测试SSO系统，经过对漏洞挖掘，可以完成任意用户登录

此处测试站点testauth在发送验证码后，目标手机号并不会接收到验证码，起初我以为是我自己问题，后面又后知后觉的知道了是没有配置短信验证，随意输入验证码即可成功登录

已知在成功登录的情况下，响应包会返回个人身份信息的jwt编码，jwt编码的好处在于，即使你知道了他人的userid，单纯修改编码内userid值，其中的exp时间戳也没办法伪造越权(某些应用程序逻辑问题除外)

但是auth主站并不存在这个洞，我们测试，假设登录失败的情况下是什么样子

这里大胆尝试，我如果在testauth系统任意用户登录成功，抓取到相应的响应数据后进行替换到正式站点auth系统是否可行呢

进行替换放包后等待程序自动运行，成功进入主页，访问个人中心(脱敏原因无法截图页面)，看到/api/user/info接口个人信息成功显示

这里感觉还算是比较合理的，此处程序校验了jwt是否合格，然后手机号是否正确，userid是否正确，然后跳转，用户数据在主站和测试站点是同步的

OSS接管及springboot actuator未授权访问

在start及teststart业务站点下，/api/actuator中存在未授权访问，对于此漏洞并不陌生了，我们直接下载下来heapdump进行解密分析

使用JDumpSpider-1.1-SNAPSHOT-full工具拿到其中数据后，发现很多都是内网环境，密码都是弱口令，当然，前面我们已经通过shiro反序列化拿到主机了，由于是漏洞挖掘，点到为止，所以不在内网利用

至于为什么我前面提到是阿里的SMS短信接口呢，是通过heapdump文件中的smskey可以看到

然后通过翻阅文件，看到存在OSS及AK，通过工具扫描没发现任何东西，使用OSS浏览器登录发现又没有权限

其实说安全吧，这个做的还是比较安全的了，正在我灰心的时候，想着看看WEB还有没有什么可以利用的漏洞呢

在平台功能-创建团队-上传证件处找到文件上传点，依然熟悉的味道，PUT到OSS中，流程和上面文件上传一样

和上面不同的是，此时OSS浏览器登入，成功接管OSS，并且可以拿到近几年的所有上传数据及个人敏感数据

需要注意的是，STS开头的AK属于临时凭据，可用时长基本就3-5分钟，当然了剩余一些未授权访问和轰炸漏洞没有什么分析的，所以就不写出来了

至于前面我说到，为什么可以判断出来短信接口使用的swagger呢，请看下图

由此可以得出，此企业的业务网站，前端安全框架基于shiro，而API接口基于swagger进行调度，最后使用springboot框架进行后端调度

0x03 结语

由于时间较为紧张，平常也没什么时间，有一些如：堡垒机、APP、OA、论坛等都没有再拓展性挖掘，一些没有什么写讲解的地方就不再叨叨了，捡洞+手动挖大概15个漏洞，一篇文章并不能全部写完，书是慢慢读的，多学多想

渗透测试是目的，漏洞挖掘是过程，在进行渗透挖洞过程中，多去思考和关联是非常有必要的，经验都是满满攒出来学出来的，漏洞不分高低，黑盒白盒各有千秋，静下心了学习思考，每个漏洞都可能是高危，勤能补拙方能成才，望各位多多交流技术，早日成为人中龙凤

原文始发于微信公众号（州弟学安全）：漏洞挖掘|从实战中学习漏洞挖掘与渗透测试流程