1.Apache Tomcat 反序列化代码执行漏洞复现(CVE-2020-9484)
2.shiro反序列化漏洞原理分析以及漏洞复现（Shiro-550/Shiro-721漏洞复现）
3.Tomcat Session(CVE-2020-9484)反序列化复现
4.记一次反序列化漏洞的码分利用之路
5.ysoserial-URLDNS调试分析
6.Shiro反序列化漏洞原理详解及复现

Apache Tomcat 反序列化代码执行漏洞复现(CVE-2020-9484)

       Apache Tomcat的CVE--远程代码执行漏洞概述，漏洞的码分详细信息与影响范围如下。

       Apache Tomcat是码分一个开放源代码的Java Web应用容器，该漏洞存在于使用了自带session同步功能，码分而没有正确使用EncryptInterceptor配置的码分场景中。攻击者利用精心构造的码分加油优惠源码搭建数据包，可以对部署了Tomcat且具有特定配置的码分服务器进行攻击。

       成功利用此漏洞需要满足以下四个条件：

       攻击者能够控制服务器上的码分文件内容和文件名。

       服务器配置了PersistenceManager使用了FileStore。码分

       PersistenceManager的码分sessionAttributeValueClassNameFilter配置为“null”或者过滤机制不严格，允许攻击者提供恶意反序列化的码分对象。

       攻击者知道FileStore存储位置到攻击者可控文件的码分相对路径。

       该漏洞的码分威胁等级为中危，主要影响版本在CVE--漏洞公告覆盖的码分范围内。

       漏洞复现实验可以在本地环境或Docker容器中进行。码分

       本地环境搭建步骤：

       设置server.xml文件参数，如debug、saveOnRestart、maxActiveSession等，然后部署一个依赖commons-collections4的web应用到Tomcat中。

       Docker环境搭建步骤：

       克隆相关代码，构建Docker镜像，运行Docker容器，并通过特定端口访问容器内的Tomcat服务。

       验证漏洞的存在，可以通过以下步骤：

       使用ysoserial工具生成恶意序列化数据，利用文件上传功能将数据上传到服务器。

       发起恶意请求，携带恶意数据。

       漏洞检测方法包括：

       检查安装的Apache Tomcat版本，确认是否受影响。

       检查配置文件（如context.xml或server.xml）中是否存在FileStore配置。

       修复建议包括：

       使用最新版本的Apache Tomcat，官方已修复该漏洞。

       禁用或正确配置FileStore的使用，避免使用不安全的反序列化过滤机制。

       华云安安全威胁管理平台提供了一套自动化漏洞挖掘与利用能力，帮助客户实现持续的风险检测和威胁防御。

       “以攻促防，攻防兼备”的理念贯穿华云安的产品与服务，通过一流的安全攻防团队和网络安全产品，服务于关键信息基础设施行业，构建全面的文字游戏源码 php网络安全保障体系。

