Security audit

huawei-cloud-mrs-host-alarm-diagnose

Security checks for vulnerabilities and agentic risk

Overview

This is a mostly coherent MRS alarm-diagnosis skill, but it exposes overly broad authenticated Manager API proxy access and risky operational guidance that should be reviewed before installation.

Install only in a trusted, controlled MRS/LakeWatch environment. Before use, remove or restrict the generic manager-access POST and wildcard proxy entries, enable TLS verification or configure a trusted CA, protect the config/token/key files, and require explicit human approval before any repair command is run.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration

Findings (21)

Lp3

Medium

Category: MCP Least Privilege
Confidence: 90% confidence
Finding: The skill exposes meaningful capabilities—shell execution, file reads, environment access, and network access—via the declared `bash` tool and the documented use of local config files and LakeWatch APIs, but it does not declare an explicit permissions model or scope constraints. This creates an avoidable trust gap: an integrating agent may grant broader execution than the alarm-diagnosis use case requires, increasing the chance of unintended data exposure or misuse if the skill or its dependencies are compromised.

Tp4

High

Category: MCP Tool Poisoning
Confidence: 95% confidence
Finding: The skill is presented as a narrowly scoped alarm-diagnosis workflow, but its documented backend client appears to support much broader behaviors: generic invocation of any configured API, credential handling, token lifecycle management, optional file download, and use of external crypto utilities. That mismatch is dangerous because reviewers or orchestrators may trust the skill for a constrained diagnostic purpose while it actually enables wider network actions and local secret handling, which expands the attack surface and could be abused to reach unintended APIs or expose sensitive data.

Context-Inappropriate Capability

Medium

Confidence: 92% confidence
Finding: The skill includes a large manual path with direct operational commands that go beyond observation into system modification and external access, such as creating directories, changing permissions, restarting GaussDB, copying scripts from other nodes, and initiating SFTP sessions. In a diagnosis skill, this expands the agent's effective authority from troubleshooting into remediation and could lead to unauthorized changes, service disruption, or unsafe operator execution if surfaced without gating, especially because some steps are interactive and environment-dependent.

Intent-Code Divergence

Medium

Confidence: 97% confidence
Finding: The file claims diagnosis is driven only by the built-in LakeWatch API client, but it also instructs direct shell access to local log files using ls/cat on the alarm node. This creates a scope mismatch that can lead an agent or operator to perform host-level actions outside the declared trust boundary, increasing the chance of unauthorized local access patterns and bypassing API-side controls, auditing, or sandboxing.

Description-Behavior Mismatch

Medium

Confidence: 92% confidence
Finding: The knowledge base extends beyond diagnosis into prescriptive system administration and repair actions such as chown, chmod, ulimit, lsof, netstat, and disk cleanup. That broadens the skill from analysis into operational change execution, which is not reflected in the manifest and may cause an agent to recommend or perform impactful admin actions in a context that users expect to be diagnostic only.

Context-Inappropriate Capability

Medium

Confidence: 89% confidence
Finding: The documented `access_manager_get` capability allows callers to proxy arbitrary MRS Manager GET paths via `target_url`, which is broader than the skill's stated alarm-diagnosis purpose. Even though it is limited to GET, this can expose sensitive management-plane data, configuration, and audit information unrelated to a specific alarm, increasing the risk of over-privileged data access and misuse.

Context-Inappropriate Capability

Medium

Confidence: 84% confidence
Finding: The YAML-based extension model allows operators to define new arbitrary API endpoints and request mappings, turning a diagnosis client into a general-purpose API invocation framework. In a skill meant to stay within a fixed diagnostic knowledge base, this broadens the attack surface and can enable access to unintended services or actions if configuration changes are made without strong controls.

Description-Behavior Mismatch

Medium

Confidence: 89% confidence
Finding: The verification guide explicitly validates a generic `access_manager_get` capability against an MRS Manager endpoint, which expands the tested and therefore encouraged operational scope beyond narrowly bounded alarm diagnosis. Even though the example is a read-oriented GET, documenting generic proxy access increases the chance the skill is used as a broader management data access path and weakens the principle of least privilege.

Context-Inappropriate Capability

Medium

Confidence: 95% confidence
Finding: The access_manager_get endpoint is a generic proxy to MRS Manager GET APIs using a caller-controlled target_url, but the skill is described as an alarm-diagnosis-only capability. Without strict allowlisting or path validation, this enables access to unrelated manager APIs such as audit, cluster, or administrative endpoints, expanding the skill far beyond its declared scope and creating a confused-deputy risk if the backend authenticates with privileged credentials.

