T05 · Unauthorized Access and Privilege Escalation
Note
- Location
- skill.md:39
- Finding
- Collection of Unnecessary Persistent Device Identifiers<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:39-59` **Vulnerability Type**: Excessive device fingerprint collection **Risk Level**: Moderate ### Vulnerable Code Snippet ```json { "agent_id": "your_agent_id", "username": "your_name", "gender": "male", "age": 25, "device_id": "MAC address or device ID", "device_name": "device name", "device_type": "desktop" } ``` The associated parameter documentation also permits collection of: ```text device_id Optional — Unique device identifier, such as a MAC address or device ID device_name Optional — Device name, such as "iPhone 15" or "Windows PC" device_type Optional — Device type, such as mobile, desktop, or agent os_info Optional — Operating-system information client_version Optional — Client version ``` ### Technical Analysis The registration example encourages an Agent to send a MAC address or another stable device identifier to the external service at `https://tsdtmhtd9d.coze.site`. It also permits disclosure of the device name and operating-system information. These attributes are not necessary for the documented matchmaking operations. A persistent hardware identifier is particularly sensitive because it can correlate registrations and activity across sessions, accounts, or profile changes. Combining it with a device name and operating-system information produces a stronger device fingerprint. The fields are documented as optional, so the Skill does not technically require their submission. Nevertheless, placing them in the primary registration example encourages implementations to collect and transmit them by default. This conflicts with data-minimization and least-privilege principles. ### Attack Path 1. An Agent loads the Skill and follows its registration example. 2. The Agent or its integration obtains the host's MAC address, device identifier, device name, or operating-system details. 3. These values are submitted to the third-party registrati ...[truncated 1141 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `device_id`, `device_name`, and `os_info` from the default registration example. 2. Explicitly instruct Agents not to retrieve or submit MAC addresses, hardware serial numbers, advertising identifiers, or other host-level identifiers. 3. If an installation identifier is operationally necessary, generate a random, service-specific identifier that cannot be correlated with other services. 4. Make any telemetry strictly opt-in and explain its purpose, retention period, recipients, and deletion process before collection. 5. Minimize retained metadata and enforce server-side expiration for optional device information. 6. Provide users with controls to inspect and delete previously submitted device data. 7. Document that registration and core matchmaking functionality must remain available when all optional device fields are omitted. ]]>