shiro反序列化漏洞原理分析以及漏洞复现（Shiro-/Shiro-漏洞复现）

       shiro-反序列化漏洞（CVE--）漏洞简介

       shiro-主要是由shiro的rememberMe内容反序列化导致的命令执行漏洞，造成的原因是默认加密密钥是硬编码在shiro源码中，任何有权访问源代码的人都可以知道默认加密密钥。于是攻击者可以创建一个恶意对象，对其进行序列化、编码，然后将其作为cookie的rememberMe字段内容发送，Shiro 将对其解码和反序列化，导致服务器运行一些恶意代码。

       特征：cookie中含有rememberMe字段

       修复建议：

       更新shiro到1.2.4以上的版本。

       不使用默认的加密密钥，改为随机生成密钥。

       漏洞原理

       一、Shiro简介

       Apache Shiro 是一个强大易用的 Java 安全框架，提供了认证、授权、加密和会话管理等功能，对于任何一个应用程序，Shiro 都可以提供全面的安全管理服务。

       在ApacheShiro<=1.2.4版本中AES加密时采用的key是硬编码在代码中的，于是我们就可以构造Remembe Me的值，然后让其反序列化执行。

       二、Shiro服务器识别身份加解密处理的流程

       （1）加密

       1.用户使用账号密码进行登录，并勾选"Remember Me"。

       2、Shiro验证用户登录信息，通过后，查看用户是否勾选了”Remember Me“。

       3、若勾选，则将用户身份序列化，并将序列化后的内容进行AES加密，再使用base编码。

       4、最后将处理好的内容放于cookie中的rememberMe字段。

       （2）解密

       1、当服务端收到来自未经身份验证的用户的请求时，会在客户端发送请求中的cookie中获取rememberMe字段内容。

       2、将获取到的rememberMe字段进行base解码，再使用AES解密。炫舞注入器源码

       3、最后将解密的内容进行反序列化，获取到用户身份。

       三、Key

       AES加密的密钥Key被硬编码在代码里

       于是可得到Payload的构造流程：

       恶意命令-->序列化-->AES加密-->base编码-->发送Cookie

       Shiro-反序列化漏洞（CVE--）Shiro和Shiro的区别是什么

       Shiro只需要通过碰撞key，爆破出来密钥，就可以进行利用 Shiro的ase加密的key一般情况下猜不到，是系统随机生成的，并且当存在有效的用户信息时才会进入下一阶段的流程所以我们需要使用登录后的rememberMe Cookie，才可以进行下一步攻击。

       漏洞指纹

       URL中含有Shiro字段

       cookie中含有rememberMe字段

       返回包中含有rememberMe

       漏洞介绍

       在Shiro中，Shiro通过AES--CBC对cookie中的rememberMe字段进行加密，所以用户可以通过PaddingOracle加密生成的攻击代码来构造恶意的rememberMe字段，进行反序列化攻击，需要执行的命令越复杂，生成payload需要的时间就越长。

       漏洞原理

       由于Apache Shiro cookie中通过 AES--CBC 模式加密的rememberMe字段存在问题，用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段，用有效的RememberMe cookie作为Padding Oracle Attack 的前缀，然后制作精心制作的RememberMe来执行Java反序列化攻击

       攻击流程

       登录网站，并从cookie中获取RememberMe。使用RememberMe cookie作为Padding Oracle Attack的前缀。加密syserial的序列化有效负载，以通过Padding Oracle Attack制作精心制作的RememberMe。请求带有新的RememberMe cookie的网站，以执行反序列化攻击。攻击者无需知道RememberMe加密的密码密钥。

       加密方式：AES--CBC 属于AES加密算法的CBC模式，使用位数据块为一组进行加密解密，即字节明文，对应字节密文，，明文加密时，如果数据不够字节，则会将数据补全剩余字节

       若最后剩余的明文不够字节，需要进行填充，通常采用PKCS7进行填充。比如最后缺3个字节，则填充3个字节的0x;若最后缺个字节，则填充个字节的0;

       若明文正好是个字节的整数倍，最后要再加入一个字节0x的组再进行加密

       Padding Oracle Attack原理 Padding Oracle攻击可以在没有密钥的情况下加密或解密密文

       Shiro Padding Oracle Attack（Shiro填充Oracle攻击）是一种针对Apache Shiro身份验证框架的安全漏洞攻击。Apache Shiro是易语言打开源码Java应用程序中广泛使用的身份验证和授权框架，用于管理用户会话、权限验证等功能。

       Padding Oracle Attack（填充Oracle攻击）是一种针对加密算法使用填充的安全漏洞攻击。在加密通信中，填充用于将明文数据扩展到加密算法块大小的倍数。在此攻击中，攻击者利用填充的响应信息来推断出加密算法中的秘密信息。

       Shiro Padding Oracle Attack利用了Shiro框架中的身份验证过程中的一个漏洞，该漏洞允许攻击者通过填充信息的不同响应时间来确定身份验证过程中的错误。通过不断尝试不同的填充方式，攻击者可以逐步推断出加密秘钥，并最终获取访问权限。

       这种攻击利用了填充错误的身份验证响应来获取关于秘密信息的信息泄漏，然后根据这些信息进行进一步的攻击。为了防止Shiro Padding Oracle Attack，建议及时更新Apache Shiro版本，确保已修复该漏洞，并采取其他安全措施，如使用安全的加密算法和密钥管理策略。

       漏洞复现：CVE--

       环境：kali linux

       靶场使用：vulhub/shiro/CVE--

       访问地址：

       抓包分析一下：

       在返回包当中发现存在rememberMe=deleteMe 字样，可以大概确定有配置shiro，可以进行下一步。因为shiro本身功能就是一个身份验证管理，所以一般都在登录口可以看到。

       UI一键利用工具

       使用工具再进行检测确认:

       输入目标的url地址，根据关键字进行爆破秘钥

       接下来爆破利用链以及回显方式：

       接下来可进行命令执行：

       反弹shell：

       可使用工具进行检测：

       检测完成后可进行命令执行，反弹shell等操作：

       使用工具进行简单的反弹：

       设置监听端口

       window：

       linux：

       还有使用ysoserial监听模块JRMP来进行反弹shell，具体可看参考文档，操作都差不多。

       正是因为利用简单，所以危害比较大。

       工具地址

       漏洞复现：CVE--

       环境：kali linux

       docker进行搭建启动

       访问：

       利用过程和shiro差不多，shiro需要登录网站，并从cookie中获取RememberMe。

       进行登录，使用正确的账号和密码：

       先使用正确的账号密码登录后，在抓包获取合法 Cookie（勾选Remember Me）

       如果认证失败则只能得到 rememberMe=deleteMe

       将登录后获取的set-cookie值当中的rememberMe值，将值复制下来，放到工具当中

       选择shiro，输入目标url，设置rememberMe值，点击下一步，微信拆礼盒源码等待即可

       选择检测方式：

       等待即可：

       使用shiro综合工具：

       输入url后：进行爆破秘钥，爆破利用链以及回显

       命令执行：

       工具地址

