shiro反序列化攻击（是否 有 java反序列化漏洞）

本文目录

• 是否 有 java反序列化漏洞
• 【CVE-2016-4437】Shiro反序列化漏洞复现
• 如何防止java编程语言序列化网络攻击
• shiro中User user = (User) *****().getPrincipal();
• java反序列漏洞，涉及到哪些中间件
• 泛微OA反序列化漏洞是什么原因导致的
• shiro的session信息放redis反序列化异常解决
• Shiro RememberMe ***** 反序列化命令执行漏洞复现

是否 有 java反序列化漏洞

java反序列化漏洞是一类被广泛应用的漏洞，绝大多数的编程语言都会提供内建方法使用户可以将自身应用所产生的数据存入硬盘或通过网络传输出去。这种将应用数据转化为其他格式的过程称之为序列化，而将读取序列化数据的过程称之为反序列化。
　　当应用代码从用户接受序列化数据并试图反序列化改数据进行下一步处理时会产生反序列化漏洞。该漏洞在不同的语言环境下会导致多种结果，但最有危害性的，也是之后我们即将讨论的是远程代码注入。
　　*****反序列化漏洞发现历程
　　在最近几年间，不断的有java反序列化漏洞被曝光。最近的几次分别产生于spring框架以及Groovy还有文件上传的java库中，这些漏洞均得到了修复。
　　但在最近的研究中，安全人员发现java反序列漏洞远远不止上述几处，该漏洞广泛的存在于java库中。
　　Java反序列化漏洞：
　　漏洞产生原因：
　　在java编写的web应用与web服务器间java通常会发送大量的序列化对象例如以下场景：
　　HTTP请求中的参数，cookies以及Parameters。
　　RMI协议，被广泛使用的RMI协议完全基于序列化
　　JMX 同样用于处理序列化对象
　　自定义协议 用来接收与发送原始的java对象
　　在序列化过程中会使用ObjectOutputStream类的writeObject()方法，在接收数据后一般又会采用ObjectInputStream类的readObject()方法进行反序列化读取数据。其代码示例如下：
　　上述代码中的java类ObjectInputStream在执行反序列化时并不会对自身的输入进行检查，意味着一种可能性，即恶意攻击者构建特定的输入，在ObjectInputStream类反序列化之后会产生非正常结果。而根据最新的研究，利用这一方法可以实现远程执行任意代码。

【CVE-2016-4437】Shiro反序列化漏洞复现

Apache Shiro是一款开源的java安全框架，执行身份验证、授权、密码和会话管理。
Apache Shiro *****及以前版本中，加密的用户信息序列化后存储在名为rememberMe的Cookie中。攻击者可以使用Shiro的默认密钥伪造用户Cookie，触发Java反序列化漏洞，进而在目标机器上执行任意命令。

Apache Shiro 《=*****

使用vulhub搭建环境

尝试登录，登录的返回包中有 rememberMe=deleteMe 字段

或者不登录，发送一个GET请求登录页面的包，把cookie改成rememberMe=1，返回包中也存在 rememberMe=deleteMe 字段

则可判断使用了shiro框架，接下来使用工具ShiroExploit 检测是否存在shiro反序列化漏洞
***隐藏网址***

当命令框可输入，代表存在漏洞

可以勾选便捷操作，反弹shell，输入攻击机的ip和端口号，并在攻击机**端口，然后点fire，成功获取目标的shell

如何防止java编程语言序列化网络攻击

java编程一直以来都是互联网软件开发市场上的主流开发语言，同样的这也就导致了只要发生漏洞的话，所有用java编程开发的软件都会出现问题，下面昌平java培训就一起来了解一下，java编程语言中的序列化问题应该如何解决。

什么是序列化?

自从1997年发布*****以来，序列化已经存在于Java平台中。

它用于在套接字之间共享对象表示，或者将对象及其状态保存起来以供将来使用(反序列化)。

在JDK10及更低版本中，序列化作为*****包和*****方法的一部分存在于所有的系统中。

序列化的挑战和局限

序列化的局限主要表现在以下两个方面：

出现了新的对象传输策略，例如JSON、XML、ApacheAvro、ProtocolBuffers等。

1997年的序列化策略无法预见现代互联网服务的构建和攻击方式。

进行序列化漏洞攻击的基本前提是找到对反序列化的数据执行特权操作的类，然后传给它们恶意的代码。

序列化在哪里?如何知道我的应用程序是否用到了序列化?

要移除序列化，需要从*****包开始，这个包是*****模块的一部分。常见的使用场景是：

实现Serializable接口和(可选)serialversionuid长整型字段。

使用ObjectInputStream或ObjectOutputStream。

使用严重依赖序列化的库，例如：Xstream、Kryo、BlazeDS和大多数应用程序服务器。

使用这些方法的开发人员应考虑使用其他存储和读回数据的替代方法。EishaySmith发布了几个不同序列化库的性能指标。在评估性能时，需要在基准度量指标中包含安全方面的考虑。默认的Java序列化“更快”一些，但漏洞也会以同样的速度找上门来。

我们该如何降低序列化**的影响?

