T09 · Insecure Skill Coding Practices
- Location
src/utils/config.ts:46- Finding
API Key Stored Without Restrictive Filesystem Permissions
- Content
View full analysis
): void { const existing = readJsonConfig(CONFIG_FILE); const merged = { ...existing, ...updates }; if (!existsSync(CONFIG_DIR)) { mkdirSync(CONFIG_DIR, { recursive: true }); } writeFileSync(CONFIG_FILE, JSON.stringify(merged, null, 2) + '\n', 'utf-8'); } ``` ### Technical Analysis The `writeConfig` function stores the Zernio API key in `~/.zernio/config.json` without specifying restrictive permissions for either the configuration directory or file. When Node.js creates the file, its effective permissions are derived from the default creation mode and the process umask. On commonly configured Unix-like systems, this can result in a mode such as `0644`, allowing other local users to read the file. The implementation also does not repair an existing configuration file that already has insecure permissions. The API key is a bearer credential. Any local principal able to read it can authenticate without needing the user's password or browser authorization session. ### Attack Path 1. The victim runs `zernio auth:login` or `zernio auth:set`. 2. The CLI calls `writeConfig` and writes the API key to `~/.zernio/config.json`. 3. The operating system creates the directory and file using permissions determined by the current umask. 4. If those permissions permit access by another local user or process, that principal reads the configuration file. 5. The attacker extracts the plaintext `apiKey` value. 6. The attacker submits authenticated requests to the configured Zernio API using the stolen bearer credential. Exploitation requires local filesystem access and permissions suffici ...[truncated 622 chars]- Remediation
View remediation