Tomcat Session(CVE--)反序列化复现

       Apache Tomcat远程代码执行风险剖析

       Apache Tomcat，一个开放源代码的Web应用服务器，主要实现Java EE规范中的Servlet、JSP，并提供HTTP服务，是广泛使用的Java Web容器。在年，由Sun Microsystems开发并在年捐献给ASF（Apache Software Foundation），现独立为顶级项目。Tomcat为中小规模系统和低并发访问提供高效服务，适合初学者开发和调试JSP程序。它作为Apache服务器的扩展运行独立进程，具备轻量级应用服务器特性。

       CVE--：Tomcat反序列化漏洞

       年5月日，Apache官方宣布了Tomcat远程代码执行风险，漏洞编号CVE--。此漏洞存在于Tomcat使用内置session同步功能时，若配置不当（未使用EncryptInterceptor），攻击者通过精心构造数据包，可对使用内置session同步的Tomcat服务器发起攻击。

       成功利用此漏洞需满足四条件：攻击者能够控制服务器文件内容与名称；服务器使用FileStore进行持久化；sessionAttributeValueClassNameFilter配置不当，允许攻击者提供反序列化对象；攻击者知道FileStore存储位置与攻击可控文件相对路径。

       影响版本

       Apache Tomcat版本包括：.0.0-M1至.0.0-M4，9.0.0.M1至9.0.，8.5.0至8.5.，以及7.0.0至7.0.。

       源码分析

       根据配置，对Tomcat源码进行分析。以Tomcat .0.0-M4为例，关注FileStore的load方法，此方法首先将session id转换为file object并检查文件是否存在。若存在，则读取文件内容。文件对象会添加'.session'后缀，但未验证目录路径。当文件存在时，系统运行CustomObjectInputStream获取gadget类，进行反序列化操作。

       环境搭建

       安装Tomcat需Java8环境，具体安装教程可见相关链接。下载Tomcat .0.0-M4，创建tomcat目录，解压文件。在conf目录下编辑context.xml文件添加Manager配置。下载groovy-2.3.9.jar，放入lib目录下。执行wget命令下载依赖，运行catalina.sh启动Tomcat。访问ip:，确认安装成功。

       漏洞复现

       使用ysoserial生成Java反序列化payload，执行java命令生成payload文件。在浏览器中添加Cookie，包含攻击性JSESSIONID值。或直接通过curl命令加载恶意session持久化文件。执行ls /tmp查看结果。

       修复方法

       通过升级Tomcat版本、配置WAF过滤器、或避免使用FileStore来修复此漏洞。

       免责申明

       本项目仅用于安全人员完成授权项目测试与学习交流，不涉及漏洞利用与攻击性行为。使用时请遵守当地法律法规，避免非授权测试。

