900字范文 > Spring Messaging 远程代码执行漏洞分析（CVE--1270）

Spring Messaging 远程代码执行漏洞分析（CVE--1270）

时间：2021-11-27 17:32:30

文章目录

Spring Messaging 远程命令执行漏洞（CVE--1270）相关知识WebSocket、SockJS和STOMPSTOMP的消息结构和示例Spring Messaging 漏洞分析PoC漏洞修复参考

Spring Messaging 远程命令执行漏洞（CVE--1270）

漏洞公告：

/security/cve--1270

影响版本：

Spring Framework 5.0 to 5.0.4Spring Framework 4.3 to 4.3.15Older unsupported versions are also affected

环境搭建：

/spring-guides/gs-messaging-stomp-websocket
执行git checkout 2.0.0.RELEASE切换版本，该版本使用了存在漏洞的spring-messaging:5.0.4

相关知识

在分析这个漏洞之前，这里简单介绍相关的一些概念。详细内容请阅读文末罗列的参考资料。

WebSocket、SockJS和STOMP

WebSocket：是 HTML5 新增加特性之一，目的是浏览器与服务端建立全双工的通信方式，解决 http 请求-响应带来过多的资源消耗，同时对特殊场景应用提供了全新的实现方式，比如聊天、股票交易、游戏等对对实时性要求较高的行业领域。

HTTP与WebSocket都是基于TCP(传输控制协议)的，WebSocket可以看做是对http协议的一个补充，它复用HTTP/HTTPS的端口。

WebSocket协议提供了通过一个套接字实现全双工通信的功能。除了其他的功能之外，它能够实现Web浏览器和服务器之间的异步通信。全双工意味着服务器可以发送消息给浏览器，浏览器也可以发送消息给服务器。

SockJS：SockJS是一个JavaScript库，为了应对许多浏览器不支持WebSocket协议的问题，设计了备选SockJS。SockJS 是 WebSocket 技术的一种模拟。SockJS会尽可能对应 WebSocket API，但如果WebSocket 技术不可用的话，会自动降为轮询的方式。

WebSocket是一个相对比较新的规范，在Web浏览器和应用服务器上没有得到一致的支持。所以我们需要一种WebSocket的备选方案，而这恰恰是SockJS所擅长的。

SockJS是WebSocket技术的一种模拟，在表面上，它尽可能对应WebSocket API，但是在底层非常智能。如果WebSocket技术不可用的话，就会选择另外的通信方式。

SockJS会优先选择WebSocket进行连接，但是当服务器或客户端不支持WebSocket时，会自动在 XHR流、XDR流、iFrame事件源、iFrame HTML文件、XHR轮询、XDR轮询、iFrame XHR轮询、JSONP轮询这几个方案中择优进行连接。

STOMP：即 Simple Text Oriented Message Protocol——面向消息的简单文本协议。SockJS 为 WebSocket 提供了备选方案。但无论哪种场景，对于实际应用来说，这种通信形式层级过低。STOMP协议，为浏览器和服务器之间的通信增加适当的消息语义。

三者的关系：

简而言之，WebSocket 是底层协议，SockJS 是WebSocket 的备选方案，也是底层协议，而 STOMP 是基于 WebSocket（SockJS）的上层协议。

STOMP和WebSocket（SockJS）的关系，类似于HTTP和TCP。

（1）HTTP协议解决了 Web 浏览器发起请求以及 web 服务器响应请求的细节，假设 HTTP 协议并不存在，只能使用 TCP 套接字来编写 web 应用，那将是一件非常痛苦的事情。

（2）直接使用 WebSocket（SockJS）就很类似于使用 TCP 套接字来编写 web 应用，因为没有高层协议，就需要我们定义应用间所发送消息的语义，还需要确保连接的两端都能遵循这些语义；

（3）同HTTP在TCP 套接字上添加请求-响应模型层一样，STOMP在WebSocket 之上提供了一个基于帧的线路格式层，用来定义消息语义；

WebSocket、SockJS、STOMP三者，从前往后，层级依次上升，就像洋葱，WebSocket在里面，SockJS其次，STOMP在最外面。如果我们使用建立在SockJS协议上的STOMP服务，而SockJS又选择WebSocket作为底层的通信协议。在通信过程中，STOMP帧会被组装成SockJS的帧；SockJS的帧会被组装成WebSocket的帧；再深一点，WebSocket的帧会被组装成TCP的帧；TCP的帧被组装成IP层的帧，然后传输；到远端后执行相反操作。

从分类上说，WebSocket和SockJS都只是通用的数据传输协议；而STOMP是一种消息协议，抽象层级更高。

STOMP的消息结构和示例

STOMP是一种基于帧的协议，其帧基于HTTP建模。STOMP消息帧结构如下：

COMMANDheader1:value1header2:value2Body^@

^@表示字符串结束符\x00

客户端可以使用SEND或SUBSCRIBE命令发送或订阅带有destination请求头的消息，destination描述了消息的内容以及应该接收该消息的人。

在使用Spring的STOMP支持时，Spring WebSocket应用程序充当客户端的STOMP代理。消息被路由到@Controller类的消息处理方法或一个简单的内存中代理，该代理跟踪订阅并将消息广播给订阅用户。你也可以配置Spring使用专用的STOMP代理(例如RabbitMQ, ActiveMQ等)来实际广播消息。在这种情况下，Spring维护与代理的TCP连接，将消息转发给代理，并将消息从代理向下传递到连接的WebSocket客户端。

示例1：客户端订阅股票报价

SUBSCRIBEid:sub-1destination:/topic/price.stock.*^@

示例2：客户端发送交易请求

SENDdestination:/queue/tradecontent-type:application/jsoncontent-length:44{"action":"BUY","ticker":"MMM","shares",44}^@

