T07 · Tool Hijacking and Spoofing
- Location
SKILL.md:3- Finding
Execution of an Unreviewed External Tool with Credential Access
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 3–20
Vulnerability Type: Trusting an external executable outside the audited skill package
Risk Level: MediumRelevant Code:
markdown description: "Ruft Google Search Console Daten für akku-alle.de ab - Klicks, Impressionen, CTR, Rankings und Top-Keywords. Nutze das shell Tool um /root/.openclaw/skills/gsc-search/gsc-search auszuführen." metadata: {"requires":{"env":["GOOGLE_APPLICATION_CREDENTIALS"]},"emoji":"🔍","always":true} user-invocable: true --- # Google Search Console Skill Ruft Search Console Daten für akku-alle.de ab. ## Aufruf via Shell Tool **WICHTIG**: Rufe dieses Skill mit dem `shell` Tool auf: ```bash /root/.openclaw/skills/gsc-search/gsc-searchtext ### Technical Analysis The skill instructs the agent to invoke `/root/.openclaw/skills/gsc-search/gsc-search`, an absolute-path executable that is not included in the audited project. Consequently, the executable's implementation, integrity, ownership, and behavior cannot be verified from this package. The skill also declares a requirement for `GOOGLE_APPLICATION_CREDENTIALS` and is configured with `"always": true`. If the external executable is replaced, modified, or resolved from an inadequately protected location, an attacker-controlled program could run under the agent's identity and potentially access the credential configuration available to the process. This is classified as tool hijacking because a legitimate-looking skill invocation delegates its effective behavior to an unaudited local tool. The reviewed `SKILL.md` does not itself prove that the referenced executable is malicious; the risk arises from the unverified external trust boundary. ### Attack Path 1. An attacker who can modify `/root/.openclaw/skills/gsc-search/gsc-search` replaces it with a malicious executable or script. 2. The skill is loaded automatically or selected in response to a Searc ...[truncated 1277 chars]- Remediation
View remediation
Remediation Suggestions
- Include the executable and its source code within the reviewed skill package so its behavior can be audited and versioned with the instructions.
- Verify the executable before every invocation using a pinned cryptographic hash, signed artifact, or trusted package manifest.
- Ensure the executable and every parent directory are owned by a trusted administrator and are not writable by unprivileged users or unrelated services.
- Run the executable in a sandbox with a read-only filesystem, restricted network access, and only the minimum required operating-system permissions.
- Provide Google credentials only to the subprocess that requires them rather than exposing them broadly in the agent environment.
- Use a dedicated service account with narrowly scoped IAM permissions and rotate its credentials regularly.
- Prefer short-lived workload identity credentials over persistent credential files where supported.
- Remove
"always": trueunless automatic loading is operationally necessary, reducing unnecessary exposure of the execution instruction. - Validate and constrain all arguments passed to the executable, including the documented
queriesargument. - Log executable integrity checks, invocations, and credential-access failures without recording credential contents.