Context-Inappropriate Capability

High

Confidence: 99% confidence
Finding: The manager-access-get and manager-access-post endpoints expose highly generic web/API proxying with wildcard target_url support, including POST capability. In the context of a diagnosis skill, this can be abused to invoke arbitrary Manager web actions or APIs outside the intended workflow, potentially reaching sensitive data, triggering state-changing operations, or bypassing normal UI/API access controls through the skill's backend trust.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The manual SFTP test instructs the operator to initiate an interactive authentication flow without a warning about credential handling, terminal history, recording, or accidental disclosure. In an agent-assisted setting, users may paste passwords into monitored consoles or expose credentials during shared-session troubleshooting, creating avoidable secret leakage risk.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: The skill includes operational guidance to change configuration and restart critical services (NodeAgent and sshd) without an explicit warning, approval gate, rollback guidance, or environment validation. In an automated or semi-automated agent context, these steps could be surfaced or acted on prematurely, causing service interruption, loss of visibility, or accidental lockout if the SSH configuration is wrong.

Missing User Warnings

Medium

Confidence: 87% confidence
Finding: The skill includes direct kernel/network tuning commands that modify TCP behavior on the host without any safety gating, rollback guidance, or warning that these changes are system-wide and can affect running workloads. In an agent skill context, operational instructions like `sysctl -w` can be executed or repeated by users with elevated privileges, potentially causing service instability, weakened network hygiene, or masking the real root cause instead of safely diagnosing it.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The remediation section recommends permission-changing commands such as chown and chmod without contextual safeguards, validation steps, or warnings about ownership and mode errors. If followed blindly, these commands can break service integrity, weaken filesystem protections, or introduce privilege and access-control issues on production nodes.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The file suggests increasing file descriptor limits with ulimit -n 65535 without explaining scope, persistence, compatibility, or resource side effects. In practice, this can mask root causes, create inconsistent behavior across sessions/services, and encourage unsafe operational changes on production systems without capacity review.

Missing User Warnings

Medium

Confidence: 81% confidence
Finding: The client caches reusable authentication tokens on local disk under temporary directories, and the documentation does not clearly warn about the sensitivity of those artifacts or operational constraints. If the host is shared, compromised, or temp storage is improperly protected or collected, an attacker may reuse the token to access LakeWatch APIs until expiry.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: On Windows, the documentation states that the AES key is auto-generated into a local `.aes_key` file next to the script, meaning the decryption key is stored alongside the encrypted password. This undermines the protection value of the encryption at rest: anyone who can read the script directory may be able to recover the stored credentials.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The instructions direct operators to make live authenticated calls that can transmit cluster identifiers, node names, log paths, log contents, and manager configuration data to the configured LakeWatch endpoint without any explicit warning, consent, or data-handling note. In enterprise environments, this can lead to unintended disclosure of sensitive operational metadata or logs, especially if the endpoint configuration is incorrect, third-party managed, or insufficiently trusted.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The SSL context allows certificate validation and hostname checks to be disabled via configuration, enabling silent acceptance of untrusted TLS connections. If used in production, an attacker on the network could intercept credentials, tokens, and API responses via man-in-the-middle attacks, which is especially dangerous for a diagnosis skill that handles authentication and sensitive alarm/log data.

Vague Triggers

Medium

Confidence: 96% confidence
Finding: The configuration requires only cluster_id and target_url for manager proxy access and does not define validation rules or scope constraints for target_url. This lack of constraint makes it easy for a caller or prompt-driven agent flow to access arbitrary internal Manager paths, increasing the likelihood of overreach, unauthorized data exposure, or misuse of privileged backend connectivity.

Missing User Warnings

Medium

Confidence: 88% confidence
Finding: The configuration includes verify_ssl: false, which permits TLS certificate verification to be disabled. In any environment where this setting is used, an attacker on the network could intercept or tamper with traffic to the LakeWatch service, exposing credentials, tokens, alarm data, or API responses and undermining trust in diagnosis results.

Static analysis

Detected: suspicious.insecure_tls_verification

HTTPS certificate verification is disabled.

Warn

Code: suspicious.insecure_tls_verification
Location: scripts/lakewatch_api_client.py:148