T09 · Insecure Skill Coding Practices
- Location
scripts/ambari_api.py:35- Finding
TLS Certificate Verification Disabled by Default
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a legitimate Ambari cluster-management tool, but it handles privileged credentials and live service changes with unsafe defaults that users should review before installing.
Review carefully before installing, especially for production clusters. Use a least-privilege Ambari account, avoid real passwords on the command line, do not rely on the plaintext config file for sensitive credentials, enable certificate verification or a trusted CA path before use, and treat stop/restart commands as outage-causing administrative actions.
scripts/ambari_api.py:35TLS Certificate Verification Disabled by Default
scripts/ambari_api.py:26Ambari Credentials Stored in a Plaintext Configuration File
scripts/ambari_api.py:319Password Accepted and Documented as a Command-Line Argument
scripts/requirements.txt:1Runtime Dependencies Use Open-Ended Version Constraints Without Integrity Pinning
The documented purpose understates and inconsistently describes the skill’s behavior, including local credential storage and host-level operations beyond the stated management scope. Description-behavior mismatches are dangerous because users and orchestration systems may invoke the skill under false assumptions, leading to sensitive credential exposure or broader-than-expected administrative actions on cluster infrastructure.
The file shows plaintext credentials on the command line for both development and production examples without warning that shell arguments are exposed via history, process listings, terminal logging, and operational runbooks. In the context of an Ambari administration tool, this is especially dangerous because the credentials are for privileged cluster management, making accidental disclosure likely and high-value to an attacker.
The client sends HTTP Basic Auth credentials while TLS certificate verification is disabled by default and related warnings are suppressed. In the context of cluster administration, this enables man-in-the-middle interception or tampering of credentials and management commands, potentially allowing an attacker to take over or disrupt Hadoop services.
The skill documents commands that read and write local files and perform network operations against Ambari, but it declares no explicit tool scope or permission boundaries. This increases the chance that an agent or reviewer will underestimate the skill’s real capabilities, enabling unintended file access, credential handling, or cluster changes without clear policy constraints.
The activation text uses broad triggers such as mentions of Ambari, HDP, HDF, or cluster operations without clear guardrails. Over-broad activation can cause the skill to be selected in contexts where the user did not intend administrative actions, increasing the risk of unnecessary credential prompts, information disclosure, or destructive API calls.
The quick-start instructions tell users to supply and store Ambari credentials, including a password, without any warning about sensitive data handling or storage protections. Because this skill manages administrative cluster access, unsafe credential storage can directly enable unauthorized control over services, hosts, and operational state.
The documentation presents stop and restart operations as routine commands without warning about operational impact, downtime, or the need for explicit confirmation. In the context of production cluster administration, these are highly sensitive actions that can interrupt storage, scheduling, or query services across a Hadoop environment.
This markdown file documents a PUT endpoint that changes service state, including starting and stopping cluster services, but provides no warning that these actions can affect availability or production workloads. Under the markdown-specific missing-warning rule, operational changes that can impact system integrity should be accompanied by a user-facing caution.
The file includes a PUT endpoint for changing host component state, such as starting a DATANODE on a host, but does not warn users that this performs live infrastructure changes. Markdown guidance for such actions should disclose potential effects on service health, availability, and system integrity.
The documentation includes production-labeled Ambari configuration examples with plaintext usernames and passwords, which normalizes unsafe secret handling and can lead users to paste real credentials into shell history, CI logs, screenshots, or shared docs. In an infrastructure-management skill, admin credentials grant broad operational control, so even example secrets in a production context materially increase the chance of credential exposure and misuse.
The examples instruct users to stop and restart production services without any warning, confirmation, rollback guidance, or discussion of availability impact. In a cluster-operations skill, such commands are inherently disruptive and can cause outages or data-processing failures if run casually or in the wrong environment.
The Python example hardcodes administrator credentials directly in source, encouraging copy-paste into scripts, notebooks, and repositories where secrets are often retained indefinitely. Because this skill manages Ambari clusters, those credentials could enable unauthorized service operations, cluster reconfiguration, or broader compromise of Hadoop environments if replaced with real values.
The troubleshooting guidance explicitly recommends trying the default Ambari credentials admin/admin without any warning or restriction. In a cluster-management skill, this normalizes insecure authentication practices and could lead users to attempt or retain well-known credentials on privileged infrastructure, increasing the chance of unauthorized administrative access.
Suggesting default credentials as a normal troubleshooting step is unsafe because Ambari provides administrative control over Hadoop clusters and their services. In this context, encouraging use of a known default username/password pair materially increases risk by enabling weak-authentication behavior on production-like systems.
The unsafe default verify_ssl=False makes insecure transport the standard behavior for all API interactions unless a caller overrides it, and this file never exposes a safe way to do so through configuration. Because this skill manages Ambari cluster operations with administrative credentials, the insecure default materially increases the likelihood of credential theft and command tampering.
class AmbariClient:
"""Ambari REST API Client"""
def __init__(self, base_url, username, password, verify_ssl=False):
self.base_url = base_url.rstrip('/')
self.auth = HTTPBasicAuth(username, password)
self.verify_ssl = verify_ssl
The service_action docstring says supported actions include INSTALLED (same as STOP), yet the valid_actions list excludes INSTALLED and the function rejects it. This creates a direct contradiction between the function's documentation and its runtime behavior.
The skill stores Ambari credentials in plaintext in a local JSON config file under the user's home directory without setting restrictive file permissions or warning the user. On multi-user systems, backups, endpoint collection tools, or compromised user sessions, these credentials could be exposed and then used to administer Hadoop cluster services.
The CLI parser documents and accepts INSTALL as a valid component action, but component_action only allows START and STOP and returns an invalid-action error for INSTALL. This is an active contradiction between the exposed command interface/documentation and the code's actual behavior.
The dependency is specified with a lower bound only (requests>=2.28.0), so builds may resolve to different versions over time and could inadvertently install a release with known vulnerabilities or breaking behavior. In a cluster-management skill that makes outbound API calls to Ambari, dependency drift in an HTTP client increases supply-chain and runtime risk, even though this file alone does not prove a currently vulnerable version is installed.
requests>=2.28.0
urllib3>=1.26.0
requests has multiple known advisories, and because the manifest does not pin the version, there is no way to verify from this file whether deployments avoid affected releases. In a skill that performs authenticated REST operations against Ambari, an affected HTTP client could expose credentials, weaken TLS/request handling, or mishandle redirects depending on the resolved version.
The dependency is unpinned (urllib3>=1.26.0), which makes installations non-reproducible and can result in pulling a vulnerable or incompatible version in the future. Because this skill manages Hadoop clusters over REST, the HTTP transport library is security-relevant and version ambiguity makes safe deployment harder to verify.
requests>=2.28.0
urllib3>=1.26.0
urllib3 has known advisories, but the unpinned requirement prevents determining whether installed environments are exposed. Since urllib3 underpins HTTP communication and may process redirects, proxies, and compressed responses, this uncertainty is more concerning in a cluster-management tool that interacts with potentially sensitive infrastructure endpoints.