T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:126
- Finding
- SSH Host-Key Verification Disabled in Password-Based Connection Example## Vulnerability Details **File Location**: `SKILL.md:126` **Vulnerability Type**: SSH server authentication bypass through disabled host-key verification **Risk Level**: High ```bash lelogin exec --env-file ssh.env -- /bin/sh -c \ 'sshpass -e ssh -o StrictHostKeyChecking=no -p "$SSH_PORT" \ "$SSH_USER@$SSH_HOST" "echo ok"' ``` ### Technical Analysis The documented SSH workflow passes `StrictHostKeyChecking=no` to the SSH client. This setting permits a connection to proceed without requiring the remote server's host key to be trusted or previously verified. The same workflow retrieves a password from `lelogin`, injects it into the `SSHPASS` environment variable, and directs `sshpass -e` to submit that password during authentication. Consequently, disabling host-key verification removes the mechanism that protects the injected credential from being sent to an impersonated SSH server. An attacker able to manipulate DNS resolution, routing, network traffic, or the specified SSH endpoint could present an arbitrary host key. The client would accept it without an authenticity check and could then submit the password to the attacker's server. ### Attack Path 1. A user authorizes the documented `lelogin exec` operation. 2. `lelogin` resolves the referenced secret and injects the SSH password into `SSHPASS`. 3. The attacker redirects the connection to a server under the attacker's control, such as through DNS poisoning, route manipulation, or a malicious network intermediary. 4. The attacker's server presents an untrusted SSH host key. 5. Because `StrictHostKeyChecking=no` is configured, the client proceeds without requiring trusted server identity verification. 6. `sshpass -e` supplies the resolved password to the impersonated server. 7. The attacker captures the credential and can attempt to reuse it against the legitimate SSH service or other systems where the credential is valid. ### Impact Assessment Successful exploitation can disclose the SSH accoun ...[truncated 600 chars]
- Remediation
- ## Remediation Suggestions - Remove `-o StrictHostKeyChecking=no` from the documented command. - Require strict host-key validation with `-o StrictHostKeyChecking=yes`. - Provision the expected server host key through a trusted channel before initiating the connection. - Use a dedicated, permission-restricted `known_hosts` file and specify it explicitly, for example: ```bash lelogin exec --env-file ssh.env -- /bin/sh -c \ 'sshpass -e ssh \ -o StrictHostKeyChecking=yes \ -o UserKnownHostsFile="$HOME/.ssh/known_hosts" \ -p "$SSH_PORT" "$SSH_USER@$SSH_HOST" "echo ok"' ``` - Verify host-key fingerprints out of band rather than automatically trusting keys obtained from the same potentially compromised network path. - Prefer SSH public-key authentication with passphrase-protected keys over reusable account passwords. - Disable direct root login and password authentication on SSH servers where operationally possible. - Use a minimally privileged account and narrowly scoped privilege escalation instead of authenticating directly as `root`. - Retain the existing requirement for explicit user approval before resolving or injecting secrets.