T09 · Insecure Skill Coding Practices
- Location
scripts/dt_helper.sh:87- Finding
Persistent credentials and access tokens are stored without restrictive file permissions
- Content
View full analysis
/dev/null; then sed -i "s|^${key}=.*|${key}=${value}|" "$CONFIG" else echo "${key}=${value}" >> "$CONFIG" fi } ``` The affected function is used to persist sensitive values, including access tokens: ```bash cfg_set DINGTALK_ACCESS_TOKEN "$token" cfg_set DINGTALK_TOKEN_EXPIRY "$((now + expire_in - 200))" ``` ```bash cfg_set DINGTALK_OLD_TOKEN "$token" cfg_set DINGTALK_OLD_TOKEN_EXPIRY "$((now + expires_in - 200))" ``` ### Technical Analysis The configuration file stores the DingTalk AppSecret and cached access tokens in plaintext. The script creates the directory and file using `mkdir -p` and `touch`, but does not establish a restrictive `umask` or explicitly apply secure permissions. Consequently, permissions are inherited from the process environment. Under a common `umask` of `022`, a newly created configuration file can be readable by other local users. The masking performed by `--config` and `--get` only affects command output; it does not protect the contents of the file itself. The script also accepts an alternative path through `DINGTALK_CONFIG`. The same insecure creation behavior applies to that path. ### Attack Path 1. A user invokes `--set` to store `DINGTALK_APP_SECRET`, or invokes `--token` or `--old-token`. 2. `cfg_set` creates the configuration file using inherited default permissions. 3. The file receives the application secret and reusable DingTalk access tokens in plaintext. 4. Another local account or compromised process reads the configuration file if its permissions permit access. 5. The attacker submits the stolen credentials or tokens to the documented DingTal ...[truncated 739 chars]- Remediation
View remediation
