T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- references/commands.md:10
- Finding
- SSH setup defaults to persistent root-level remote access<![CDATA[ ## Vulnerability Details **File Location**: `references/commands.md:10-31`; additional occurrences in `SKILL.md:35`, `SKILL.md:77-81`, and `references/examples.md:65-74` **Vulnerability Type**: Least-privilege violation through root SSH key authorization **Risk Level**: High ### Vulnerable Code `references/commands.md:10-31`: ```bash claw2claw setup <remote-host> [user] [port] ``` ```markdown | Argument | Required | Default | Description | |----------|----------|---------|-------------| | `<remote-host>` | Yes | - | IP or hostname | | `[user]` | No | `root` | SSH username | | `[port]` | No | `22` | SSH port | ``` ```bash claw2claw setup 192.168.1.100 claw2claw setup 192.168.1.100 admin claw2claw setup 192.168.1.100 admin 2222 claw2claw setup myserver.example.com ``` ```markdown ### What Happens 1. Tests SSH connectivity 2. Adds SSH key to remote if needed 3. Saves config to `~/.claw2claw.conf` ``` `SKILL.md:35`: ```bash claw2claw setup 192.168.1.100 --user root ``` `SKILL.md:77-81`: ```bash REMOTE_HOST="192.168.1.100" # Remote IP/hostname REMOTE_USER="root" # SSH user REMOTE_PORT="22" # SSH port SSH_KEY="/path/to/key" # Custom SSH key RSYNC_BWLIMIT=1000 # KB/s limit ``` `references/examples.md:65-74`: ```markdown ## Multi-Agent Setup **Agent A:** ```bash claw2claw setup <agent-b-ip> --user root ``` **Agent B:** ```bash claw2claw setup <agent-a-ip> --user root ``` ``` ### Technical Analysis The documented `setup` workflow defaults to the `root` SSH account and states that it adds an SSH key to the remote system. The examples also recommend reciprocal root setup between two agents. This creates persistent, key-based administrative access even though ordinary file transfer generally requires access only to designated source and destination directories. This exceeds the minimum privileges necessary for the declared file-transfer functionality. A dedicated, unprivileged transfer account with narro ...[truncated 1895 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Change the default SSH user from `root` to a dedicated, unprivileged transfer account. 2. Require users to specify a remote account explicitly rather than silently selecting an administrative account. 3. Grant the transfer account access only to approved source and destination directories using ownership, groups, ACLs, a restricted shell, or a chroot environment. 4. If key installation is supported, require explicit confirmation and display the target host, account, key fingerprint, and resulting privilege level before modifying `authorized_keys`. 5. Restrict authorized keys where feasible using options such as `from=`, `restrict`, `no-agent-forwarding`, `no-port-forwarding`, `no-X11-forwarding`, and an appropriate forced command. 6. Enforce strict SSH host-key verification to reduce machine-in-the-middle risk during initial setup. 7. Store private keys with mode `0600` and configuration directories with mode `0700`; never copy private keys to remote hosts. 8. Treat root setup as an exceptional, opt-in operation accompanied by a prominent warning and additional confirmation. 9. Avoid recommending reciprocal root access between agents. Configure only the minimum transfer direction required for the workflow. 10. Document key rotation, revocation, and uninstall procedures, including removal of the corresponding remote `authorized_keys` entry. 11. Include the actual implementation in future audits so command construction, input validation, host-key handling, and key-management behavior can be verified. ]]>