T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:37
- Finding
- Predictable Shared WeChat Verification Token## Vulnerability Details **File Location**: `SKILL.md`, lines 37 and 51 **Vulnerability Type**: Predictable authentication token in configuration guidance **Risk Level**: Medium ### Vulnerable Code Snippet ```text Token: openclaw2024 ``` The same predictable value is presented as an example at line 37 and as direct configuration input at line 51. ### Technical Analysis The guide recommends a fixed, low-entropy token without clearly requiring users to replace it with a unique, cryptographically random secret. Users following the instructions verbatim may deploy the publicly documented value as the verification token for their WeChat callback endpoint. Callback authentication commonly relies on this token when validating request signatures. If the token is known, an attacker may be able to generate otherwise valid authentication signatures and submit forged requests to the public `/wechat` endpoint. Encrypted message contents may remain protected by the separately configured `EncodingAESKey`, but the documented token can still undermine any request-validation mechanism that relies on the token alone. The practical exploitability and exact consequences depend on the callback-validation behavior implemented by OpenClaw, which is not included in this project. ### Attack Path 1. An operator follows the guide and configures `openclaw2024` as the production WeChat verification token. 2. The operator exposes the documented `/wechat` callback endpoint on a public server. 3. An attacker obtains the token directly from this publicly distributed guide. 4. The attacker generates requests or verification signatures using the known token. 5. The attacker submits crafted requests to the callback endpoint. 6. If OpenClaw treats a valid token-derived signature as sufficient authentication, the forged request is accepted and processed. ### Impact Assessment A successful attack could allow unauthorized callback verification, forge ...[truncated 362 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the fixed example with an unmistakable placeholder such as `YOUR_UNIQUE_RANDOM_TOKEN`. 2. Require every deployment to generate an independent token using a cryptographically secure random-number generator, with at least 32 random bytes of entropy. 3. Provide a safe generation example, such as: ```bash openssl rand -hex 32 ``` 4. Explicitly warn users never to copy documentation examples into production. 5. Store the token, AppSecret, and EncodingAESKey in a protected secret manager or restricted environment variables rather than plaintext configuration where supported. 6. Restrict secret-file permissions to the service account and prevent secrets from appearing in logs, shell history, screenshots, or source control. 7. Validate every callback signature using constant-time comparison and reject stale timestamps, replayed nonces, malformed requests, and requests that fail encryption or signature checks. 8. Rotate any deployment currently using `openclaw2024` and review callback logs for suspicious verification or message-processing requests.