SpringBoot SpEL表达式注入漏洞-分析与复现
影响版本:
1.1.0-1.1.12
1.2.0-1.2.7
1.3.0
修复方案:升至1.3.1或以上版本
我的测试环境:SpringBoot 1.2.0
0x00前言
这是2016年爆出的一个洞,利用条件是使用了springboot的默认错误页(Whitelabel Error Page),存在漏洞的页面在:/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/ErrorMvcAutoConfiguration.java
0x01触发原因
本次漏洞的触发点在SpringBoot的自定义错误页面,功能是页面返回错误,并提供详细信息,信息中包括错误status("status"->500)、时间戳("timestamp"->"Fri Dec.....")、错误信息("error"->"Internal Server Error")、和用户输入的参数("message"->"abcd"),这些参数在模板文件中以类似于以下形式存在:”Error 1234 ${status}---${timestamp}---${error}---${message}“。
后端进行渲染视图时,首先,解析错误页面模板中的参数名(status、timestamp、error、message),即判断模板中每个${的位置,然后再判断最近的}的位置,从而将参数名一个个读取出来,然而这里使用了递归,也就是说如果参数名中还包含${和}的话,这个解析引擎会再次递归一次,再次解析这个值,如,模板中有个值为${${abc}},由于使用了递归,解析引擎会对其解析两次,第一层去掉最外层的{}解析成${abc},然后将其作为参数进行第二次解析。在第二次解析中将里层的{}去掉,变成abc。
每次将一个参数名解析出来之后,就将参数名传入SpEL引擎,解析成context中对应参数名的值(如"status"->500),完成之后返回参数值给第一步中的解析引擎(返回500)。
解析引擎收到SpEL传回的参数值之后,再次进行递归,以防参数值中也存在${和},存在则去之,然后在递归过程中再次传入SpEL引擎进行解析。这里就是触发点了。假设用户的输入中包含${payload},则SpEL第一次message解析成${payload}之后,解析引擎进行递归,去掉${和}后将payload传入SpEL引擎,SpEL引擎将将直接对payload进行解析,从而触发了漏洞,触发点如下图所示。
0x02调试分析
先搭好存在漏洞的SpringBoot版本的环境,使用其自带的sample搭建一个服务器,然后自己写一个控制器,抛出异常即可。
开启调试,使用浏览器访问
http://127.0.0.1:8080/?payload=${new%20java.lang.ProcessBuilder(new%20java.lang.String(new%20byte[]{99,97,108,99})).start()}
首先,将context赋值到this.context中,然后以this.template和this.resolver为参数调用replacePlaceholders方法。
this.template="<html><body><h1>Whitelabel Error Page</h1><p>This application has no explicit mapping for /error, so you are seeing this as a fallback.</p><div id='created'>${timestamp}</div><div>There was an unexpected error (type=${error}, status=${status}).</div><div>${message}</div></body></html>"
跟进replacePlaceholders方法,进入了PropertyPlaceholderHelper文件
继续跟进parseStringValue方法(这就是分析中说的存在递归的方法),strVal的值为之前的this.template,将之赋值给result,然后通过判断result中${和}的位置,开始解析result中的第一个参数名,并赋值给placeholder,本次的值为"timestamp",然后将placeholder作为第一个参数,再次调用本方法(递归,以防字符串placeholder中包含${})。
跟进递归,由于placeholder的值为"timestamp",其中不包含${,导致startIndex为-1,故不进入while语句,直接到了return,因此可以发现,在递归时,如果第一个参数中不包含${,则直接将第一个参数返回。
再次回到之前的点,下一步是调用resolvePlaceholder方法,此函数的作用是查找this.context中对应参数的值并返回,跟进看一下
首先看一下this.context,发现"timestamp" -> "Sat Dec 15 10:49:02 CST 2018"
继续跟进,发现value被赋值成SpEL解析后的值,然后return
回到parseStringValue方法,将经过SpEL解析后return的值赋值给propVal,由于propVal != null,故跳过第一个if语句,进入第二个语句,将propVal作为第一个参数再次递归。通过上一次递归我们发现,如果第一个参数中没有${,则直接返回第一个参数的值,因此这次就不再跟进了。
递归回来后propVal的值没变,使用replace将propVal替换到result中的对应的参数位。接着寻找template中的下一个参数位,赋值给startIndex,用于下一次while条件判断。
进入第二次循环,这次的参数是error,和之前的timestamp过程一样,就不具体分析了
第三次while循环,参数是status,同上,不具体分析
进入第四次循环,重头戏来啦,这次的参数是message,其值是用户输入的值。
跟进到第一次递归,防止参数名中含有${},由于参数名士message,故略过这一步。然后到了resolvePlaceholder方法,用于使用SpEL表达式引擎解析message的值,再跟进一下。
发现value的值为用户传入的payload
其中包含${},是一个SpEL表达式。继续跟进,返回到parseStringValue方法。
可以发现,为了防止propVal中包含${},再次进行一次递归。下面就是漏洞关键点了,跟进这次递归。
此时placeholder的值为去掉${}的payload,即:"new java.lang.ProcessBuilder(new java.lang.String(new byte[]{99,97,108,99})).start()"。将placeholder作为第一个参数传入SpEL解析函数(147行)
可以发现,这里直接使用parseExpression(name),而name的值就是我们的payload。接着使用getValue解析payload:
Expression expression = this.parser.parseExpression("new java.lang.ProcessBuilder(new java.lang.String(new byte[]{99,97,108,99})).start()");
Object value = expression.getValue(this.context);
然后触发payload,漏洞利用完成。
0x03补丁分析
补丁创建了一个新的NonRecursivePropertyPlaceholderHelper类,用于防止parseStringValue进行递归解析。
0x04参考文章
Spring Boot框架Whitelabel Error Page SpEL注入漏洞分析
SpringBoot SpEL表达式注入漏洞-分析与复现的更多相关文章
- SpEL表达式注入漏洞学习和回显poc研究
目录 前言 环境 基础学习和回显实验 语法基础 回显实验 BufferedReader Scanner SpEL漏洞复现 低版本SpringBoot中IllegalStateException CVE ...
- SpringBoot框架SpEL表达式注入漏洞复现与原理分析
前言 这是2016年的一个洞,利用条件是至少知道一个触发 springboot 默认错误页面的接口及参数名. 影响版本:1.1.0-1.1.12 1.2.0-1.2.7 1.3.0 修复方案:升级版本 ...
- [CVE-2014-3704]Drupal 7.31 SQL注入漏洞分析与复现
记录下自己的复现思路 漏洞影响: Drupal 7.31 Drupal是一个开源内容管理平台,为数百万个网站和应用程序提供支持. 0x01漏洞复现 复现环境: 1) Apache2.4 2) Php ...
- [CVE-2017-5487] WordPress <=4.7.1 REST API 内容注入漏洞分析与复现
记录下自己的复现思路 漏洞影响: 未授权获取发布过文章的其他用户的用户名.id 触发前提:wordpress配置REST API 影响版本:<= 4.7 0x01漏洞复现 复现环境: 1) Ap ...
- Nexus Repository Manager 3(CVE-2019-7238) 远程代码执行漏洞分析和复现
0x00 漏洞背景 Nexus Repository Manager 3是一款软件仓库,可以用来存储和分发Maven,NuGET等软件源仓库.其3.14.0及之前版本中,存在一处基于OrientDB自 ...
- Beescms_v4.0 sql注入漏洞分析
Beescms_v4.0 sql注入漏洞分析 一.漏洞描述 Beescms v4.0由于后台登录验证码设计缺陷以及代码防护缺陷导致存在bypass全局防护的SQL注入. 二.漏洞环境搭建 1.官方下载 ...
- PHPCMS \phpcms\modules\member\index.php 用户登陆SQL注入漏洞分析
catalog . 漏洞描述 . 漏洞触发条件 . 漏洞影响范围 . 漏洞代码分析 . 防御方法 . 攻防思考 1. 漏洞描述2. 漏洞触发条件 0x1: POC http://localhost/p ...
- DLink 815路由器栈溢出漏洞分析与复现
DLink 815路由器栈溢出漏洞分析与复现 qemu模拟环境搭建 固件下载地址 File DIR-815_FIRMWARE_1.01.ZIP - Firmware for D-link DIR-81 ...
- PHPCMS V9.6.0 SQL注入漏洞分析
0x01 此SQL注入漏洞与metinfo v6.2.0版本以下SQL盲注漏洞个人认为较为相似.且较为有趣,故在此分析并附上exp. 0x02 首先复现漏洞,环境为: PHP:5.4.45 + Apa ...
随机推荐
- Hashtable源码解析
Hashtable同样是基于哈希表实现的,同样每个元素是一个key-value对,其内部也是通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动增长. Hashtable也是JDK1.0引入的 ...
- J2EE--常见面试题总结 -- (二)
1 Spring拦截器的基本功能是什么? 拦截器是基于Java的反射机制的,是在面向切面编程的就是在你的service或者一个方法,前调用一个方法,或者在方法后调用一个方法比如动态代理就是拦截器的简单 ...
- 大型三甲医院管理系统源码PACS超声科室源码DICOM影像工作站
详情点击查看 开发环境 :VS2008 + C# + SQL2000 功能简介 1.患者登记工作站 集中登记患者基本信息和检查信息,包括就诊方式.患者来源.检查类型.检查部位.申请科室.申请医生等.可 ...
- threesum
算法题 问题描述:在一些给定的数中,找到三个数,他们相加的和是0,并且这三个数的组合是不能重复的 例子: input [-1, 0, -1, 2, 1] Output [[-1, 1 ,0], [-1 ...
- self,和类实例化加不加括号的理解
# class Dog(object): # def talk(self): # print('汪汪~~~') # print(self) # self就是对象,默认将对象传递到类方法,self不需要 ...
- asp.net 六大对象之Request、Response
ASP.NET的六大对象,本质上只是 Context 里面的属性,严格上不是对象. 1.Request-->读取客户端在Web请求期间发送的值 2.Response-->封装了页面执行期后 ...
- Android 开发TCP协议时,报错NetworkOnMainThreadException
设想是通过Android应用连接PC的TCP服务器,通过点击按钮连接服务器, 最终在点击按钮后报错:networkonmainthreadexception 解决办法: 在MainActivity文件 ...
- Data_r_and_w(csv,json,xlsx)
import osimport sysimport argparsetry: import cStringIO as StringIOexcept: import StringIOimpo ...
- 19.QT-事件发送函数sendEvent()、postEvent()
Qt发送事件分为两种 -阻塞型事件发送 需要重写接收对象的event()事件处理函数 当事件发送后,将会立即进入event()事件处理函数进行事件处理 通过sendEvent()静态函数实现阻塞发送: ...
- 基于Kafka Connect框架DataPipeline在实时数据集成上做了哪些提升?
在不断满足当前企业客户数据集成需求的同时,DataPipeline也基于Kafka Connect 框架做了很多非常重要的提升. 1. 系统架构层面. DataPipeline引入DataPipeli ...