WebSocket cross-site hijacking full control of sessions

WebSockets is an HTML5 feature that provides full-duplex channels for a single TCP connection. Its persistent connection function makes it possible to build real-time applications in B/S mode. Websockets is often used in WEB applications with chat functions.

The following figure illustrates the websockets used by an APT attack:

Little Science:

Same origin policy: the Same origin policy refers to the Same domain name, protocol, and Port. In other words, the browser checks the different tabs of the Same browser and the scripts with the Same source can be executed across tabs.

Origin field: the browser may add an Origin field when sending a POST request. This Origin field is mainly used to identify where the initial request was initiated. If the browser cannot determine where the source is, the value of the Origin field in the sent request is null.

IronWASP: an open-source WEB testing platform that allows users to customize security scanning and customize plug-in systems using python/ruby. See: http://www.freebuf.com/tools/32948.html

ZAP (Zed Attack Proxy) is a penetration testing framework integrated with a variety of tools, can be found in the WEB application vulnerabilities, see the introduction: http://www.freebuf.com/tools/5427.html

WebSocket security assessment

Recently, we have evaluated the security of a WEB application with complex menu options and functions. Most of the operations in this application use web-sockets, which means that most of their behaviors are not recorded in the http proxy log.

First, after we open the homepage, the website will load a static webpage with JS scripts and CSS files. After that, the communication will change to the Websockets mode, and a websocket connection will be established between the browser and the server to load all the HTML resources visible to the website. When you click the link or submit a Form, the browser will send some WebSocket messages to the server. After the server processes these messages, it will use WebSocket for feedback, and then the client browser will display new HTML content.

At this time, when a websocket message is interacting, the number of communications is very large. There is a Heartbeat packet interaction between them every second. However, the existing tools cannot meet my requirements. I have to add a Websocket message analysis device and a WebSocket client to IronWASP so that it can identify Websocket and try to fuzz its vulnerability. You can learn more here.

When I tested this application, I found that it had the Cross-Site WebSocket Hijacking Vulnerability (pioneered by christian schneider ). Of course, I will explain the impact of this vulnerability before introducing you to the test method. Before testing the relevant Websockets applications, we need to prepare them first.

Test preparation for cross-site hijacking of WebSocket

You should understand that the same-origin policy (SOP) will not be enforced on websockets through a browser (SSL-protected pages in the same browser will not pass non-SSL WebSocket ), the application we tested uses http cookies as session authentication. The messages sent by WebSocket through the browser do not have Session IDs or random parameters.

In this way, if a user logs on to a WEB application with a vulnerability and then opens a http://attacker.com (Attacker's website) in the same browser, http: // attacker.com you can try to establish a WebSocket connection with the application server through the vulnerability application, and then send a request packet with a valid authentication Session ID through the browser. Therefore, the WebSocket connection established by the attacker's website will have the same permissions as the application itself.

Because the entire application runs on the basis of websockets, hijacking WebSocket is equivalent to hijacking the user's session. Therefore, this vulnerability is essentially the same as the stored XSS vulnerability.

If you think this is terrible, would you be surprised when you hear that WebSocket cross-site scripting can even implement remote code execution on the user system in some cases? See the case of IPython Notebook.

Before testing, you must first check whether the application has WebSockets. Fortunately, this is very simple, and you only need to know the following three points:

1. WebSocket URL connections generally start with ws: // or wss.

2. Check the Origin header of the connection. The webpage may be a WebSocket link established through the Origin field.

3. In messages sent between the browser and the server, we can check the characteristics of common WebSocket connections.

The following figure shows how to obtain the Origin field value and WebSocket URL value through the IronWASP log.

Once you get this information, you can use some special methods to detect Cross-Site WebSocket Hijacking. Here are three simple examples:

Use agent software (such as Burpsuite ):

It must be mentioned that burpsuite can capture and record WebSockets messages. ZAP and IronWASP are the software I know and can replay websocket requests.

In burpsuite, we cannot replay the websockets message, but we can still check whether the WebSocket handshake packet is successful under limited conditions. For testing, we need to analyze the upgrade request packages of websocket: they will be sent over http or https, so they can be replayed.

The following screenshot shows the record of the burpsuite Repeat tab, which shows the valid requests and responses for websocket connections:

To test this vulnerability, we need to send another request packet with the duplicate Origin header. If the "101 Web Socket Protocol Handshake" flag exists in the response packet, this indicates that WebSocket has been successfully established.

If the connection fails, the application does not have this vulnerability because it rejects external WebSocket connections. After successful establishment, we can start the next test to see if the application has the WebSocket cross-site Hijacking Vulnerability. It should be noted that even if a connection has been established, it also needs to be normally connected to the Origin. After confirming that the server responds to the WebSocket message, it can prove that the application has a vulnerability. This is because the developer may enable Origin detection and connection permission authentication at the same time. Therefore, we may encounter the following situation in our experiment: the established connection can be maintained, but the Origins with external sources will not pass authentication.

ZAP can replay WebSocket messages, but as far as I know, it cannot change the Origin header. The following describes how to obtain more things through CSWSH (WebSocket cross-site hijacking.

Online test tool for cross-site hijacking using WebSocket

Open the WEB application you want to test and log in to it, open a new tab in the same browser, access the http://ironwasp.org/cswsh.html (simulated hacker website), enter the URL address of the WebSocket, click Connect on the webpage. Once a connection is established, you can send messages to the WebSocket server through this page. We need to replay the message sent by a valid session and view the server response packet.

If the server-side response is the same as the normal package sent by the previous valid session, it indicates that the application may have the WebSocket cross-site Hijacking Vulnerability.

Use IronWASP

IronWASP can achieve more, even the most basic detection can also provide automated script checks.

Use IronWASP WebSocket client

The server side used to test the Origin method above is the http://ironwasp.org. If you want to set the Origin value more flexibly, you can use the IronWASP client function. It allows you to customize the Origin value to test WebSocket connections.

Client functions may be used in the following environments:

121. The application allows WebSocket connections from open origins.

2. The application allows Origin field values from localhost and intranet IP addresses

This method is used to facilitate internal testing of developers and applications. By using the IronWASP client, you can try whether the intranet IP address or localhost can take effect as the Origin. If you can, you can use this vulnerability in a real environment. For example, if an application allows http:/127.0.0.1: 8080 as the Origin field, we can do this: if the victim has a WEB application running on the local port 8080, in addition, it has the cross-site scripting vulnerability. If these conditions are met, hackers can first perform cross-site attacks on the WEB application, and then establish a WebSocket connection to the target application server:

Use IronWASP's WebSocket API for automated detection

If you need to use localhost or intranet IP address to test the Origin header, using client scripts for automatic detection will make your operations easier. IronWASP allows you to write custom scripts using Python or Ruby.

The following script can separately check the intranet IP address filled in the Origin header and test whether the server recognizes the IP address:

Import clr
Clr. AddReference ("WebsocketClient.exe ")
From WebsocketClient import *
Def check_conn (origin ):
Print "Testing origin-" + origin
Ws = SyncWebsockClient ()
Ws. Connect ("ws: // tatgetapp.com/ws", origin, "SessionID = KSDI2923EWE9DJSDS01212 ")
Ws. Send ("first message to send ")
Msg = ws. Read ()
Ws. Close ()
If msg = "message that is part of valid session ":
Print "Connection successful !! "
Return True
Else:
Return False
Def check_nw ():
For nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]:
For ip in Tools. NwToIp (nws ):
If check_conn ("http: //" + ip ):
Break
Check_nw ()