Security Analysis of request-remote-assistance

[neil2ball]

Security Analysis of request-remote-assistance

After reviewing the code, a remote‑assistance utility named request-remote-assistance, located in site/roles/trinity/cv_support/files/, appears to contain security weaknesses in its current implementation.

Individually, each issue might introduce risk; collectively, they may increase the likelihood of unintended behavior or unauthorized access under certain conditions.

I hope these observations are helpful. If anything here needs clarification or if I’ve misunderstood part of the design, I’m more than willing to revisit it. My goal here is to discover and eliminate any potential risks to ensure cluster security. If there are architectural assumptions or safeguards that I am not aware of, I’d genuinely appreciate learning more about them so I can better understand the intended security model.

If I’m mistaken in any of these points, please feel free to make corrections. I’m approaching this with the intention of being constructive. I didn't want to go further than what I have with testing the script since that might become misconstrued as a hacking attempt.

Critical Security Risks

1. Command Injection via User Input (Critical)

Location: Lines 96-97 (argument parsing), 176 (ping command)

Issue: The script accepts a user‑controlled sandbox value and inserts it directly into a shell command without validation or escaping:

elif (len(arg) > 1):
    sandbox = arg.split('.',1)[0]

Later used in unsanitized shell commands:

perr=shell_exit_status('ping -w5 -c1 {}.clustervision.com 2>&1 > /tmp/ping.log'.format(sandbox))

Exploitation:
An attacker could pass malicious input like sandbox; rm -rf /; echo which would execute arbitrary commands:

./request-remote-assistance sandbox"; whoami; echo "

The script would execute:

ping -w5 -c1 sandbox; whoami;.clustervision.com 2>&1 > /tmp/ping.log

The shell interprets this as three separate commands:

1. ping -w5 -c1 sandbox"

2. whoami

3. echo ".clustervision.com

The injected command (whoami) executes successfully. The trailing .clustervision.com becomes part of the final echo and does not prevent exploitation.

Impact

• Arbitrary command execution under the privileges of the user running the script

• Potential full system compromise depending on execution context

Root Cause

• Direct string interpolation into shell commands

• Use of shell=True (or equivalent) without sanitization

• No validation or escaping of user‑supplied input

2. SSH Private Key Exposure

Location: Lines 158 (SSH key generation); 168 & 218 (private key usage)

Issue: The script generates a new SSH private key (id_rsa-CV) using ssh-keygen and stores it in the user’s ~/.ssh directory:

shell(""" timeout 20 -k5 yes y|ssh-keygen -t rsa -b 4096 -N '' -f {}/.ssh/id_rsa-CV """.format(current_home))

The private key:

• is created without a passphrase

• is stored in a predictable location (~/.ssh/id_rsa-CV)

• does not have its permissions hardened (e.g., chmod 600)

• inherits whatever umask the environment happens to have

Later, the script derives the private‑key filename from the public key:

priv_file = pub_file.rsplit('.', 1)[0]

And uses it directly in an SSH command executed via a shell:

subprocess.call(
    'ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no '
    '-o ServerAliveInterval=30 -o ServerAliveCountMax=5 '
    '-i {} -t -R :{}:localhost:22 sandbox@{}.clustervision.com'
    .format(priv_file, remoteport, sandbox),
    shell=True
)

Security Impact

This creates two distinct but related vulnerabilities:

1. Private Key Exposure

Because the script does not enforce restrictive permissions, the private key may be readable by other local users or processes. If an attacker obtains this key, they can:

• impersonate the user

• establish unauthorized SSH tunnels

• access remote support infrastructure intended only for legitimate systems

The absence of a passphrase makes the key immediately usable.

2. Unsafe Private Key Usage

The script passes the private key directly into a shell‑constructed SSH command with:

• shell=True

• host key checking disabled

• a predictable key path

This increases the attack surface for:

• key theft

• misuse of the key in unauthorized SSH sessions

• man‑in‑the‑middle attacks

• command injection (if other variables in the same command are compromised)

Root Causes

• No explicit permission hardening (chmod 600)

• No passphrase on the private key

• Predictable key filename

• Direct use of the private key in a shell‑constructed SSH command

• Disabled host key verification

Severity

High. Exposure or misuse of an SSH private key enables authentication bypass and unauthorized access to remote systems.

3. SSH Key Injection into authorized_keys

