T09 · Insecure Skill Coding Practices
Warning
- Location
- references/collector-cron.md:16
- Finding
- Ingest Token Exposed in Persistent Cron Command## Vulnerability Details **File Location**: `references/collector-cron.md`, lines 16-21 **Vulnerability Type**: Secret exposure through cron configuration and process environment **Risk Level**: Medium ### Vulnerable Code ```markdown Use `collectors/openclaw-state-collector/scripts/install-cron.sh` and set env vars inside script/system profile. Example entry: ```cron */2 * * * * cd <PROJECTS_ROOT>/agent-fleet-dashboard && REPORT_MODE=cloudflare REPORT_ENDPOINT=https://<worker>.workers.dev REPORT_TOKEN=<INGEST_TOKEN> AGENT_ID=<agent_id> npm run -w collectors/openclaw-state-collector collect >> <LOG_ROOT>/collector.log 2>&1 ``` ``` ### Technical Analysis The documented cron entry places `REPORT_TOKEN` directly in the persistent command. Although the value is represented by a placeholder, following this example requires substituting the production ingest token into the crontab. This conflicts with the project's separate recommendation to keep runtime secrets in secret managers. Depending on host configuration and access boundaries, the resulting secret may be exposed through crontab inspection, process environment inspection, configuration backups, administrative tooling, troubleshooting output, or copied support material. Redirecting command output does not protect the token stored in the cron definition. The scheduled collector itself is disclosed and reasonably necessary for the declared continuous heartbeat synchronization. Therefore, the persistence mechanism is not classified as a malicious T06 backdoor. The confirmed issue is the insecure handling of the credential used by that mechanism. ### Attack Path 1. An attacker obtains local access sufficient to inspect the collector user's crontab, cron configuration backups, process environment, or operational captures. 2. The attacker recovers the production value assigned to `REPORT_TOKEN`. 3. The attacker identifie ...[truncated 968 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the example that embeds `REPORT_TOKEN` directly in the crontab command. 2. Retrieve the token at execution time from an operating-system keychain, service credential facility, or other supported secret manager. 3. If a credential file is unavoidable, place it outside the repository, restrict ownership to the collector account, and set permissions to owner-read only, such as mode `0600`. 4. Use a small launcher script that retrieves the secret without printing it and then invokes the collector. Ensure the launcher and collector never enable shell tracing or log environment variables. 5. Restrict the collector to a dedicated, unprivileged operating-system account with only the filesystem and network permissions required for telemetry collection. 6. Use a dedicated ingest token with write-only, environment-specific scope. Do not reuse dashboard read tokens or Cloudflare administrative credentials. 7. Add token rotation and revocation procedures, and rotate the token immediately if a crontab, process listing, backup, screenshot, or log containing it is exposed. 8. Document safe cron installation and removal procedures and verify that uninstalling the Skill's integration removes the scheduled entry and associated credentials.
