T09 · Insecure Skill Coding Practices
- Location
config.json:2- Finding
Plaintext Umeng API Credentials Embedded in Configuration
- Content
View full analysis
Vulnerability Details
File Location:
config.json:2-4
Vulnerability Type: Hardcoded API credentials and plaintext sensitive data
Risk Level: HighVulnerable Code
json { "apiKey": "4676865", "apiSecurity": "JCVOyuLUcr", "apps": {The credential is consumed by the request-signing implementation in
scripts/query_crash.py:21-29:python def sign(api_key, api_security, service, method_name, params): url_path = f"param2/1/{service}/{method_name}/{api_key}" sorted_keys = sorted(params.keys()) param_str = "" for k in sorted_keys: param_str += f"{k}{params[k]}" s = url_path + param_str signature = hmac.new( api_security.encode("utf-8"), s.encode("utf-8"), hashlib.sha1 ).hexdigest().upper() return url_path, signatureTechnical Analysis
The project distributes an Umeng API key and its HMAC signing secret in plaintext. These values are authentication credentials rather than non-sensitive configuration. Any party able to download, inspect, copy, or otherwise access the Skill package can recover both values without needing runtime access to the legitimate operator's system.
The script contains the complete signing algorithm required to use the credential. It constructs the canonical request from the API path and sorted parameters, then calculates an HMAC-SHA1 signature using
apiSecurity. Consequently, possession of the repository is sufficient to reproduce authenticated Umeng requests outside the Skill.The configuration also associates the credential with 20 application identifiers. This gives an attacker the information required to target the configured applications' U-APM crash information and U-App analytics. Actual accessible operations remain subject to the permissions assigned to the exposed Umeng credential.
Attack Path
- An attacker obtains a copy of the Skill package, repository, ...[truncated 1211 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed
apiKeyandapiSecurityimmediately. Treat the current values as compromised because they have been distributed in plaintext. - Remove credentials from
config.json, repository history, release archives, build artifacts, logs, backups, and deployed Skill packages where feasible. - Load credentials at runtime from environment variables, an operating-system credential store, or a managed secret service.
- Commit only a credential-free template such as
config.example.json, using placeholders for sensitive values. - Separate application metadata from secrets so that application identifiers can be configured without distributing the signing secret.
- Apply least privilege to the replacement credential. Restrict it to only the applications and API methods required by the Skill.
- Restrict access to any local secret file with appropriate filesystem permissions and ensure it is excluded through repository ignore rules and packaging configuration.
- Add automated secret scanning to source-control and release pipelines to prevent credentials from being committed or packaged again.
- Review Umeng access and usage records for requests made with the exposed credential, including unusual applications, source addresses, methods, or quota consumption.
- Avoid placing authentication secrets in command-line arguments or diagnostic output when implementing the replacement secret-loading mechanism.
- Revoke and rotate the exposed