CVE-2020-5421 的复现和检测方法说明

VMWare于2020-9-17日电光火石间公布了CVE-2020-5421，但对复现和检测方法并未提及，只是简单说明它是Spring framework在修复CVE-2015-5211方案中遗留的、可以通过jessionId参数绕过修复实施攻击的漏洞。随后才发现Spring framework 在9月15日已默默然的发布了四个版本( 5.2.9, 5.1.18, 5.0.19, and 4.3.2) 对它进行了修复。

虽咨询过安全检测专业人士，但对怎样复现问题和对补丁怎样检测并未得到明确的解答。经过结合代码的分析和不断的尝试，最后终于发现了复现和检测的方法（具体步骤是亲测的，可以在后续补写说明）。但为了能与关注此漏洞的共享和交流，对方法在此先做简要说明，也希望得到更专业或官方的信息指导。

前情提要: 对CVE-2015-5211完成修复的版本，通过对url的解析识别其中带有的文件名称，并根据扩展名判断是否是安全的，如果不在白名单、也不是"协商许可"的类型、且不是业务应用明确使用的文件类型，将在Response Header中增加

"Content-Disposition: inline;filename=f.txt"

强制如果产生了文件下载，文件名称会被固定为f.txt, 以避免触发执行而对客户端造成损害。所以在访问url时，以

;setup.cmd?

的方式进行访问，以做攻击时会看到返回的Response Header 的Content-Disposition 中设置了如前述的信息。(该方法可以判断所用的spring版本是否做过CVE-2015-5211的修复。)

复现和检测方法: 本次漏洞所能绕过的途径是通过如下方式攻击实现的

;jsessionId=xxxxxxxsd&setup.cmd?

这是发现仅修复CVE-2015-5211后的版本输出的Response Header 中未出现"Content-Disposition: inline;filename=f.txt" ，经在页面中用html5的标签

，即可产生下载且文件名称为setup.cmd,这说明成功绕过了CVE-2015-5211的修复。作为反证，"jsessionId=" 是关键字，如果破坏了，也不能达到绕过。

最后声明一下： 公开的目的仅是为了方便关注该漏洞的同行进行问题修复和检测作为参考，如果用于其它目的责任自负。(从对该漏洞的认知及其所依赖的攻击时依赖的方法看，能造成危害的概率已属于毫末了，这个计划在后续会讨论)

[返回]： 关于CVE-2020-5421 想说的一些事
[下一篇] CVE-2020-5421 的复现和检测方法探寻

参考:

• CVE-2020-5421
• Spring Framework 5.2.9, 5.1.18, 5.0.19, and 4.3.29 available now