T09 · Insecure Skill Coding Practices
Error
- Location
- scripts/vault-env.sh:4
- Finding
- Automatic Vault Token Transmission to a Hard-Coded Plaintext Endpoint<![CDATA[ ## Vulnerability Details **File Location**: `scripts/vault-env.sh:4-10`; credential-consuming commands are invoked at `scripts/vault-get.sh:16`, `scripts/vault-list.sh:11`, and `scripts/vault-put.sh:16` **Vulnerability Type**: Plaintext credential exposure through insecure default configuration **Risk Level**: Critical ### Vulnerable Code ```bash : "${VAULT_ADDR:=http://192.168.1.101:8200}" export VAULT_ADDR token_file="${HOME}/.vault-token" if [[ -z "${VAULT_TOKEN:-}" && -f "$token_file" ]]; then VAULT_TOKEN="$(< "$token_file")" export VAULT_TOKEN fi ``` The token is subsequently used by these commands: ```bash vault kv get "$path" "$@" vault kv list "$path" "$@" vault kv put "$path" "$@" ``` ### Technical Analysis When `VAULT_ADDR` is not already set, the environment helper silently defaults it to `http://192.168.1.101:8200`. It then automatically reads the user's Vault token from `~/.vault-token` and exports it as `VAULT_TOKEN`. The Vault CLI uses this token to authenticate requests sent to the selected server. Because the default endpoint uses plaintext HTTP, authentication traffic lacks transport confidentiality and server authentication. A party controlling `192.168.1.101`, or one capable of intercepting or modifying traffic on the local network, can obtain the Vault token. The behavior is especially dangerous because the destination does not need to be explicitly approved before a locally stored credential is loaded and transmitted. ### Attack Path 1. A user invokes one of the supplied Vault helper scripts without explicitly defining `VAULT_ADDR`. 2. `vault-env.sh` assigns `http://192.168.1.101:8200` as the destination. 3. The script reads the user's existing token from `~/.vault-token` and exports it. 4. The invoked Vault CLI command sends an authenticated request to the plaintext HTTP endpoint. 5. An attacker controlling that host, or positioned to intercept local network traffic, captures the token. 6. The attacker reuses the t ...[truncated 875 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the hard-coded `VAULT_ADDR` default and fail closed when no endpoint is explicitly configured: ```bash if [[ -z "${VAULT_ADDR:-}" ]]; then echo "VAULT_ADDR must be explicitly configured" >&2 exit 2 fi ``` 2. Require HTTPS by default. Reject plaintext HTTP unless the user supplies a deliberate, narrowly scoped opt-in intended only for disposable local development environments. 3. Validate the destination before reading or exporting `VAULT_TOKEN`. Endpoint validation must occur before accessing `~/.vault-token`. 4. Use TLS certificate verification and a trusted CA. Do not disable certificate validation as a workaround. 5. Avoid automatically loading credentials for an unverified destination. Require explicit authentication or explicit confirmation when the configured endpoint changes. 6. Prefer short-lived, least-privileged tokens with narrowly scoped policies. Apply TTLs, periodic rotation, and CIDR restrictions where appropriate. 7. Revoke and rotate any token that may already have been transmitted through the plaintext default endpoint. 8. Update `SKILL.md` and the troubleshooting reference so plaintext HTTP addresses are clearly identified as unsafe lab-only examples rather than operational defaults. ]]>