T09 · Insecure Skill Coding Practices
- Location
scripts/screenshot.js:48- Finding
Hard-Coded SMTP Credentials Exposed in Source Code
- Content
View full analysis
' }; ``` The exposed password is subsequently supplied to Nodemailer at lines 198–207: ```js const transporter = nodemailer.createTransport({ host: EMAIL_CONFIG.host, port: EMAIL_CONFIG.port, secure: EMAIL_CONFIG.secure, auth: { user: EMAIL_CONFIG.user, pass: EMAIL_CONFIG.pass } }); ``` ### Technical Analysis The SMTP username and password are embedded directly in a distributable JavaScript file. Source-code access is therefore sufficient to recover the credentials; no execution, decryption, or privileged system access is required. The application's recipient-domain validation does not protect the SMTP account itself. An attacker can extract the credentials and connect to `smtp.feishu.cn` using a separate SMTP client, bypassing all restrictions implemented by `validateEmail()` and the remainder of the Skill. If the exposed credentials remain valid, the attacker can exercise whatever SMTP permissions the account grants. Secrets committed to source code can also remain recoverable from previously distributed packages, backups, caches, or version-control history after the current file is edited. ### Attack Path 1. Obtain read access to the Skill package or a copy of its source code. 2. Open `scripts/screenshot.js` and extract the SMTP host, port, username, and password from `EMAIL_CONFIG`. 3. Configure an independent SMTP client to connect to `smtp.feishu.cn` on port 465 using TLS. 4. Authenticate as `moss@campsnail.com` with the exposed password. 5. If the credentials are valid, send email independently of the Skill and bypass its `@campsnail.com` recipient restri ...[truncated 841 chars]- Remediation
View remediation
' }; ``` 3. **Use a secret manager where available**, granting access only to the dedicated runtime identity that executes this Skill. 4. **Remove the credential from repository history, published artifacts, backups, and cached build outputs** where operationally possible. Merely changing the current file does not invalidate previously exposed copies. 5. **Apply least privilege to the SMTP account**, including sender and recipient restrictions enforced by the mail service rather than only by client-side code. 6. **Use a dedicated application credential** instead of a reusable interactive-account password. 7. **Enable monitoring and rate limits** for abnormal login locations, excessive message volume, unusual recipients, and authentication failures. 8. **Review password reuse** and rotate credentials for any other service where the exposed password was used. 9. **Add automated secret scanning** to development and release pipelines to block future plaintext credentials from being committed or packaged. ]]>
