freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

CVE-2022-22978 Spring-security 认证绕过漏洞分析和漏洞挖掘思考
2022-09-07 13:49:54
所属地 北京

前言

在此之前,已经对CVE-2022-32532  Apache Shiro RegExPatternMatcher 认证绕过漏洞进行了分析,它和CVE-2022-22978漏洞产生原理上,本质是一样的。在分析这两个漏洞后,结合今年kcon议题《自动化API漏洞Fuzz实战》,产生了对漏洞挖掘关注点的一些思考。

CVE-2022-22978 Spring-security RegexRequestMatcher 认证绕过漏洞分析

漏洞描述

当Spring-security使用 RegexRequestMatcher 进行权限配置,由于RegexRequestMatcher正则表达式配置权限的特性,正则表达式中包含“.”时,未经身份验证攻击者可以通过构造恶意数据包绕过身份认证。

影响版本

Spring Security 5.5.x < 5.5.7

Spring Security 5.6.x < 5.6.4

环境搭建

使用github上的漏洞环境(https://github.com/XuCcc/VulEnv/tree/master/springboot/cve_2022_22978)

漏洞分析

具体漏洞产生的原理分析可参考CVE-2022-32532  Apache Shiro RegExPatternMatcher 认证绕过漏洞

构造的漏洞应用场景。

创建一个Controller,自定义接口。

通过正则表达式添加认证配置。

在访问/admin/{name}接口时,需要认证才能访问。

因为之前对CVE-2022-32532  Apache Shiro RegExPatternMatcher 认证绕过的分析,此次很快就将漏洞点定位在spring-security-web-5.6.3.jar中。

org.springframework.security.web.uti.matcher.RegexRequestMatcher#matchers

request.getServletPath()会对字符解码 并且会将;之后的字符到/字符删除,随后通过getServletPath获取URL,尝试提取?后的参数进行拼接,然后使用正则表达式匹配。

联想到在HttpServletRequest中URL解析函数中利用;进行权限绕过的场景:

其中HTTPServletRequest中对URL路径的几种解析方法。

request.getRequestURL():返回全路径;
request.getRequestURI():返回除去Host(域名或IP)部分的路径;
request.getContextPath():返回工程名部分,如果工程映射为/,则返回为空;
request.getServletPath():返回除去Host和工程名部分的路径;
request.getPathInfo():仅返回传递到Servlet的路径,如果没有传递额外的路径信息,则此返回Null;

当认证接口使用getRequestURI()或getRequestURL()函数来解析用户请求的URL时,若URL中包含了一些特殊符号,如分号;就可能产生限制绕过。

而在spring-security中,存在StrictHttpfirewall机制默认对特殊字符进行过滤,所以使用/admin/..;/1这种方式也就无法绕过。

不过在之前分析shiro认证绕过也提到,在正则表达式中元字符“.”是匹配除换行符(\n、\r)之外的任何单个字符,在java中的正则默认情况下“.”也同样不会包含\n、\r字符,所以RegexRequestMatcher在进行正则匹配时不会处理\n、\r

在spring-security中利用换行符可实现权限认证进行绕过,\r的URl编码为%0d,\n的URL编码为%0a

这样的绕过方式也和CVE-2022-32532  Apache Shiro RegExPatternMatcher 认证绕过如出一辙。

漏洞复现

访问/admin/1会302跳转至登陆页面进行权限验证。

使用/admin/1%0d%0a,成功绕过登陆认证。

漏洞挖掘的思考

因为我自己是在分析了CVE-2022-32532后再分析CVE-2022-22978,也在用正则匹配流量的过程中发现过正则“.”号不匹配换行符的问题,在拜读了CVE-2022-32532发现者分析文章,了解了其发现漏洞的过程。

高效的漏洞挖掘方法

从漏洞分析的角度来讲,CVE-2022-32532 和CVE-2022-22978的原理其实很简单,那从漏洞发现和挖掘上看,在了解了类似于CVE-2022-22978这样的安全漏洞后或者是其他的过程发现一些特性,拓展到其他框架或组件中去寻找类似的安全问题,构造利用场景,这是无疑一种高效挖洞的方法。一些未知由语言特性、机制特性等引发的安全漏洞,也等着我们去发现和研究。

在这样的背景下,结合今年KCon《自动化API漏洞Fuzz实战》议题介绍的自动化API漏洞 Fuzz方案,让我觉得API由于本身的特性和发展,以及产生的安全问题,也会逐渐成为漏洞挖掘中一个重要的关注点。

API特性与发展

简单介绍下,API本质上是一种跨语言、跨架构的数据传输约定,API连接了不同层次、不同编程语言、不同厂商 所研发的软件,让数据可以跨应用软件进行自由流动。

API本身的概念,这里不用做过多介绍。大多数人关注API安全可能在于数据隐私保护方面,这也是API安全近几年崛起的主要原因之一,对于攻击者而言,攻击API从而获取系统权限或者数据的成本也是极低的。

看得出API也在这个万物互联互通的时代正高速发展。

浅谈自动化API Fuzz到高危漏洞挖掘

API本身的会存在涉及到各种安全风险,而其大部分安全问题可进阶利用,产生危害更大的安全问题。

通过自动化API fuzz,发现API的安全漏洞,再对这些漏洞可以进一步挖掘和利用,例如通过API未授权漏洞、权限绕过、安全性错误配置等,进一步挖掘文件上传、命令执行等等漏洞。

API Fuzz流程。

当然,通过API Fuzz挖掘漏洞在SRC挖掘的过程中,同样适用。具体可参考https://mp.weixin.qq.com/s/MCtwiT93Fo9Js9ekuD-8wA中的实际案例。

在如今安全研究漏洞挖掘卷到飞起的天下,挖掘高危漏洞,安全研究员除了自身扎实的基础、丰富的漏洞经验外,可能有时还需要一点运气或灵感。通过自动化API Fuzz去挖掘新的高危漏洞的方式,也可以成为一个新的卷点。

参考材料

1.https://mp.weixin.qq.com/s?__biz=Mzg3NDcwMDk3OA==&mid=2247484068&idx=1&sn=89ea1b1be48a0cb7f93a4750765719d1&chksm=cecd8b79f9ba026f7fbf52771e41272d684fc3af5175587f768082f8dbaee12d6d33bb892ceb&scene=126&&sessionid=1662041689#rd

2.https://xz.aliyun.com/t/11501#toc-2

3.https://mp.weixin.qq.com/s/GiQJj2iD3ta8ltsHX9fYJw

4.https://github.com/XuCcc/VulEnv/tree/master/springboot/cve_2022_22978

# 网络安全 # 漏洞分析 # 企业安全
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录