记一次反序列化漏洞的利用之路

       0x 前言

       通过偶然的机会获取一套系统的源码，利用CodeQLpy轻松发现存在反序列化漏洞，此漏洞属于标准的java反序列化，未进行任何过滤，可利用性较高。

       0x 探索

       1） 验证漏洞存在：通常，确认反序列化漏洞的手段为URLDNS链。这条链依靠JDK自带，无需依赖第三方jar包，网络出问题即能利用成功，具备较强的通用性。利用ysoserial生成URLDNS链所需的序列化内容，对ysoserial.payloads.util.PayloadRunner的run方法稍作修改，将序列化的数据保存至文件cc.ser，不进行反序列化操作。之后，通过run方法生成序列化内容。在目标环境下进行测试，验证通过URLDNS链触发DNS请求成功。

       2） 常见利用链探索：CommonCollections链作为反序列化中最常见的手段，在目标源码中同样存在相关jar包。尝试使用ysoserial中的CC链生成对应序列化文件，但实际环境中失败，无法触发命令执行。确认源码环境为Linux，尝试了CC链的全部7条，均未成功。考虑到可能存在源码问题，使用源码在目标环境下反序列化生成的序列化文件，发现异常在于InvokerTransformer类未继承Serializable接口，确认为修复方式。

       3） 替代利用链：CC链未能成功利用，但发现系统存在CB链对应的jar包。测试CB链在系统中无法直接成功，通过本地调试发现错误原因在于版本不一致导致的serialVersionUID报错。查询得知，Java在反序列化时通过serialVersionUID值进行版本检查，不兼容则反序列化异常退出。为解决版本不一致问题，将ysoserial源码拷贝至目标源码中，使用目标源码的jar包作为依赖，最终通过CB链达到RCE效果。

       0x 结论

       总结反序列化漏洞利用经验：1、并非所有CommonCollections3.2版本均适用于反序列化利用；2、CommonsBeanutils链生成的payload因jar包版本不同导致serialVersionUID报错；3、直接使用ysoserial生成payload不成功时，可在目标源码环境下调试，避免因版本不一致引发的错误。

ysoserial-URLDNS调试分析

       ysoserial是强大的反序列化工具，深入研究其利用链能帮助理解Java语言特性，为Java安全学习打下坚实基础。本文将重点分析URLDNS的利用过程。

       利用链分析如图所示，当HashMap的key为URL类对象时，调用key.hashCode实际上触发了URL类对象的hashCode方法，从而引发DNS解析。实现自定义exp较为简单，通过设置hashCode为1，使得putval时重新计算hashCode，以触发DNS解析。

       使用IDEA，结合ysoserial jar (jitpack.io/com/github/f...)和ysoserial源码 (codeload.github.com/fro...)进行实践。

       进行反序列化操作，查看dnslog，倒推分析过程。通过urldns类文件，我们发现ysoserial调用getobject方法，URLStreamHandler类处理url解析。URL类解析出协议、主机名、端口号等信息，协议决定交互规范，如HTTP、FTP等。在成功构造URL实例后，openConnection()方法返回URLConnection对象，URL对象代理调用URLStreamHandler的openConnection()方法。

       接着，实例化HashMap类，调用readobject方法进行反序列化。观察反序列化代码，发现调用putVal方法进行hash计算。首先深入hash方法，处理null和非null情况。对于URL对象作为key，可追踪到URL类的hashCode方法。判断hashCode是否等于-1，返回或调用handler的hashCode方法，最终调用实际的URL对象方法。

       深入跟踪getHostAddress方法，其中InetAddress.getByName(host)实现DNS请求。通过DEBUG调试，发现反序列化过程中执行了实际的DNS查询。最后，反序列化的值即为利用过程的结果。

