T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/register.sh:33
- Finding
- Bearer Token Stored Without Enforced Restrictive Permissions<![CDATA[ ## Vulnerability Details **File Location**: `scripts/register.sh:33-34` **Vulnerability Type**: Plaintext sensitive-data storage with permissions dependent on the caller's umask **Risk Level**: High ### Vulnerable Code ```bash mkdir -p "$HOME/.brouter" echo "$RESP" | jq '.data' > "$HOME/.brouter/$NAME.json" ``` ### Technical Analysis The registration response contains the agent's bearer token and is written in plaintext to `~/.brouter/<agent-name>.json`. Neither the directory nor the output file is assigned an explicit restrictive permission mode. The resulting permissions therefore depend on the caller's current `umask` and on the permissions of any pre-existing `~/.brouter` directory. Under a permissive configuration, other local users or processes may be able to read the registration response and recover the bearer token. The documentation states that this token remains valid for 90 days, creating a substantial exposure window. The script also stores the entire `.data` object even though only a limited subset of fields may need to persist. This unnecessarily increases the amount of sensitive or account-related information retained on disk. ### Attack Path 1. A user invokes `scripts/register.sh` in an environment with a permissive `umask`, or with an existing `~/.brouter` directory that is accessible to other local users. 2. The script writes the complete registration response to `~/.brouter/<agent-name>.json`. 3. A local attacker or compromised process reads the file. 4. The attacker extracts `.token` and `.agent.id`. 5. The attacker submits authenticated requests using `Authorization: Bearer <stolen-token>`. 6. Until the token expires or is revoked, the attacker can impersonate the registered agent within the privileges granted by the Brouter API. ### Impact Assessment Successful exploitation provides access to the affected agent's authenticated Brouter API session. Depending on server-side authorization, the stolen token could allow an ...[truncated 392 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Set a restrictive `umask` before creating any credential-bearing files: ```bash umask 077 ``` 2. Create or repair the credential directory with owner-only permissions: ```bash install -d -m 700 "$HOME/.brouter" ``` 3. Create the token file atomically with mode `600`, avoiding permission dependence on the caller's environment: ```bash TOKEN_FILE="$HOME/.brouter/$NAME.json" TMP_FILE=$(mktemp "$HOME/.brouter/.register.XXXXXX") trap 'rm -f "$TMP_FILE"' EXIT printf '%s\n' "$RESP" | jq '{token: .data.token, agent: {id: .data.agent.id}}' > "$TMP_FILE" chmod 600 "$TMP_FILE" mv -f "$TMP_FILE" "$TOKEN_FILE" trap - EXIT ``` 4. Store only fields required by subsequent operations instead of the complete `.data` response. 5. Validate that an existing `~/.brouter` path is a directory owned by the current user and is not a symbolic link. 6. Provide token revocation and rotation instructions, particularly for systems where the file may already have been exposed. ]]>