freeBuf
主站

分类

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

特色

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

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

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

FreeBuf+小程序

FreeBuf+小程序

S2-066漏洞分析与复现(CVE-2023-50164)
2024-03-20 09:20:45

Foreword

自struts2官方纰漏S2-066漏洞已经有一段时间,期间断断续续地写,直到最近才完成。羞愧地回顾一下官方通告:

image.png

2023.12.9发布,编号CVE-2023-50164,主要影响版本是 2.5.0-2.5.32 以及 6.0.0-6.3.0,描述中提到了文件上传漏洞和目录穿越漏洞。开始以为这是个组合漏洞,其实不是,这是一个漏洞,看了几篇大佬的文章,有的把它称为“文件上传目录穿越漏洞”,也有道理。

Prepare

准备工作就是搭建项目,用Tomcat跑,调试好断点,回顾下struts2的结构。篇幅有限,这里只贴一张struts2自身的配置文件:

image.png

struts2有众多的Filter和Intercepter,它的配置逻辑是,除文件中定义的class、package以外,其余全部拦截。对于S2-066,处理一个请求要经过的几个关键类包括Dispatcher、Interceptor、HttpParameters以及UploadAction。使用下面的poc:

cda10716c5804ad293daf6ae5c7ed9a.png

Dispatcher

请求首先会进入著名的Dispatcher。multi参数对应的就是body数据,包含upload、fileName、contentType三个变量,无误:

image.png

request中还有一个参数,uploadFileName=../../z127.txt,这个是污染参数,文件上传的目的地,也是利用这个漏洞的目标。

image.png

走到这里Dispatcher只是简单处理一下请求然后交给Interceptor,无异常。

FileUploadInterceptor

拦截器先是把request包装了一下,类型是MultiPartRequestWrapper。

image.png

这里与Dispatcher一样,请求参数还是multi和request两部分,也无异常。

image.png

并且遍历只有一次 ,因为真正的body只有一个,就是那个multi。

image.png

在遍历过程中struts2还出现了硬编码现象,要求文件名参数必须以FileName结尾,且拼接完成的文件名前缀就是body中的{upload}名称,这就给exp带来了一定限制:

image.png

此外,注意这里的279行:

// get the name of the file from the input tag
String[] fileName = multiWrapper.getFileNames(inputName);

使用的是MultiPartRequest接口的方法,而这个接口在S2-066中是由JakartaMultiPartRequest实现。使用下面这个poc进行目录穿越并断点检测一下:

image.png

发现目录穿越失败,文件没有放在指定目录下。分析源码:

image.png

参数覆盖原本想用../../z126.txt,方法的输入参数确实也是这样接收的,但在这个方法中struts2会对文件名进行截断,最终输出的文件名会变为 z126.txt,文件也就不会出现目录穿越的现象。因此目录穿越不是发生在这里,让struts2自己背这个锅多少有点冤。body中的数据组装完毕是下面这样,size等于3,依旧无误:

image.png

HttpParameters

来到HttpParameters查看接收的参数,还是upload、contentType、fileName三个:

image.png

但是参数接收完后就不正常了,除了原本的UploadFileName(注意首字母是大写),还多了一个uploadFileName(注意首字母是小写),size也变成了4。这就是Struts2官方所解释的大小写敏感,即对大写的Upload和小写的upload分别做处理。从这里开始,S2-066才露出真正面目:

image.png

HttpParameters实现了Map接口,所以本质上它还是一个map,这也是组装参数最常用的方式。但不管是HashMap还是TreeMap,自己不会出现覆盖的问题。用一个小实验证明:

image.png

走到这里,HttpParameters对参数的处理开始出现异常,但依然没有发生覆盖。

UploadAction

终于到Action了。引用一段struts2官方的描述:

An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution.

通过操控上传参数,黑客能够出发目录穿越漏洞,这样一来,在某些情况下可以上传恶意文件,从而进行RCE。换种说法,S2-066是框架自身、软件工程师、Java反射机制共同作用的结果。走到这里,为了简化代码,UploadAction即是Action又是Entity。而在Entity的实例化过程中,必然是通过setXX属性来赋值。所以就有了setUploadFileName(注意首字母大写)和setuploadFileName(注意首字母小写)的需求 。而在Entity的setter与getter中,这两种需求都会被当做一种,即setUploadFileName,因此覆盖也就发生了。正常情况下实例化方法只走一遍,如contentType:

image.png

而setUploadFileName第一遍是z106.txt:

image.png

第二遍是../../z127.txt:

image-20240319143952102

实例化完成后,uploadFileName属性已被覆盖:

image.png

查看物理路径,上传成功:

image.png

POCs

参数不是filename结尾,失败:

5e69d76ba4a0c6e60e5fd410a53f9a1.png

参数不符合FileName大小写要求,失败:

674bb93cd91ae101fbb3cf77c13629c.png

大写覆盖小写失败:

ab7ee0ad28107ef1a8569beca2091a2.png

大写覆盖大写失败:

31b60ab46f1b93332c0cd5ecc3ce11f.png

小写覆盖小写失败:

9a5feb70097b8fd64c922676ab5cc17.png

小写覆盖大写成功,文章开头所用。另外覆盖也可以放在body中:

61f40e5da8a7488a8156c1e8897df3f.png

验证:

8da6d33b7bf1dc08e644433d86e0dde.png

利用条件多少有点苛刻,但杀伤力不输struts2过去那一堆,CVSS3.0评分9.8,CRITICAL。

capture_20240114164504492.bmp


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