Security Vulnerability: Unrestricted Remote Control Access on Local Network #82
Description
Description
The application currently binds the WebSocket server to 0.0.0.0 (all interfaces) without implementing any authentication mechanism. This allows any device connected to the same local network (Wi-Fi/LAN) to connect to the WebSocket endpoint and gain full control over the host machine's mouse and keyboard input.
An attacker does not need to scan the QR code; they only need to know the host's IP address and port (default: 3000/42069) to send input commands.
Impact
Unauthorized Input Control: A malicious actor on the local network can move the mouse, click, type text, and execute keyboard shortcuts on the victim's machine.
Privacy Violation: The attacker can access the /settings page (if not IP-restricted) to view the generated QR code or change configuration.
Denial of Service: An attacker could flood the WebSocket with input events, rendering the machine unusable.
Steps to Reproduce
Start the Rein server on a host machine (e.g., 192.168.1.10).
Connect a second device (Attacker) to the same Wi-Fi network.
On the Attacker device, open a WebSocket connection to ws://192.168.1.10:42069/ws (or via the frontend).
Send a JSON payload: {"type": "move", "dx": 100, "dy": 100}.
Result: The cursor on the Host machine moves, confirming unauthorized access.
Proposed Fix
Implement a Token-Based Authentication System:
Auth Token Generation:
The server generates a random, high-entropy AUTH_TOKEN (or PIN) on startup.
QR Code Embedding:
The token is embedded in the connection URL within the QR code (e.g., ?token=xyz123).
Connection Handshake:
The WebSocket server must reject any connection attempt that does not provide the valid AUTH_TOKEN in the query parameters or initial handshake message.
Localhost Restriction:
The /settings page (which displays the QR code) should be restricted to localhost (127.0.0.1) only. This prevents attackers from remotely viewing the token.