Ocelot WebSocket Security Bypass via Missing Middleware

Executive Summary

This vulnerability exists in Ocelot versions up to 24.1.0 and allows clients that are supposed to be blocked by IP-based access restrictions to bypass these controls by sending WebSocket upgrade requests.

The root cause is that the WebSocket upgrade pipeline in Ocelot is handled separately from the main HTTP request pipeline and does not include the SecurityMiddleware that enforces IP allow/block lists.

As a result, blocked IP addresses can still establish WebSocket connections to downstream services, circumventing the intended security restrictions.

Useful 0 Not Useful 0

Impact Analysis

An attacker from a blocked or unauthorized IP address can exploit this vulnerability to bypass IP filtering and access protected downstream WebSocket services.

This unauthorized access could lead to compromise of confidentiality and integrity depending on what the downstream WebSocket services expose or allow.

Because the IP restrictions are not enforced on WebSocket upgrade requests, sensitive services might be exposed to unauthorized clients, increasing the risk of data leakage or unauthorized actions.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by monitoring WebSocket upgrade requests from IP addresses that are supposed to be blocked or denied by your IP allow/block list configuration in Ocelot.

Specifically, you should look for WebSocket upgrade requests (HTTP headers containing 'Upgrade: websocket') originating from IPs that are on your blocked list but still successfully establishing connections.

Commands to detect this might include network traffic inspection tools or logs analysis to identify such bypass attempts. For example:

• Using tcpdump or tshark to filter WebSocket upgrade requests from blocked IPs: tcpdump -i <interface> 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 and src host <blocked_ip>'
• Using grep on Ocelot access logs to find WebSocket upgrade requests from blocked IPs: grep 'Upgrade: websocket' <ocelot_access_log> | grep '<blocked_ip>'

Additionally, check if blocked IPs are receiving HTTP 403 Forbidden responses for WebSocket upgrade requests. If they are not, it indicates the vulnerability is present.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability immediately, you should update Ocelot to a version that includes the fix from commit f156fd4 or later, where SecurityMiddleware is applied to the WebSocket upgrade pipeline.

This fix ensures that IP allow/block lists are enforced consistently for both HTTP and WebSocket requests, preventing unauthorized IPs from bypassing restrictions via WebSocket upgrades.

• Apply the patch or upgrade to Ocelot version 25.0 or later where the WebSocket pipeline includes SecurityMiddleware.
• Verify that blocked IPs receive HTTP 403 Forbidden responses when attempting WebSocket upgrades.
• Review and update your security policies and configurations to ensure they are applied to WebSocket connections as well as HTTP.

If immediate upgrade is not possible, consider implementing network-level controls to block WebSocket upgrade requests from unauthorized IPs as a temporary workaround.

Useful 0 Not Useful 0