本文强脱敏，因为涉及的企业都很大，涉及到信息和资产相关的都不会贴图，相关特征图片也用其他类似的代替，所以文字占了大部分，着重记录一下思路，十分抱歉师傅们见谅。
本次攻击用到了两个供应链，包含一个我没公开的day
这次的目标是一个投送广告的大屏管理企业，拿下了这个系统基本就控住了那个地市三分之一的商业大屏
而其资产是托管在其他厂商那里，或者说是委托其他厂商来开发运维，目标只是作为使用方。
那目标就很明确，由这目标单位范围延伸覆盖到了运维厂商侧，然后开始收集厂商资产。
在收集过程中发现这个厂商做了非常多家企业的运维开发业务，但业务系统并不一致，只是主域名资产都是备案在厂商。
不过对于这种单位，他运维团队除非很大，否则在运维习惯上会有很大的通用性，为了验证这点，在查了他单位的人员信息和一些采购、业务纠纷、合同指标之后发现他公司的开发运维技术团队并不大，直觉告诉我只要打进一个或者两个，就有很大概率杀到目标单位。
所以我挑选了旗下的一个建筑企业，因为他的ui很眼熟，让我想起来一个年初时候的一个项目，当时的目标是一个五百强企业，除了高防就是封，10分钟给我封了3ip，压根没法测，其他队伍也碰了一鼻子灰。
最后我顺着系统指纹找到了供应链企业的一个测试环境，其并没有套waf，在我字典的狂轰乱炸下出了个名字肥肠逆天的入口接口，当时打了两天，黑盒fuzz出了他们所有未授权的接口和参数，最后成功拿到了这个目标企业在海外援建的所有人员和项目的信息，艰难拿下4000分（分好少..）
（这个图的login并不是本项目用到的,随便找了个别的）
不过这个也就只是看着眼熟，在看了前端的特征并没有什么相同的特点。
然后我就去打开了原来那条链的几个版本的站点，找了个几个原来系统在比对了几个版本之后我确信这个是被二开过的，ui基本全换了，但是登录框布局并没有替换，但是不知具体使用的版本。
但是他漏了一点，在一个无关紧要的js里有系统原来的名字，而这个系统也是在我day的覆盖范围内的。
我先尝试了绕过被关闭的注册添加一个admin权限用户
不过他这个比较坑的是虽然可以未授权直接添加，但是必须要用手机再做个短信验证，我在发过包去等认证短信等了好久还是没等到，猜测他系统可能没对接短信平台。那就退而求其次，尝试翻一下用户信息和平台的文件信息。
然后先用洞绕过前台翻取它系统中的敏感文件，然后就报错了
应该是文件太多pg没法直接全返回，所以加个过滤就ok
在翻了很久之后找到一个一年前交付时候的技术文档，在翻阅中我发现他家在项目开发中，凡是二开的项目都喜欢新加一个接口路径，并且都喜欢以项目名相关信息的拼音简写。
比如水利系统，就会写成 `/slxt/system/xxxx/xxxxxxx`
而在这文档中也存在一个系统url上面有泄露他的开头路径，可能是测试用的，点进去就是个接近静态的站点，毛js都没加载，拼上翻出的前缀路径再爆破目录后也是什么都没产出，简直逆天，测了一顿什么都没出来。
除此之外其中大部分都是一些非目标的项目信息，而人员信息也就是一些三要素，简单的收集了一下，这套系统中的超管是强制强口令的所以压根没法爆破。
然后这里面就没什么收获了，主要登录需要短信验证，而这套系统我也没找到可以前台getshell的点。
没办法这里啃不出东西来，就去看了这个厂商其他资产，在精挑乱选之后我尝试拼了另一个企业的简写作为路径fuzz了下路径下的接口，可能是我猜错路径名，亦或是我的想法不成立，打了几个资产也都没有任何收获。
不过我还是坚信，能用我都能发现的漏洞的系统的企业，它指定是不会很安全。
所以我挨个资产从头排着打，一共是二十几个系统资产，在打到了厂商业官网的时候，我发现他有个登陆，点击后跳转到了另一个没有备案域名的ip的资产
在看他的网页源码时，发现这个站点的js特征暴露出这个站点有我今年时候发现的另一个框架漏洞，不过只是一个接口信息泄露。
然后就拿出当时的利用记录对它进行一个嗦，发现相关泄露路径都被ban了，猜测可能是开发对框架魔改过，没办法只能祭出最后一个，在这个框架中其实存在一个隐藏的js，不过名字会比较复杂并且通常是不会直接暴露出来，而在这个框架的官方文档中也没有体现，开发基本上是发现不了有这个东西，但是他会同样暴露出所有接口和params。（这是打另一个项目时候在个边缘资产发现有个企业用了这套框架，曰进去之后发现的）
所以目前是这个样子
然后就对接口进行挨个fuzz，这套系统同样也是在框架原来的路径之外也单独写了个自己的接口路径.
举个例子，正常框架下的原生接口是这样的
通常大部分开发喜欢在原生接口路由后面接着写
而这家喜欢这样写
而其他暴露在外面原生功能还是沿用的框架的接口，比如登录传入的接口还是原生框架的，这框架原来就很成熟的，所以测不出东西来。
这也怪不得直接跑路径是跑不出啥来。
fuzz的方式比较多，我习惯ffuf跑，方式很多看个人习惯，这里就不多赘述了。
在一顿跑之后其实大部分接口都401了，但在其中还是有几个漏网之鱼，其中有一个`logs`引起了我的注意
在访问之后发现其是这套系统中所有的请求记录，其中包含了post请求的body
但遗憾的是可能是这套系统的开发对他进行过修改，body部分被好像置空了，我在尝试POST了几个之后发现我传入的data也被替换为空。
最后我把这十几个系统全测完了，只收获了两个接口泄露，一个人员和项目信息泄露，以及发现两个运维厂商没备案的资产，至于目标站点可以说是坚若磐石（
不过我有个在打同一个厂商的时候习惯建一个wordlist保留这个项目他们js或者swagger等泄露所有接口path的习惯，这次也同样不例外，然后我就不断对着这些个站点递归扫啊扫，黑盒打起来是真难受啊。
在第四天的时候我仍旧在漫无目的的测这十几个资产，然后我看着资产突发奇想，有没有一种可能他的交付演示环境，使用的同样会是泄露接口的框架的后台，可能他把main路径藏在了静态页后面的路径。
然后在拼接之后就真的出货了
是的，他确实把路径藏在了`/test/xxx/xxxx-api/`，但这次暴露是暴露出来了，他们并没有往这里面直接加接口，或者他们压根测试环境就没有完全用到这个框架，我是麻了。
思索了一下他们开发写码子的习惯，我猜测他们`/test/xxx/`test后的第一个路径有可能就是他们的对应的其他站点根路径，所以我直接把其他十来个站点积攒的字典对他进行一个跑。
最后出了一堆不存在的接口，在里面我又见到了其他两个站点都有的`logs`目录，但是这次并没有让我失望。
他开发忘记屏蔽body回显了，并且这个环境目前还在使用，在我过滤了`url`key为`login`路径之后直接就看到了其他人的登陆时候的账户密码。
考虑到大概率是他们开发登陆的，我拿到超管密码直接去测运维厂商其他资产
果不其然，开发一懒导致口令全是通用的。
然后再试试目标系统。
结束，全部拿下。
不得不说他这个开发的可视化管理的大屏非常帅气，但是因为容易被一眼认出是哪个地区的哪个企业，所以不敢放，十分抱歉。
最后是整个攻击的路线图
实在不好意思，有些地方技术细节不敢写太细了，这次整个过程涉及的企业都比较敏感所以只能记录一下大体的思路。
---本文来自于Flower师傅的投稿，非常精彩！
