关于Struts2及Weblogic反序列化工具被他人擅自公布下载的声明

大大源码 • 2023年3月20日 pm11:47 • 未分类

Part1 前言

大家好，我是ABC_123。今天好多朋友给我发信息说，工具被人公布到某公众号提供下载了，还提倡加入qq群，好多人还误以为是我在提供下载，还误以为我与其他人进行合作啥的。。。(非ABC_123本人自愿的泄露事件)

为此本人ABC_123在此郑重澄清：

1、本人未授权未授意任何人公布工具的下载地址。公布出来的工具如果被恶意捆绑木马、加入后门，被用来社工钓鱼，本人概不负责。

2、禁止使用该工具去蹭热度、刷流量、博眼球，禁止把工具公开售卖，因为这些行为背离了我写这些工具的初衷。

3、禁止用来做未授权的测试，禁止被用来做黑产、灰产。工具被公布下载引起的刷shell、刷黑产的行为，由相关责任人承担。

4、本人暂时没有公开建的qq群和微信群。

5、后续这些工具还会更新，但是我会想办法杜绝这种现象发生，比如说加上网络验证及license限制。

6、一切消息以本公众号为准，本人没有其它公众号。

Part2 工具研发历程

这两个工具是我从2016年时开始编写，当初是为了方便同事、朋友对相关漏洞进行检测。随后一直更新到今天，有6年之久了吧，之前一直在公司内部流传，从未公开。在这6年期间，从未有一个人把工具直接放到网上提供下载，但是今天这个游戏规则还是被打破了。

自从我写公众号之后，几乎每天都有人问各种各样的问题，其中就包括这些工具的问题，有时候公众号后台消息多了，工作忙，也没时间一一回复，请大家谅解。但是如果是技术交流问题，我一般都会回复。在这里我也就网友经常问的问题做一个统一回复吧。

工具的MD5哈希值

为了防止工具被捆绑恶意木马或者广告链接，工具的MD5、SHA1值如下：

Struts2全版本漏洞检测工具19版本md5及SHA1加密值如下：

MD5: 667CA10E430E2FE65AC239384F208C7F

SHA1: 39DD5FE1307E644051BCF9A7270F90D23CC0B586

Weblogic T3/IIOP反序列化工具md5及SHA1加密值如下：

MD5: 91513512BBB42CB6080C36B4D06472EF

SHA1: FDD694DEBBFCC14BE7BE90EED2610AF4831FFAB0

工具编写初衷

这两个工具编写初期，主要是方便身边的朋友对漏洞进行快速检测、打攻防比赛的时候，可以快速拿下权限，不用把精力放在重复的手工操作上。因为在我看来，网络安全服务项目、渗透测试项目、攻防演习项目、红队评估项目等等，90%以上的漏洞测试工作都是繁琐的重复的，日复一日年复一年，做的都是重复来重复去的工作。所以为了减少繁琐的工作，我很早就有工具化、自动化、武器化的思维。写一个工具，输入一个URL，点击“检测”按钮，漏洞存在与否就被完全验证，那岂不是很好。

为什么不公开提供下载

主要是因为安全测试工具是一把双刃剑，我相信安全圈子大多数人都是善意的，但是其中难免鱼龙混杂，有极少数不法分子会利用这些工具刷shell、做灰产，甚至之前还有人挂在咸鱼公开售卖，这些是本人ABC_123不想看到的。

先前版本的Struts2工具、Weblogic工具是带有批量扫描功能的，因为我记得当初漏洞频繁爆出的时候，客户几千几万的ip，逐一验证工作量特别大，所以我就写了批量功能，但是有的网友就去批量getshell了，最终我只能遗憾的把批量功能删掉了。

为什么不开放源代码

早期的版本是开源的，结果还是惹出了点麻烦。工具写出名了，就会有人重新编译一个新版本，连出处都不注明，还有人在其中插入广告链接，甚至插入木马程序，对本人造成很多不良影响。所以后续没办法，源代码做了加密混淆。但是后续有朋友想要研究Struts2的语句，我就给工具加上了一个HTTP代理功能，所有的检测语句都是可以用burpsuite抓包的。这个代理功能其实就是为了给学习者抓包语句，改包过waf用的。

为啥有的Struts2漏洞，只有这个工具能检测出来

因为Struts2、Weblogic漏洞的检测尤其麻烦，因为这两类漏洞受生产环境因素影响特别大，与虚拟机环境下大不相同，大概Java类型漏洞都有这个麻烦。很多时候一个CVE编号的漏洞，要用5、6个payload来检查。

比如说：有的生产环境下Struts2框架，最简单的Response对象的print方法不能执行，那么就得想办法变更payload；有的网站的response屏蔽了任何回显，就得想办法用DNSlog方式来检测漏洞；有的环境禁止了出网，就得想办法用延迟手法判断；有的没办法直接延迟，比如Weblogic反序列化，延迟是发生在控制台的，延迟判断就没法使用，就得想其它办法产生延迟效果；有的payload一次检测后就失效，就需要保证其一次检测的成功率最大；反序列化漏洞受环境因为影响更大，JDK1.5、JDK1.6、JDK1.8等等payload都不一样；有的类只在Struts2、Weblogic特定版本才有；有的类只在JDK1.8上才有，有的类在JDK1.8高版本又被删除了，有的环境只支持ldap不支持rmi，有的反序列化Jar包的SUID不同，需要URLClassLoader加载不同jar包解决，等等。。。

遇到的问题实在是太多太多了。而且同样的反序列化漏洞，前端waf设备封堵了T3协议的情况下，就得变更为IIOP协议，但是IIOP协议坑也挺多的。我为解决这一系列问题，付出了很大的精力。所以，工具同样是工具，有的工具检测得准确，里面肯定是内置了很多判断逻辑。