T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:31
- Finding
- Public Identifier Used as the Sole Authentication Credential## Vulnerability Details **File Location**: `SKILL.md:31-38`; supporting implementation in `scripts/tbb-register.py:49-56` **Vulnerability Type**: Authentication design flaw **Risk Level**: High ### Vulnerable Code `SKILL.md:31-38`: ```text ## Step 2: Authenticate All authenticated endpoints require one header: X-Agent-Pubkey: ed25519:your_pubkey_here No tokens. No OAuth flows. Just the header. ``` `scripts/tbb-register.py:49-56`: ```python identity = { "pubkey": result["pubkey"], "reputation": result["initial_reputation"], "node": NODE_URL, } IDENTITY_FILE.write_text(json.dumps(identity, indent=2)) ``` ### Technical Analysis The documented authentication protocol uses an agent's public identifier as the only authentication value. It does not require a private-key signature, server challenge, bearer secret, or any other proof that the caller owns the associated identity. A public key is intended to be public and therefore cannot safely function as a reusable authentication credential by itself. The Skill also documents public reputation endpoints that use public keys as identifiers, further making confidentiality of these values an invalid security assumption. The local registration helper does not generate or store a private key. It only saves the server-provided public identifier, confirming that subsequent requests cannot perform cryptographic proof of possession under the documented protocol. ### Attack Path 1. The attacker obtains a target agent's public key from command output, shared files, gossip records, reputation data, logs, or another public source. 2. The attacker constructs a request to an endpoint described as authenticated. 3. The attacker supplies the target value in the `X-Agent-Pubkey` header. 4. Because the protocol requires no signature or secret, the service has no documented mechanism to distinguish the attacker from the legitimate agent. 5. The attacker performs actions attributed to the victim, such as broadcas ...[truncated 690 chars]
- Remediation
- ## Remediation Suggestions 1. Generate an Ed25519 key pair locally and retain the private key only on the agent's system. 2. Register only the public key with the external service. 3. Require every authenticated request to include a signature covering: - HTTP method - Request path and query - Hash of the request body - Server-issued nonce - Timestamp and short expiration period 4. Verify signatures server-side against the registered public key. 5. Track and reject reused nonces to prevent replay attacks. 6. Store the private key in an operating-system credential store or another access-controlled secret store rather than a general working-directory JSON file. 7. Restrict identity-file permissions and avoid printing sensitive authentication material if the protocol is changed to use a secret. 8. Clearly distinguish public identifiers from authentication credentials in the Skill documentation.