Location: Lines 183-201 (adding sandbox's public key) 240 (key removal attempt)

Issue: The script retrieves a public key from a remote server and appends it directly to the user’s ~/.ssh/authorized_keys file:

shell("""echo '{}' >> {}""".format(sandboxpub, auth_key))

No validation, integrity checking, or key‑pinning is performed. The script assumes the downloaded key is trustworthy and permanently authorizes it for SSH access.

The cleanup routine later attempts to remove the key using a grep command that incorporates a variable derived from remote data:

shell("""grep -vw '{}' {} > {}.clean""".format(key_name, auth_key, auth_key))

Because key_name is not sanitized, special characters could alter the behavior of the cleanup command or corrupt the authorized_keys file.

Exploitation:
This behavior introduces two significant risks:

1. Remote Key Injection

If the remote endpoint serving the public key is compromised, intercepted, or spoofed, an attacker can supply their own SSH public key. This grants persistent, passwordless SSH access to any system running the script.

This constitutes a supply‑chain‑style vulnerability.
2. Unsafe Cleanup Logic

The cleanup command embeds unvalidated data into a shell command. If the remote key contains unexpected formatting or maliciously crafted fields, the cleanup step could:

• remove unintended keys

• corrupt the authorized_keys file

• alter the shell command’s behavior

Severity

High. Unauthorized key injection enables persistent remote access, and unsafe cleanup logic increases the risk of file corruption or unintended privilege changes.

4. Use of HTTP for Critical Operations

Location: Line 104 (remote_url) and commented line 186 (SCP copy)

Issue: Uses HTTP instead of HTTPS for some operations:

remote_url = 'http://{}/~remote/'.format(sandbox)

This URL is used for operations that influence the behavior of the remote‑assistance workflow. Because HTTP provides no encryption or integrity protection, any data retrieved from this endpoint is vulnerable to interception or modification by an attacker on the network path.

Additionally, although the following SCP command is commented out, it demonstrates a pattern of disabling SSH host‑key verification:

#shell("""scp -v -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -i {} -P {} tunnel.log sandbox@{}.clustervision.com:{}""".format(priv_file,remoteport,sandbox,logfile_name))

This pattern is consistent with other parts of the script (e.g., line 218), where StrictHostKeyChecking=no is actively used. Disabling host‑key verification removes SSH’s protection against server impersonation.

Impact

• Man‑in‑the‑middle attacks: An attacker on the network path can intercept or modify HTTP responses, potentially altering script behavior or injecting malicious data.

• Loss of integrity: The script cannot verify that the data it receives originates from the intended server.

• Weak SSH posture: The use of StrictHostKeyChecking=no elsewhere in the script (218) removes protections against server impersonation.

Severity

Medium to High.
In environments where network traffic can be intercepted or manipulated (e.g., shared networks, cloud environments, enterprise networks with inspection devices), this becomes a critical issue.

5. Hardcoded Credentials in Authentication

Location: Line 209 (requests.post with embedded credentials)

Issue: The script embeds static username and password credentials directly in the source code:

r = requests.post('https://sandbox.clustervision.com/cgi-bin/keys.py',data=data, auth=('trinityx','trinityx'))

Impact

• Credential exposure:
  Hardcoded credentials are visible to anyone who can read the script, including unauthorized users or attackers who gain limited access to the system.

• Unauthorized access to vendor infrastructure:
  If these credentials grant access to ClusterVision services, an attacker could impersonate legitimate systems, submit unauthorized requests, or retrieve sensitive data.

• No credential rotation:
  Because the credentials are embedded in the script, they cannot be changed without modifying and redistributing the script itself.

• Potential for widespread compromise:
  If the same credentials are used across multiple installations, compromise of one system exposes all others.

Severity

High. Hardcoded credentials undermine authentication security and create a single point of failure across all deployments of the script.

6. Shell Command Injection via authorized_keys Cleanup

Location: Lines 239-241 (cleanup code)

Issue:
The script attempts to remove a previously added SSH key by running shell commands that incorporate the variable key_name directly into the command string:

if key_name:
    shell("""grep -vw '{}' {} > {}.clean""".format(key_name, auth_key, auth_key))
    shell("""cat {}.clean > {}""".format(auth_key, auth_key))

The value of key_name is derived from remote data (the downloaded public key). It is not validated, sanitized, or escaped before being inserted into a shell command.

Because the script uses a shell to execute these strings, any shell metacharacters present in key_name will be interpreted by /bin/sh.

Impact

1. Command Injection Risk

If an attacker can influence the contents of the downloaded public key (for example, through a compromised endpoint, a man‑in‑the‑middle attack, or a maliciously crafted key), they can embed characters that alter the behavior of the cleanup command. This could allow:

• execution of unintended shell commands

• modification or deletion of arbitrary files

• corruption of the authorized_keys file

2. Integrity Risk to authorized_keys

Even without deliberate exploitation, malformed or unexpected key formats could cause:

• removal of legitimate keys

• partial or complete corruption of the file

• denial of SSH access for the user

Because the cleanup step rewrites the entire authorized_keys file, any injection or parsing error has immediate and potentially severe consequences.

Severity

High. The cleanup routine executes shell commands using unvalidated, externally influenced data. This creates a direct command‑injection vector and jeopardizes the integrity of the user’s SSH configuration.

7. Weak SSH Host Key Verification

Location: Lines 218 (SSH invocation via subprocess.call)

Issue: The script invokes SSH with host‑key verification explicitly disabled:

subprocess.call('ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no ...')

The options:

• -o UserKnownHostsFile=/dev/null

• -o StrictHostKeyChecking=no

cause SSH to:

• ignore the known‑hosts database

• accept any host key presented by the server

• suppress warnings about mismatched or unknown keys

This effectively disables SSH’s built‑in protection against connecting to an impersonated or malicious server.

The following line:

subprocess.call('setterm -cursor on', shell=True)

is unrelated to the vulnerability but confirms that the script continues to use shell‑based command execution.

Impact

• Man‑in‑the‑middle attacks:
  An attacker who can intercept or modify network traffic can impersonate the remote server and gain access to the SSH tunnel.

• Loss of authenticity guarantees:
  The client cannot verify that it is connecting to the legitimate ClusterVision endpoint.

• Compounded risk with other vulnerabilities:
  When combined with insecure key handling and command injection elsewhere in the script, disabling host‑key verification significantly increases the overall attack surface.

Severity

High. Disabling SSH host‑key verification removes a core security property of SSH and exposes the connection to server impersonation and interception.

8. Sensitive Data Exposure in Log Files

Location: Lines 187 (log file name with TrinityID)

Issue: The script creates log files with the Trinity ID, which could be used to track or fingerprint specific installations:

logfile_name = 'tunnel--TrinityID-' + readable_trid + '--' + now.strftime("%m-%d-%Y_%H-%M-%S") + ".log"

The Trinity ID appears to be a unique identifier associated with the installation or system. By including it directly in log filenames, the script exposes this identifier in a way that can be accessed by other local users, backup systems, monitoring tools, or any process with read access to the log directory.

Impact

• Fingerprinting of installations
  The Trinity ID can be used to uniquely identify or track specific systems. If logs are collected centrally or shared with support teams, this identifier becomes visible outside the originating machine.

• Correlation of activity across logs
  Because the ID is embedded in every log filename, an attacker or unauthorized user with access to log archives can correlate activity across time and across systems.

• Potential privacy or metadata leakage
  Even if the logs themselves contain no sensitive content, the filename alone may reveal deployment details or internal identifiers that were not intended to be exposed.

• Amplified risk if logs are transmitted or stored externally
  If logs are uploaded, emailed, or included in support bundles, the Trinity ID is automatically disclosed.

Severity

Low to Medium.
The identifier does not directly grant access, but embedding unique system identifiers in log filenames increases the risk of fingerprinting, correlation, and unintended metadata exposure—especially in environments where logs are aggregated or shared.

Additional Security Concerns

1. Lack of Input Validation on Certificate Subject

The script parses SSH public keys using a regular expression but does not validate the overall key format or sanitize embedded fields. If an attacker can influence the certificate subject or key comment (for example, via a compromised key source), they may be able to inject unexpected characters or options that affect downstream processing, including cleanup routines or authorized key handling.

2. Insecure File Permissions

The script sets the authorized_keys file to mode 640, which allows group read access. OpenSSH typically requires more restrictive permissions (mode 600) to prevent SSH from rejecting the file and to ensure that no other local users can read authorized keys or metadata.

3. No Rate Limiting or Abuse Protection

The script does not implement any form of rate limiting, throttling, or brute‑force protection. A malicious user or automated process could repeatedly trigger tunnel creation, key generation, or remote requests, potentially leading to resource exhaustion or unauthorized repeated access attempts.

Overall Risk

Taken together, these vulnerabilities could allow an attacker to:

• gain unauthorized SSH access

• establish persistent backdoors

• impersonate trusted systems

• manipulate or replace SSH keys

• intercept or modify network traffic

• escalate privileges or compromise the host

The combination of command injection, insecure key handling, disabled SSH protections, and unvalidated remote data creates a high‑risk environment that warrants immediate remediation.

[aphmschonewille]

Hi Neil

Thank you so much for this input!
We will review the problems/issues/code based on above findings.
If you feel there are other components that need revisiting, please don't feel shy to inform us.

Regards
Antoine