Poking holes in your applications with WebSockets
According to MDN web docs, WebSockets makes it possible to open two-way communication (full-duplex communication) between a client and a server without the client asking the server again for a response. The most common applications WebSockets are used for are ones that communicate data in a constant stream without querying the server subsequently for responses. These applications include: Client to client communications such as chat, Monitoring, and maintenance Human Machine Interfaces (HMI) that are used in Industrial Control Systems (ICS) or other SCADA networks, multiplayer games — the list goes on.
The great thing about WebSockets is that most browsers support them natively. The BeEF Framework’s core is built around this protocol in order to keep the victim browser “hooked” into your C&C. Think about it, full duplex communication AND it’s native in all browsers since IE 10? A web security researcher’s wet dream if you ask me.
The Handshake
The initiation of full-duplex WebSocket communication starts with the following request and response:
There are some things that just get thrown out the window when this Handshake occurs. In terms of Authentication and Authorization, there is no implementation in WebSockets to enforce these policies besides the practices that HTTP uses (Basic Auth, Cookies and the like). You can always use you headers such as Origin, User-Agent, and IP address to authenticate but these can easily be manipulated.
How secure are WebSockets Really?
Out of the box, they are not secure at all. There are a multitude of vulnerabilities that can occur with WebSockets such as replay attacks, spoofing, buffer overflows, and sniffing. There can be things that may invoke a buffer overflow, such as parameters that may be send along the connection.
Unencrypted communications such as HTTP suffer from sniffing attacks, WebSockets are no different when using ws:// as a method of transfer. Tools such as Wireshark and tcpdump can easily sniff out the unencrypted traffic.
Things you can do to secure WebSockets
#1: WebSockets over SSL
To prevent sniffing attacks WebSockets included WebSockets over TLS/SSL (wss://), this idea is similar to HTTP and HTTPS.
#2: Authenticate before upgrading/establishing the connection
WebSockets use standard HTTP headers for authentication and authorization. It’s common to look at the Origin header and setup session tokens for authenticated requests. This is how WebSockets authenticate a valid session. Things like a wildcard CORS are it’s worse nightmare as it allows anyone outside of it’s origin to establish connections with the socket. The problem with having an origin only header to authenticate a connection is that it can be easily tampered with.
#3: An implementation to verify an origin
The tragedy of WebSockets and their infancy shows in CORS and SOP, both are not implemented as strictly as they are with HTTP and HTTPS connections. Due to this reason you can effortlessly establish a connection with a server outside of your origin. On the server-side, you will need to implement a feature such as a nonce or adding metadata information such as timestamp, IP, and/or user ID to ensure the request is genuine BEFORE the WebSocket upgrade.
#4: Use Rate Limiting for multiple server requests
A vector of attack that has always been popular is your average DDoS attacks. They occur in a variety of flavors from your simple ICMP packet floods to flooding memcached servers with spoofed requests as seen in the biggest DDoS in history. WebSockets provide a vector to DoS a server by flooding your server with Socket requests to the point your socket dispatcher may crash. Again, all is subject to how the server-side WebSocket dispatcher is configured. An example of how easy it can be to establish connections with a WebSocket server is shown below.
Securing the establishment of the connection is one thing but how can we take it a step further to protect the assets the client is talking to? Applications that are deploying WebSockets are going to be interfaced with on a regular basis, so authorization past authentication needs to be deployed.
In security, we believe in the idea of security in layers. What can happen when your Web Application Firewall is bypassed? There might be a zero-day associated with your WAF also. An example of why layered security is so crucial can be seen from the recent Impreva Breach.
Sure, you can throw on a cybersecurity silver bullet solution to secure WebSockets, but the brittle foundation in which the internet has built itself on is crumbling. It will not surprise me if the next “big” 0-day exploit is related to this technology.
Thank you for reading
— 💮💀💮
