Back to skill

Security audit

huawei-cloud-cloudrobo-workspace

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for CloudRobo workspace management, but its test script has a real code-injection risk and some credential-handling guidance is under-hardened.

Install only if you need CloudRobo workspace administration. Use least-privileged or temporary AK/SK credentials, avoid storing them in plaintext config unless the file is owner-only, keep SSL verification enabled, and run the included test script only in a clean environment where WORKSPACE_ID, USER_ID, and ROLE_ID are trusted. Prefer a pinned, reviewed CLI package version before exposing real cloud credentials.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/test-cli-commands.sh:239
Finding
Environment-Controlled Python Code Injection in SDK Tests<![CDATA[ ## Vulnerability Details **File Location**: `scripts/test-cli-commands.sh`, lines 239–245, 266–272, 296–302, 307–313, 317–324, and 329–335 **Vulnerability Type**: Python code injection through unsafe interpolation of environment-controlled values **Risk Level**: High ### Vulnerable Code ```bash python3 -c " from cloudrobo_workspace.client import WorkspaceClient from cloudrobo_core.sdk import Config, HttpClient client = WorkspaceClient(HttpClient(Config())) result = client.show_workspace('$workspace_id') print(str(result)[:500]) " ``` The same vulnerable construction is used by other SDK tests: ```bash result = client.list_workspace_members('$workspace_id') result = client.update_workspace('$workspace_id', {'name': 'sdk-updated'}) result = client.delete_workspace('$workspace_id') result = client.add_workspace_members('$workspace_id', {'member_list': [{'user_id': '${USER_ID}', 'role_ids': ['${ROLE_ID}']}]}) result = client.delete_workspace_members('$workspace_id', ['${USER_ID}']) ``` ### Technical Analysis Values originating from `WORKSPACE_ID`, `USER_ID`, and `ROLE_ID` are inserted directly into Python source code passed to `python3 -c`. Shell quoting does not encode these values as safe Python string literals. An input containing a single quote can terminate the intended Python literal and append arbitrary Python statements. For example, a crafted `WORKSPACE_ID` resembling the following can alter the generated program: ```text '); __import__("os").system("attacker-controlled-command"); # ``` No local validation is performed before the environment values reach the Python interpreter. Although the service may validate UUIDs remotely, that validation occurs only after the generated Python source has already been parsed and executed. The read-only SDK cases TC-20 and TC-22 are especially significant because they run automatically when SDK mode is selected and `WORKSPACE_ID` is present. They do not require the mutation confirmation mechanism. ### ...[truncated 1385 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Do not generate Python source code containing interpolated environment values. Pass all dynamic values as command-line arguments, standard input, or environment data, and treat them exclusively as data. A safe pattern is: ```bash python3 - "$workspace_id" <<'PY' import sys from cloudrobo_workspace.client import WorkspaceClient from cloudrobo_core.sdk import Config, HttpClient workspace_id = sys.argv[1] client = WorkspaceClient(HttpClient(Config())) result = client.show_workspace(workspace_id) print(str(result)[:500]) PY ``` Apply the same design to every SDK function using `WORKSPACE_ID`, `USER_ID`, or `ROLE_ID`. Additional hardening should include: 1. Validate `WORKSPACE_ID` and `ROLE_ID` against a strict UUID parser before invocation. 2. Validate `USER_ID` against the documented lowercase 32-character identifier format. 3. Reject values containing unexpected characters rather than relying only on server-side validation. 4. Add regression tests containing quotes, newlines, backslashes, semicolons, and Python syntax. 5. Avoid `eval`, generated source, or dynamically assembled interpreter commands for all test inputs. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/test-cli-commands.sh:371
Finding
Overbroad Credential Discovery and Access-Key Prefix Disclosure<![CDATA[ ## Vulnerability Details **File Location**: `scripts/test-cli-commands.sh`, lines 371–384 **Vulnerability Type**: Excessive credential enumeration and sensitive identifier exposure **Risk Level**: Medium ### Vulnerable Code ```bash scan_credentials() { local ak="" sk="" for var in $(env | grep -iE '^(HUAWEI|HW|HWC).*(_AK|ACCESS_KEY|_SK|SECRET_KEY)' | cut -d= -f1 | sort -u); do case "$var" in *_AK|*ACCESS_KEY) ak="${!var}" ;; *_SK|*SECRET_KEY) sk="${!var}" ;; esac done if [ -z "$ak" ] || [ -z "$sk" ]; then echo "ERROR: AK/SK not found in environment variables." echo "Set HUAWEI_CLOUD_AK and HUAWEI_CLOUD_SK environment variables." exit 1 fi echo "Credentials found: AK=${ak:0:8}..." } ``` ### Technical Analysis The project declares `HUAWEI_CLOUD_AK` and `HUAWEI_CLOUD_SK` as the required credential variables. However, `scan_credentials` enumerates every environment variable whose name starts with `HUAWEI`, `HW`, or `HWC` and ends with an access-key or secret-key pattern. The script dereferences and reads each matching value through indirect expansion: ```bash ak="${!var}" sk="${!var}" ``` This exceeds the minimum operation required to verify that the two documented variables exist. If multiple credentials are present, the selected pair also depends on sorted environment-variable names and may not correspond to the credentials the CloudRobo client will actually use. The script then prints the first eight characters of the selected access key. Access-key identifiers are less sensitive than secret keys, but their disclosure can aid credential correlation, account identification, log-based reconnaissance, or targeted social engineering. CI logs may retain this value for extended periods. ### Attack Path 1. A developer workstation or CI runner contains several Huawei-related access keys and secret keys for different accounts or services. 2. The user runs the docume ...[truncated 994 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Check only the two explicitly documented variables, and never read or display more credential material than necessary: ```bash scan_credentials() { if [[ -z "${HUAWEI_CLOUD_AK:-}" || -z "${HUAWEI_CLOUD_SK:-}" ]]; then echo "ERROR: HUAWEI_CLOUD_AK and HUAWEI_CLOUD_SK must be set." >&2 exit 1 fi echo "Required credentials are configured." } ``` Further hardening should include: 1. Remove environment-wide credential enumeration. 2. Never print full or partial AK/SK values. 3. Disable shell tracing around authentication setup and test execution. 4. Configure CI systems to mask the exact required credential variables. 5. Use isolated, least-privileged test credentials rather than credentials shared with production workloads. 6. Prefer short-lived credentials where the underlying platform supports them. ]]>

T08 · Insecure Dependencies

Warning
Location
references/cli-installation-guide.md:12
Finding
Unpinned Third-Party CLI and SDK Installation<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-installation-guide.md`, lines 12–19 and 86–87 **Vulnerability Type**: Unpinned dependency installation from a mutable package source **Risk Level**: Medium ### Vulnerable Code ```bash pip install hw-cloudrobo-client ``` The guide explains that this meta-package installs the CLI framework, workspace command group, and all sub-packages through Python entry points, but it does not pin or verify any version. The troubleshooting section repeats the same installation instruction: ```text Reinstall: pip install hw-cloudrobo-client ``` ### Technical Analysis The installation command resolves the latest package and transitive dependencies available from pip's configured index at installation time. The project does not provide: - An exact package version. - A dependency lock file. - Package hashes. - A verified package index or repository URL. - A reviewed source revision. - Constraints for transitive dependencies. Python package installation may execute build backends or setup-related code. The resulting CLI and SDK also handle long-lived Huawei Cloud AK/SK credentials and authenticated network requests, making dependency integrity particularly important. There is no evidence in the audited project that `hw-cloudrobo-client` is currently malicious. The vulnerability is that the instructions trust mutable, unauthenticated-by-project dependency resolution without reproducibility or integrity controls. ### Attack Path 1. An attacker compromises the package publisher account, package index, build pipeline, or a transitive dependency. 2. A modified package version is published under a dependency name resolved by the command. 3. A user follows the installation guide and runs the unpinned `pip install`. 4. pip downloads and installs the compromised version. 5. Malicious installation or runtime code executes with the user's privileges. 6. When the CLI is subsequently used, the compromised component ...[truncated 563 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Use a reproducible, reviewed dependency set: 1. Pin `hw-cloudrobo-client` to an explicitly audited version. 2. Pin all transitive dependencies through a generated lock or constraints file. 3. Record SHA-256 hashes and install with hash enforcement: ```bash python -m pip install --require-hashes -r requirements.txt ``` 4. Document the expected package index and verified publisher. 5. Prefer a private, controlled package mirror for CI and production. 6. Run installation in an isolated virtual environment or container without cloud credentials. 7. Perform package integrity and provenance verification before exposing the installed client to AK/SK values. 8. Use automated dependency scanning and review updates before changing pinned versions. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/cli-installation-guide.md:44
Finding
Plaintext Long-Lived Credential Storage Without Permission Hardening<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-installation-guide.md`, lines 44–51; duplicated in `references/iam-policies.md`, lines 41–50 **Vulnerability Type**: Insecure storage guidance for long-lived cloud credentials **Risk Level**: Medium ### Vulnerable Code ```yaml cloudrobo: auth: ak: "<your-ak>" sk: "<your-sk>" region: cn-southwest-2 ``` The IAM guide provides the same alternative: ```yaml cloudrobo: auth: ak: "<your-ak>" sk: "<your-sk>" ``` ### Technical Analysis The documentation instructs users to place Huawei Cloud access and secret keys directly into `~/.cloudrobo/config.yaml`. These are long-lived authentication secrets used to sign API requests. The project explicitly documents `0o600` protection for `~/.cloudrobo/workspace.json`, but it provides no equivalent permission requirement, ownership verification, or secure creation process for the more sensitive `config.yaml` credential file. If the file is created under a permissive umask, restored with loose permissions, synchronized, or included in backups, other principals may obtain the secret key. The issue is not merely that the data is plaintext—clients often require retrievable credentials—but that the recommended storage method lacks controls proportionate to the sensitivity of the stored secret. ### Attack Path 1. A user follows the documented alternative configuration procedure. 2. The user writes AK/SK credentials to `~/.cloudrobo/config.yaml`. 3. The file receives inherited or default permissions that allow access beyond the owner, or it is copied into an insecure backup or synchronization location. 4. Another local user, process, backup agent, or compromised application reads the file. 5. The attacker extracts the AK/SK pair. 6. The attacker signs requests and performs CloudRobo operations allowed by those credentials. ### Impact Assessment Credential compromise may allow remote authenticated access without continued access to the ...[truncated 480 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Prefer environment injection from a managed secret store or short-lived credentials. If file-based credentials remain supported: 1. Create the directory and file with restrictive permissions before writing secrets: ```bash install -d -m 700 ~/.cloudrobo install -m 600 /dev/null ~/.cloudrobo/config.yaml ``` 2. Verify that the file is owned by the intended user and is not a symbolic link. 3. Perform atomic writes while preserving mode `0600`. 4. Add an explicit permission check in `cloudrobo setup` and refuse or warn on group/world-readable credential files. 5. Document credential rotation and immediate revocation procedures. 6. Exclude the file from version control, synchronization tools, diagnostic bundles, and unencrypted backups. 7. Use separate, least-privileged test credentials for this Skill. 8. Avoid enabling traffic logging or shell tracing while credentials are configured. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (4)

Context-Inappropriate Capability

Medium
Confidence
95% confidence
Finding
The script enumerates environment variables matching broad Huawei/cloud credential patterns and reads their values, even though the skill is for workspace management rather than credential handling. This increases exposure of unrelated secrets and partially prints the access key prefix, creating unnecessary secret discovery and disclosure risk if logs, terminal output, or downstream tooling capture the result.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The guide instructs users to place long-lived AK/SK credentials in environment variables or directly in ~/.cloudrobo/config.yaml, but it does not warn that config files may store secrets in plaintext and that shell-based export commands can be exposed through shell history, process environments, backups, or overly permissive file permissions. In a CLI used to manage cloud workspaces, compromise of these credentials could allow unauthorized access to workspace resources and downstream CloudRobo operations.

Session Persistence

Medium
Category
Rogue Agent
Content
all other skills (dataset, train, eval, infer) read the active workspace from
  `~/.cloudrobo/workspace.json`
- **Overview & quota** — View workspace capacity, used count, available count, member count
- **Onboarding** — First-time setup: create workspace → switch to it → start using other skills

**Architecture:**
Confidence
81% confidence
Finding
The skill persists active workspace context in ~/.cloudrobo/workspace.json for reuse by other skills, creating cross-session and cross-skill state that can influence later operations. Even though the file is documented as 0o600, persisted context can still lead to confused-deputy behavior, accidental operations against the wrong workspace, or tampering by local processes running as the same user.

Unsafe Defaults

Medium
Category
Tool Misuse
Content
- **Signing mechanism** — APIG HMAC-SHA256 signs each request with a timestamp to prevent
  replay attacks
- **Proxy support** — Optional HTTP/HTTPS proxy can be configured for network isolation
- **SSL verification** — Can be disabled for debugging (`CLOUDROBO_VERIFY_SSL=false`) but
  should be enabled in production
- **Traffic logging** — `CLOUDROBO_LOG_TRAFFIC=true` enables request/response logging for
  debugging; disable in production to avoid credential leakage in logs
Confidence
89% confidence
Finding
The document explicitly advertises an option to disable TLS certificate verification via `CLOUDROBO_VERIFY_SSL=false`. Even though it says this should only be used for debugging, normalizing this setting in credential-bearing documentation is risky because these operations use AK/SK secrets and disabling SSL verification exposes requests to man-in-the-middle interception or endpoint spoofing.

Static analysis

No suspicious patterns detected.