Shiro反序列化漏洞原理详解及复现

       要进行Shiro反序列化漏洞的探究，首先需要搭建一个vulhub提供的Shiro环境，通过访问端口进行测试确认。

       Shiro是个开源的安全框架，核心功能包括身份验证、授权和会话管理。当我们尝试登录并勾选"Remember me"选项，Burp抓包会发现响应包中的set-cookie字段包含'rememberMe'。如果不勾选，set-cookie则会设置为'rememberMe=deleteMe'，这成为判断网站是否使用Shiro和是否存在漏洞的线索。

       虽然不深入分析源码，但服务端在处理cookie时，会经历一系列操作，包括读取、处理和存储。这个过程中的一个环节，URLDNS链可以被利用，从HashMap的readObject方法开始，通过一系列转换最终发送DNS解析请求。利用ysoserial工具生成URLDNS链，然后对特定payload进行加密和编码，隐藏JSESSIONID并修改rememberMe字段。

       通过这种方式发送请求，DNS日志会显示成功，表明存在可利用的漏洞。进一步，可以尝试生成CC链，利用它执行反弹shell攻击，但需要注意，vulhub靶机可能缺少nc工具，需要先进行上传。

       关于Shiro的不同版本，1.4.2版本之前的使用CBC加密，虽然密钥不再硬编码，可以通过padding oracle攻击，但1.4.2及以后的版本切换到了GCM加密，这为防御带来了变化，需要在实际环境中考虑相应的防护措施。

初入RMI反序列化（一）

       程序员的探索之旅:

       本文将深度剖析RMI反序列化，分为"入门篇"和"漏洞解析"两大部分，带你探索RPC框架中的RMI技术，包括其背后的原理、实现及潜在的安全隐患。我们将在JDK8u的攻击端与jdk7的服务端，以及Apache-Commons-Collections 3.1和ysoserial.jar的背景下展开讨论。

       RMI基础

       在分布式编程中，RMI是RPC框架之一，让我们从概念出发：

RPC框架比较：RMI、grpc和dubbo各有特色，RMI以其简单易用著称。

RMI概念解析：远程调用的奥秘，Server、Client和Registry的协作机制。

实践代码示例：一步步构建接口、实现、实体，以及客户端如何调用远程服务。

源码浅析揭秘：深入RMI源码，理解服务端的发布与调试过程。

       服务端发布与调试

发布过程：从无参构造到创建RemoteHelloWorld引用，每个步骤都至关重要。

关键步骤：初始化castServerRef，通过端口传递；有参构造LiveRef，实现对象的远程发布。

UnicastRef封装：TCP通信与对象类型检查，确保高效安全的通信。

exportObject与代理：创建并调用RemoteHelloWorld，服务器端的代理写法如何运作。

       安全风险点

       在服务端，执行call方法时，readObject漏洞可能成为攻击者的入口：

readObject的危险：未过滤的输入流可能导致恶意对象反序列化，构成潜在威胁。

客户端与服务端的攻防：序列化/反序列化操作，既是攻击手段，也是防御线。

       动态代理与客户端调用

       var动态代理类中，RemoteObjectInvocationHandler与LiveREF承载着服务端信息，客户端调用远程方法时，这个环节尤为关键：

客户端调用链路：从注册中心获取服务，执行executeCall，反序列化可能的陷阱。

返回值与潜在攻击：unmarshalValue环节，可能成为攻击者下手的地方。

       总结：序列化/反序列化如同一把双刃剑，既可实现数据交互，也可能带来安全风险。下期我们将深入剖析RMI反序列化漏洞，敬请期待！