WebSocket connections are vulnerable to numerous attacks. In July 2022, security researchers found a vulnerability in Apache Tomcat CVE-2022-25762. The flaw allows a threat actor to compromise the data of victims.

In another incident, researchers found a WebSocket vulnerability in the infamous Log4j CVE-2021-44228, where an attacker can exploit the vulnerable log4j version using a JavaScript WebSocket connection.

The reports indicate that attackers can target the WebSocket to exploit the application. This article will help you to understand the functionality and the exploitation methods used against WebSocket connections.

What are WebSockets?

WebSockets are full-duplex and bi-directional communication protocols that require HTTP for connection.

The WebSockets operates on the application layer (OSI model - 7), which allows the client and server to deploy dynamic and real-time applications such as live gaming and chatting.

How does WebSockets handshake work?

In most cases, Javascript establishes WebSocket connections on the client side. 

The 'wss' protocol initiates encrypted communication over TLS, while 'ws' uses an unencrypted channel.

Initially, the client established a WebSocket handshake by sending a request to the server over HTTP.

• The 'Connection' and 'Upgrade' headers specify the WebSocket connection.

• The 'Sec-WebSocket-Version' indicates the WebSocket protocol version. If the server is incompatible with the specified one, it responds with the supported version.

• The 'Sec-WebSocket-Key' is a randomly generated base-64 encoded value, which is unique for each handshake.

The server accepts the handshake and returns an "HTTP status 101 Switching Protocol" response status. 

• The 'Sec-WebSocket-Accept' header value uses an algorithm that includes the SHA-1 hash of the "Sec-WebSocket-Key" and GUID (Globally Unique Identifier) concatenated strings. This process helped to mitigate ambiguous responses caused due to misconfigured servers or cached proxies.

In the lateral part, the handshake is completed, which means that the server and client can communicate via WebSockets in either direction.

WebSocket message format

The client-side browser uses javascript to craft a simple message, which looks like this:

ws.send("John Doe");

As modern applications require work on JSON, WebSocket messages are compatible with the transit of structured data.

{"user":"John Doe","content":"Follow VSociety for amazing Cybersecurity content"}

WebSocket versus HTTP

When a browser and a server communicate, they mostly use a half-duplex stateless protocol known as HTTP. While using HTTP, the client generates the request and then waits for the response from the server. 

While WebSockets use a full-duplex mode for communication initiated over HTTP, the connection stays alive as long as the application is running. 

Vulnerabilities in WebSocket

A threat actor can target the WebSocket in a multitude of ways. Some of the most common flaws and exploitation methods are:

• Improper Authorization and Authentication 

The WebSocket does not have a pre-defined method to check the integrity of the user. The Application-level protocol performs a separate check for identification.

• Sniffing attack

The data transmitted over the 'ws' protocol is vulnerable to sniffing attacks, which means an attacker can perform a man-in-the-middle attack and leak the sensitive information. For protection against attacks like sniffing, it is encouraged to use the 'wss' protocol, which transmits the data over TLS.

• Denial-of-Service attack

The WebSocket allows a large amount of connection to reach the server. A hacker can take advantage of this and launch a Denial-of-Service or DoS attack by flooding the server with unwanted data.

WebSocket exploitation

For a clear understanding of WebSocket exploitation, let's comprehend multiple attacks by picking an excerpt from the Mr. Robot series.

Elliott Alderson, the main protagonist, is preparing to tackle the biggest hacking group in the world called the Dark Army.

Manipulating WebSocket messages

The initial step is to visit the website (darkarmy.com) and analyze the workflow to find the potential break-in ways.

Elliot finds a chat option. The next step is to fire the Burpsuite and intercept the traffic between the server and his browser. Elliot scrutinizes the intercepted data and figures that the application is running WebSockets for communication.

After transmitting and inspecting the messages, Elliot understood the encoding method performed on the client side. The final step is to prepare the payload, which looks like this.

The 'onerror' event in the payload is triggered when the 'img' tag fails to load the image from its source.

Elliot modifies the request, forwards the payload, and observes the alert trigger in the browser. The attacks prove that the Dark Army live chats are susceptible to WebSocket manipulation attacks.

Exploiting the WebSocket handshake

The Dark Army has patched the previous vulnerability, but Elliot still ponders and finds another way to target the application.

Elliot first uses the previous payload in the 'Repeater' tab of Burpsuite. According to portswigger, "Burp Repeater is a tool that enables you to modify and send an interesting HTTP or WebSocket message over and over."

Upon careful observation, Elliot figures that his attack is blocked, and the Dark Army has banned his IP address, which means he cannot initiate further communications with the server.

Elliot spoofs the IP address by adding an XFF (X-Forwarded-For) header to the handshake request. The XFF request header identifies the originating IP address of a client while connecting to a web server through a proxy.

The header request looks like this, and the IP address (1.1.1.1) is the fastest DNS resolver used by Cloudflare.

Now Elliot can reconnect with the Dark Army chat as he has spoofed the IP address successfully. In the lateral part of the attack, he creates an obfuscated XSS payload inside an iframe to bypass any limitation placed by the enemy.

The iframe is an HTML element that embeds another document inside the current HTML document. 

Security methods and mitigations 

To minimize the security threats against WebSockets, follow the pivotal guidelines. 

• The application should use the encrypted 'wss://' protocol over the unencrypted 'ws://' to protect against the man-in-the-middle attack.

• The anti-CSRF tokens, such as X-CSRF-Token, protect the WebSockets against cross-site hijacking attacks.

• The origin header detects the source of the request. The request header warns the server if the origin is not trustworthy. The server takes necessary action and protects the application against cross-origin attacks.

• Sanitizing the user input adverts the input-based attacks such as XSS, SQL injections and 

Conclusion

The usage of WebSockets among various applications is prolific due to its dynamic and agile nature. But the recent CVE and the security incident warn that the WebSocket vulnerability is a severe threat and proper remediation is required.

#CVE-2022-25762 #vicarius_blog #exploitation