T06 · System Persistence
- Location
SKILL.md:37- Finding
Privileged Cross-Session Rollback Task Creates System Persistence
- Content
View full analysis
``` The Skill further specifies: ```text The restore timer is a system-level scheduled task (`at` / `crontab`). It does NOT depend on your shell session, SSH connection, or any application. Even if you brick the service, the timer still fires. ``` ### Technical Analysis The Skill explicitly instructs the Agent to register an `at` job that continues executing after the initiating shell, application, or SSH session ends. The scheduled command later overwrites an active service configuration and reloads the affected service. A delayed rollback is relevant to the declared recovery functionality, but the instructions apply broadly to nginx, SSH, firewall, DNS, proxy, and arbitrary service configurations. They do not require: - Validation or canonicalization of the target path. - An allowlist of permitted files or services. - Confirmation of the exact delayed command before registration. - Verification of the account under which the task will execute. - Reliable capture and storage of the scheduled job ID. - Verification that cancellation succeeded. - Secure backup permissions and cleanup. - Restrictions against substituting a persistent `crontab` entry. The mechanism does not independently obtain elevated privileges; it executes with the permissions of the account that registers the job. However, modifying files under `/etc` and reloading system services will commonly require root or equivalent administrative authority. When invoked with those privileges, ...[truncated 1952 chars]- Remediation
View remediation
