T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:50
- Finding
- Excessive DingTalk Enterprise Directory Permissions## Vulnerability Details **File Location**: `SKILL.md`, lines 50-57 **Vulnerability Type**: Excessive permissions that violate the principle of least privilege **Risk Level**: Medium ### Evidence The following is an English translation of the complete relevant documentation segment: ```markdown ## Step 4: Permission Configuration Enable the following under "Permission Management": - Enterprise conversation message read permission - Enterprise conversation message write permission - Address book read-only permission - Member information read permission ``` ### Technical Analysis The stated purpose of the Skill is to connect an AI assistant to DingTalk and process group messages. Message read and write permissions are consistent with that purpose. However, the guide additionally directs users to grant read access to the enterprise address book and member information without identifying any required feature that depends on those permissions. These directory-related scopes may expose organization structure and employee data beyond what is necessary for ordinary group-message processing. This violates the principle of least privilege and increases the consequences of credential disclosure, webhook compromise, OpenClaw host compromise, or misuse by an authorized integration operator. The package contains documentation rather than executable implementation, so it does not independently exercise these privileges. Exploitation depends on a user following the guide, granting the listed scopes, and an attacker subsequently obtaining control of the integration or its credentials. ### Attack Path 1. An administrator follows `SKILL.md` and creates a DingTalk enterprise application. 2. The administrator grants all recommended permissions, including address-book and member-information read access. 3. The administrator supplies the application credentials to OpenClaw and exposes the bot service through a public HTTPS webhook. 4. An attacker compromises the OpenClaw ...[truncated 1039 chars]
- Remediation
- ## Remediation Suggestions 1. Remove address-book and member-information permissions from the default setup instructions. 2. Require only the minimum message scopes necessary to receive and reply to DingTalk group messages. 3. Document every requested permission, the exact feature that requires it, and the data it exposes. 4. Present directory permissions as optional and require administrators to enable them only when a specifically configured feature needs enterprise-directory access. 5. Separate optional features into distinct permission profiles so deployments can use narrowly scoped credentials. 6. Recommend restricting the bot to explicitly approved chats and reviewing the `allowed_chats` configuration before deployment. 7. Store the AppSecret in a protected secret manager or environment-backed credential store rather than plaintext configuration or shell history. 8. Rotate credentials periodically and immediately after suspected disclosure. 9. Apply DingTalk tenant controls, API audit logging, and monitoring for unusual directory queries. 10. Protect the public webhook with DingTalk request signature verification, replay protection, strict request validation, rate limiting, and HTTPS. 11. Advise administrators to review granted scopes regularly and revoke permissions that are no longer required.