T06 · System Persistence
Error
- Location
- SKILL.md:48
- Finding
- Elevated Logon Persistence Executes a Mutable User-Profile Script<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:48-54` and duplicated in `README.md:39-45` **Vulnerability Type**: Scheduled-task persistence, excessive privileges, and unsafe executable path **Risk Level**: High ```batch REM Delete the old task schtasks /delete /tn "OpenClaw Gateway" /f 2>nul REM Create corrected task (runs at logon, no idle kill) schtasks /create /tn "OpenClaw Gateway" /tr "cmd /c cd /d \"%USERPROFILE%\.openclaw\" && gateway.cmd" /sc ONLOGON /rl HIGHEST /f ``` ### Technical Analysis The documented batch commands forcibly delete the existing `OpenClaw Gateway` scheduled task and recreate it with an `ONLOGON` trigger and the `HIGHEST` run level. This establishes execution that persists across sessions and requests the highest privileges available to the task principal. The task launches `gateway.cmd` indirectly through `cmd.exe` from `%USERPROFILE%\.openclaw`. The documentation does not validate the script's owner, access-control list, signature, or hash. Because a user-profile location is commonly writable by the account and potentially by processes operating under that account, any actor able to replace or alter `gateway.cmd` can influence what the scheduled task executes at the next logon. This design exceeds the minimum privileges necessary for the declared purpose. Correcting idle termination only requires changing the existing task's idle-related settings. It does not inherently require deleting the task, introducing a new logon trigger, requesting the highest run level, or launching a mutable batch file through a command interpreter. Forced replacement also discards the existing task definition, including its principal, action, conditions, access controls, failure behavior, and other security settings. The documentation claims that the replacement restarts on failure and operates regardless of battery state, but the provided `schtasks /create` command does not explicitly configure those properties. ### Attack Path ...[truncated 1931 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not delete and recreate the task merely to correct idle behavior. Modify only the required idle, execution-limit, battery, and failure-recovery properties of the existing task. 2. Preserve and review the existing task's principal, action, trigger, access-control descriptor, and other settings before applying changes. Export a backup of the task definition first. 3. Remove `/rl HIGHEST` unless documented functionality demonstrably requires elevation. Use the least-privileged dedicated account or standard user context sufficient to run the gateway. 4. Avoid `cmd.exe` and mutable batch files where possible. Configure the task to invoke the intended executable directly using an absolute path. 5. Store the executable or script in an administrator-protected installation directory rather than a broadly mutable user-profile path. 6. Restrict file and directory ACLs so only the trusted installer and required service identity can modify the launched program. 7. Verify the launched artifact's digital signature or cryptographic hash before registration and execution. 8. Explicitly configure and verify restart-on-failure and battery behavior instead of claiming settings that the supplied command does not establish. 9. Require explicit user confirmation before replacing an existing task, and abort if the existing task's principal or action differs from the expected trusted configuration. 10. Provide an uninstall or rollback procedure that restores the backed-up task definition and removes any persistence introduced by the fix. ]]>