T09 · Insecure Skill Coding Practices
Note
- Location
- SKILL.md:82
- Finding
- Hardcoded Telegram Application Identifier and Hash<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 82-86 **Vulnerability Type**: Hardcoded credential-like application configuration **Risk Level**: Low ### Vulnerable Code ```markdown ## KHF Client Protocol Constants (must match server) Extracted from KHF client source code: - `TLRPC.LAYER = 222` - `BuildVars.APP_ID = 4` - `BuildVars.APP_HASH = "014b35b6184100b085b0d0572f9b5103"` ``` ### Technical Analysis The skill embeds a concrete Telegram-compatible application ID and application hash and states that they must match between client and server. Although the document characterizes these values as public identifiers, an application hash is credential-like configuration associated with an application identity. Publishing and encouraging reuse of a fixed value can result in multiple deployments sharing the same identity. The file is documentation-only and does not itself use, transmit, or execute the value. Consequently, exploitation requires a separate compatible client or server implementation. There is no evidence in the audited project that this value grants server administration, operating-system access, access to user authorization keys, or access to user accounts by itself. ### Attack Path 1. An external party reads the application ID and hash from `SKILL.md`. 2. The party configures a Telegram-compatible client or related implementation with the published values. 3. The party initiates protocol requests under the shared application identity. 4. If an upstream service accepts these values and applies identity-based accounting or policy, activity may be attributed to the shared application identity, potentially causing abuse attribution, throttling, or revocation affecting legitimate users. This path does not independently bypass user authentication or disclose MTProto authorization keys. ### Impact Assessment The likely impact is unauthorized reuse of the documented application identity, attribution ambiguity, operational c ...[truncated 449 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace the concrete values with clearly nonfunctional placeholders: ```markdown - `BuildVars.APP_ID = <YOUR_APP_ID>` - `BuildVars.APP_HASH = "<YOUR_APP_HASH>"` ``` 2. Instruct operators to provision and use an application identity authorized for their own deployment rather than reusing a shared identity. 3. Store the application hash outside source-controlled documentation and code, such as in an environment variable or access-controlled configuration file. 4. Avoid logging the application hash or including it in examples, generated diagnostics, or deployment artifacts. 5. If the published value is active and controlled by the project, assess its usage and rotate or revoke it where the relevant platform supports doing so. 6. Clarify that application credentials do not replace user authentication and must not be treated as authorization for access to user accounts or server administration. ]]>