项目Amber包含了一个关于将序列化API隔离出来的讨论。我们的想法是将序列化从*****移动到单独的模块，这样应用程序就可以完全移除它。在确定JDK11功能集时并没有针对该提议得出任何结果，但可能会在未来的Java版本中继续进行讨论。

通过运行时保护来减少序列化暴露

一个可以监控风险并自动化可重复安全专业知识的系统对于很多企业来说都是很有用的。Java应用程序可以将JVMTI工具嵌入到安全监控系统中，通过插桩的方式将传感器植入到应用程序中。

其他有用的安全技术

在进行维护时，可以不需要手动列出一长串东西，而是使用像OWASPDependency-Check这样的系统，它可以识别出已知安全漏洞的依赖关系，并提示进行升级。也可以考虑通过像DependABot这样的系统进行库的自动更新。

虽然用意很好，但默认的Oracle序列化过滤器存在与SecurityManager和相关沙箱漏洞相同的设计**。因为需要混淆角色权限并要求提前了解不可知的事物，限制了这个功能的大规模采用：系统管理员不知道代码的内容，所以无法列出类文件，而开发人员不了解环境，甚至DevOps团队通常也不知道系统其他部分(如应用程序服务器)的需求。

shiro中User user = (User) *****().getPrincipal();

之前群里有人报这个错，你这样排查一下，你用instanceof
判断下对象，另外你把序列化的id改一下，重启项目，当然你也要排查是不是有把实体打成jar包，多个类，然后序列化id不一样！
推荐一套完整的Shiro Demo，免费的。‍
***隐藏网址***
***隐藏网址***
管理员帐号：admin，密码：***** 如果密码错误，请用*****：你可以注册自己的帐号，然后用管理员赋权限给你自己的帐号，但是，每20分钟会把数据初始化一次。建议自己下载源码，让Demo跑起来，然后跑的更快。

java反序列漏洞，涉及到哪些中间件

　目前oracle还没有在公开途径发布weblogic的J**A反序列化漏洞的官方补丁，目前看到的修复方法无非两条：
　　使用SerialKiller替换进行序列化操作的ObjectInputStream类;
　　在不影响业务的情况下，临时删除掉项目里的 "org/apache/comm***/collecti***/functors/*****"文件。
　　ObjectInputStream类为JRE的原生类，*****为weblogic基础包中的类，对上述两个类进行修改或删除，实在无法保证对业务没有影响。如果使用上述的修复方式，需要大量的测试工作。且仅仅删除*****文件，无法保证以后不会发现其他的类存在反序列化漏洞。

泛微OA反序列化漏洞是什么原因导致的

泛微OA反序列化漏洞是由于泛微OA系统在反序列化用户输入的数据时，没有对数据进行足够的验证和过滤，导致攻击者可以构造恶意的序列化数据，从而实现远程代码执行攻击。具体来说，漏洞出现的原因可能是以下几个方面：

1. 序列化和反序列化的机制存在漏洞。泛微OA系统中可能存在某些不安全的序列化和反序列化机制，攻击者可以利用这些机制构造恶意数据，从而实现代码执行。

2. 输入数据未经过足够的验证和过滤。泛微OA系统中某些功能可能接受用户输入的数据，并将其反序列化，如果没有对输入数据进行足够的验证和过滤，就会导致攻击者可以注入恶意代码。

3. 漏洞修复不及时。泛微OA系统可能存在已知的反序列化漏洞，但是由于种种原因，漏洞修复不及时，攻击者有机会利用这些漏洞进行攻击。

shiro的session信息放redis反序列化异常解决

背景
在本地session移至redis存储时，原本以为引入spring-session-data-redis依赖，配置RedisHttpSessionConfiguration，在*****中引入springSessionRepositoryFilter就结束了，没想到遇到序列化相关的问题，具体就是只有getter，没有setter。日志如下：

分析
提示很清楚，就是shiro的SimplePrincipalCollection类中realmNames字段没有setter方法，没法反序列化。
来看看realmNames是什么鬼，作为成熟的框架也偷懒不写setter？仔细一看，发现并不简单。类里面没有realmNames，只有个getRealmNames方法。
原来是个假getter，是由其他字段动态生成的，如下：

看下redis里面存的值

核心就是*****()和*****()两个方法
SimplePrincipalCollection是需要处理的类，IncludShiroFields就是一个简单的接口，如下：

通过上面的配置间接控制SimplePrincipalCollection类中必要字段的序列化，从而解决了问题。
ps ：因为使用了注解，一定要去掉*****(*****_ANNOTATIONS, false)，不然配置不生效。

Shiro RememberMe ***** 反序列化命令执行漏洞复现

Apache Shiro 《= *****

shiro默认使用了 CookieRememberMeManager ，其处理cookie的流程是：得到 rememberMe的cookie值 --》 Base64解码 --》 AES解密 --》 反序列化 。
然而AES的密钥是硬编码的，就导致了攻击者可以构造恶意数据造成反序列化的RCE漏洞。

前16字节的密钥 --》后面 加入序列化参数 --》 AES加密 --》 base64编码 --》发送 cookie 。

使用大佬脚本生成 payload( ***** 文件和运行目录处于同一目录)
图片.png 图片.png
这里依旧使用docker进行漏洞复现
图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png 图片.png
参考链接：
***隐藏网址***
***隐藏网址***