Summary
The application uses WebSocket (with Socket.io), but it does not verify that the source of communication is valid. This allows third-party website to access the application on behalf of their client.
Details
When connecting to the server using Socket.IO, the server does not validate the Origin
header leading to other site being able to open connections to the server and communicate with it.
Other website still need to authenticate to access most features, however this can circumvent reverse proxy or firewall protections made in place by users deploying the application.
PoC
On another origin, you can serve the following HTML document.
<script src="https://cdn.socket.io/4.7.2/socket.io.min.js"></script>
<script>
const socket = io("wss://[TARGET_WEBSITE]", { transports: ["websocket"] });
socket.emit("getGameList", console.log.bind(console))
</script>
Impact
Without origin validation, Javascript executed from another origin would be allowed to connect to the application without any user interaction. Without login credentials, such a connection is unable to access protected endpoints containing sensitive data of the application. However, such a connection may allow attacker to further exploit unseen vulnerabilities of the application.
Users with "No-auth" mode configured who are relying on a reverse proxy or firewall to provide protection to the application would be especially vulnerable as it would grant the attacker full access to the application.
Remediation
Additional verification of the HTTP Origin
header has been added to the socket.io connection handler. By default, if the Origin
header is present, it would be checked against the Host
header. Connection would be denied if the hostnames do not match, which would indicate that the request is cross-origin. Connection would be allowed if the Origin
header is not present.
Users can override this behaviour by setting environment variable UPTIME_KUMA_WS_ORIGIN_CHECK=bypass
.
Summary
The application uses WebSocket (with Socket.io), but it does not verify that the source of communication is valid. This allows third-party website to access the application on behalf of their client.
Details
When connecting to the server using Socket.IO, the server does not validate the
Origin
header leading to other site being able to open connections to the server and communicate with it.Other website still need to authenticate to access most features, however this can circumvent reverse proxy or firewall protections made in place by users deploying the application.
PoC
On another origin, you can serve the following HTML document.
Impact
Without origin validation, Javascript executed from another origin would be allowed to connect to the application without any user interaction. Without login credentials, such a connection is unable to access protected endpoints containing sensitive data of the application. However, such a connection may allow attacker to further exploit unseen vulnerabilities of the application.
Users with "No-auth" mode configured who are relying on a reverse proxy or firewall to provide protection to the application would be especially vulnerable as it would grant the attacker full access to the application.
Remediation
Additional verification of the HTTP
Origin
header has been added to the socket.io connection handler. By default, if theOrigin
header is present, it would be checked against theHost
header. Connection would be denied if the hostnames do not match, which would indicate that the request is cross-origin. Connection would be allowed if theOrigin
header is not present.Users can override this behaviour by setting environment variable
UPTIME_KUMA_WS_ORIGIN_CHECK=bypass
.