# Pre-auth stored XSS in Activity Logs can lead to command execution ## Summary Crafty Controller trusts the client supplied `X-Real-IP` and `X-Forwarded-For` headers as the remote IP address. A failed login for an existing user stores this value in the audit log. The Activity Logs page later inserts the stored value into the DOM as HTML. An unauthenticated attacker can therefore store JavaScript in the audit log. When a superuser opens Activity Logs, the script runs in the Crafty Controller origin with that user's access. The same-origin script can use the victim's session to create a full-access API key, change a managed server's execution command, and start the server. This results in command execution as the operating system user running Crafty. {width=490 height=278} {width=900 height=473} ## Affected version Confirmed on Crafty Controller `v4.10.7` at commit: ```text 5ecfda7508cd6d7324365b56ccedc127b4a3ab83 ``` The official image used for validation was: ```text registry.gitlab.com/crafty-controller/crafty-4@sha256:67c2cbab1c88b75efb41b2970b1faca1a736b3532f6d1a806a7fe3f81664a199 ``` Earlier versions containing the same code may also be affected, but were not tested. Proposed severity: Critical Proposed CVSS 3.1: `9.6` Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` ## Root cause `app/classes/web/base_handler.py` trusts forwarding headers without checking whether the request came from a configured trusted proxy: ```python def get_remote_ip(self): remote_ip = ( self.request.headers.get("X-Real-IP") or self.request.headers.get("X-Forwarded-For") or self.request.remote_ip ) return remote_ip ``` `app/classes/web/routes/api/auth/login.py` stores that value after a failed password attempt for an existing user: ```python self.controller.management.add_to_audit_log( user_data.user_id, "Tried to log in", None, self.get_remote_ip() ) ``` `app/frontend/templates/panel/activity_logs.html` inserts audit values as HTML: ```javascript row.append(`<td>${value.source_ip}</td>`); ``` The other audit fields on this page are inserted in the same way and should be fixed at the same time. ## Proof of concept Run this against a disposable test instance. Replace `base_url` and the username if needed. The username must identify an existing enabled account. `admin` is the default on a normal installation. ```python import requests base_url = "https://127.0.0.1:18444" payload = """<img src=x onerror='alert("crafty-xss")'>""" requests.packages.urllib3.disable_warnings() response = requests.post( f"{base_url}/api/v2/auth/login/", headers={"X-Real-IP": payload}, json={ "username": "admin", "password": "DefinitelyWrong123!", }, verify=False, timeout=10, ) print(response.status_code) print(response.text) ``` The request returns `401`, but the payload is still stored. Log in as a superuser and open: ```text https://127.0.0.1:18444/panel/activity_logs ``` The alert runs when the audit rows are loaded. Reloading the page triggers it again, which confirms that the payload is stored. The same issue is also reachable through `X-Forwarded-For` when `X-Real-IP` is absent. ## Validated impact The storage, sink, privileged API, and command-execution legs were validated against the same official `v4.10.7` container: - The anonymous login request returned `401`. - The exact HTML payload was returned unchanged by the audit API. - The Activity Logs page inserted the payload as HTML. - A superuser session created a full-access API key through `PATCH /api/v2/users/<user-id>/key/`. - The key was retrieved through `GET /api/v2/users/<user-id>/key/<key-id>/`. - The key changed an existing server's `execution_command` through `PATCH /api/v2/servers/<server-id>/`. - Starting that server through `POST /api/v2/servers/<server-id>/action/start_server/` executed: ```text /usr/bin/touch crafty_rce_confirmed ``` The marker was created inside the managed server directory. The final process launch reaches `subprocess.Popen` in `app/classes/shared/server.py`. The official container proof executed as the unprivileged `crafty` user with all Linux capabilities dropped and no host mounts. In a container deployment, impact outside the container depends on its mounts and runtime permissions. On a native installation, the command runs with the permissions of the Crafty service account. Crafty's session token cookie is also readable by JavaScript in this version because it is set without `HttpOnly`. This makes token theft possible, but `HttpOnly` alone would not stop the chain because same-origin JavaScript can still call Crafty's APIs using the victim's session. ## Preconditions - The attacker must know an existing enabled username. - The attacker must be able to supply a forwarding header that reaches Crafty. Direct exposure is affected. A correctly configured proxy that overwrites the header with a validated client IP can block this input path. - A logged-in superuser must open Activity Logs before the entry rotates out. - Command execution requires a privileged victim and a managed server that can be started. ## Recommended fix Treat every audit field as text. Do not interpolate audit data into HTML strings. For example: ```javascript function textCell(value) { return $("<td>").text(value ?? ""); } row.append(textCell(value.time)); row.append(textCell(value.log_msg)); row.append(textCell(value.server_id)); row.append(textCell(value.source_ip)); ``` Build the username link with DOM methods. Set the label using `.text()`, encode the ID used in the URL, and only create the link when the ID has the expected numeric format. Also fix remote IP handling: - Use `request.remote_ip` by default. - Only honor forwarding headers when the direct peer is in a configured trusted proxy CIDR. - Parse and validate forwarded values as IP addresses. - Select the client address according to the trusted proxy chain. - Reject invalid values instead of storing the raw header. - Use the same normalized address for rate limiting, login cooldowns, audit records, and authentication logs. As defense in depth: - Set the token cookie with `HttpOnly`, `Secure`, and an appropriate `SameSite` value. - Add a Content Security Policy that blocks inline event handlers. - Require recent authentication for API key creation and execution command changes. ## Regression tests - Send an `X-Real-IP` value containing `<img src=x onerror=alert(1)>` during a failed login and confirm it is displayed literally in Activity Logs. - Repeat with `X-Forwarded-For`. - Confirm forwarding headers are ignored from untrusted peers. - Confirm valid forwarded IPs are accepted only from configured trusted proxies. - Test every audit table field, not only `source_ip`.