示例3：服务器发送股票报价给订阅客户端

MESSAGEmessage-id:nxahklf6-1subscription:sub-1destination:/topic/price.stock.MMM{"ticker":"MMM","price":129.45}^@

服务器不能发送未经请求的消息。来自服务器的所有消息都必须响应特定的客户端订阅，且服务器消息的subscription-id请求头必须与客户端订阅的id请求头匹配。

Spring Messaging

Spring Messaging是Spring框架中的一个模块，该模块为Spring框架提供消息支持，其上层协议是STOMP，底层通信基于SockJS。

一旦公开了STOMP端点，Spring应用程序就成为已连接的客户端的STOMP代理（STOMP broker）。

下图显示了基于Spring的消息订阅程序，且使用内置的消息代理（SimpleBrokerMessageHandler）时的消息传递流程：

上图中，有3个消息通道（Channel）:

clientInboundChannel：用于传递来自WebSocket客户端发来的消息。clientOutboundChannel：用于向WebSocket客户端发送服务端消息。brokerChannel：用于从服务器端、应用程序代码中向消息代理（message broker）发送消息。

下面结合本次漏洞复现的示例代码理一下工作流程。

前端：app.js

后端：

WebSocketConfig.java

@Configuration@EnableWebSocketMessageBrokerpublic class WebSocketConfig implements WebSocketMessageBrokerConfigurer {public WebSocketConfig() {}public void configureMessageBroker(MessageBrokerRegistry config) {config.enableSimpleBroker(new String[]{"/topic"});config.setApplicationDestinationPrefixes(new String[]{"/app"});}public void registerStompEndpoints(StompEndpointRegistry registry) {registry.addEndpoint(new String[]{"/gs-guide-websocket"}).withSockJS();}}

GreetingController.java

@Controllerpublic class GreetingController {public GreetingController() {}@MessageMapping({"/hello"})@SendTo({"/topic/greetings"})public Greeting greeting(HelloMessage message) throws Exception {Thread.sleep(1000L);return new Greeting("Hello, " + HtmlUtils.htmlEscape(message.getName()) + "!");}}

(1) 客户端连接http://localhost:8080/gs-guide-websocket进行握手，一旦握手成功，WebSocket连接建立，STOMP消息帧就在此连接上传输。

(2) 客户端发送带有destination: /topic/greetings请求头的SUBSCRIBE消息帧进行消息订阅。服务端接收并解码后，消息被发送到clientInboundChannel，然后路由到存储客户端订阅的消息代理（SimpleBrokerMessageHandler）。

(3) 客户端发送带有destination：/app/hello请求头的SEND消息帧。/app前缀有助于服务端将其路由到带注解的控制器。在/app前缀被剥离后，/hello部分被映射到GreetingController的@MessagingMapping注解的greeting()方法。

(4)GreetingControler返回的值被转换成一个Spring Message，该Message带有基于返回值和destination: /topic/greetings请求头的消息负载。该Message被发送到brokerChannel并被消息代理（SimpleBrokerMessageHandler）处理。

(5) 消息代理（SimpleBrokerMessageHandler）寻找所有匹配的订阅者，并通过clientOutboundChannel向每一个订阅者发送一个MESSAGE消息帧。

漏洞分析

从STOMP协议官方文档（参考[7]）里可看到，STOMP允许客户端在SUBSCRIBE帧添加selector请求头在订阅的消息中过滤出自己想要的消息。

我们以调试模式运行上述应用，在GreetingController#greeting()下断点。在前端页面，先点击Connect按钮（执行WebSocket握手，握手成功后，往destination: /topic/greetings发送SUBSCRIBE帧进行消息订阅），然后在编辑框输入内容，再点击SEND按钮（往destination: /app/hello发送SEND帧），断点命中，调试。

GreetingController#greeting()的返回值被转换为GenericMessage对象，被发送到ExecutorSubscribableChannel，并被消息代理SimpleBrokerMessageHandler处理。

消息代理（SimpleBrokerMessageHandler）要做的，就是寻找所有匹配的订阅者，并通过clientOutboundChannel向每一个订阅者发送一个MESSAGE消息帧。而就是在这个过程中，会根据客户端发送SUBSCRIBE进行消息订阅时添加的selector请求头的内容进行过滤。

漏洞就出在这部分代码，如果前面订阅的时候发送的SUBSCRIBE帧有包含selector请求头，那么这里就会对selector请求头的值进行SpEL表达式求值。

回头看一下发送SUBSCRIBE帧进行的消息订阅操作。

具体的添加订阅操作的代码是在DefaultSubsriptionRegistry$SessionSubscriptionInfo#getSubscription()方法中：

往上函数追溯，可以在DefaultSubsriptionRegistry#addSubscriptionInternal()方法中看到对selector请求头的处理：获取selector请求头的值，对其值进行SpEL表达式解析，得到一个SpelExpression对象。

PoC

["SUBSCRIBE\nselector:T(java.lang.Runtime).getRuntime().exec('open -a Calculator')\nid:sub-0\ndestination:/topic/greetings\n\n\u0000"]

burpsuite可以看到通过WebSocket传输的STOMP消息帧，所以利用burpsuite抓包，在SUBSCRIBE帧中添加selector请求头，其值插入恶意SpEL表达式，然后重放该SUBSCRIBE帧。然后再重放SEND消息帧便可触发RCE。

攻击演示如下gif：

漏洞修复

在Spring5.0.5版本中，消息支持模块spring-messaging的DefaultSubscriptionRegistry#findSubscriptionInternal()方法中，SpEL求值的上下文的位置处，使用权限更小的SimpleEvaluationContext来替换原来的StandardEvaluationContext。